[Bf-committers] Understanding the dev process

[Jacob Merrill]

It would be nice if The game engine concerns would be addressed during the
development of 2. 8 instead of after.

Also is there any plan to integrate multiple users to a single blender
scene? (multi-player blender?)
5g means huge changes could stream instantly almost no?

On Fri, Jul 5, 2019, 10:18 PM Nathan Letwory <jesterking at letwory.net> wrote:

> Hi Pablo (and all the others who already chipped in),
>
> Your writing is very much on topic. Bias is what I'm looking for, the
> request
> was formulated about perception of process!
>
> I think some valid points are being raised. We definitely should continue
> this
> discussion, and my hope is that we will see all sides of it in the coming
> days.
>
> For now I'll keep it to encouraging everybody to speak their mind. All good
> criticism, concerns, but also positive points, are welcome.
>
> Next week or so will be time for more contemplation on all input.
>
> /Nathan
>
> la 6. heinäk. 2019 klo 7.07 Pablo Dobarro <pablodp606 at gmail.com>
> kirjoitti:
>
> > Hi!
> >
> > Maybe I'm going off-topic and I'm probably a little bit biased...
> >
> > I think the main problem in the development process of some areas of
> > Blender is feature incoherence. I feel like some times there are
> > discussions, design proposals and commits implementing new advanced
> > features on areas where the most basic functionality for an artist is
> still
> > not right. The sculpt/paint module and the tool system are heavily
> affected
> > by this.
> >
> > This is a tricky problem to solve. We can't really expect artists to make
> > useful bug reports about brushes or tools behaving incorrectly. For most
> of
> > them, it would be nearly impossible to formulate the problem pointing at
> > the exact technical detail for a developer to fix it. These kinds of
> issues
> > are really obvious for an artist who has been working with these tools
> for
> > years, but developers may think that the tool is working at it should.
> This
> > communication problem often ends in misleading bug reports, proposals and
> > discussions going nowhere while trying to fix the wrong thing.
> >
> > The thing is: in some cases, those issues can be fixed by changing just a
> > few lines, so we can expect artists with a coding background to fix them.
> > But there are a lot of cases where a whole redesign of an area is
> required
> > just to fix one those issues (that is essentially the problem of the
> sculpt
> > branch). Some users are creating non-commercial addons to bypass these
> > limitations by recreating entire systems through the Python API instead
> of
> > contributing it to Blender, probably because they consider that a task
> for
> > a core developer.
> >
> > I think we should be extra careful about this when doing big refactors or
> > creating new modules. In my opinion, the core team should focus more on
> > designing the new systems in a way that makes the life of new
> contributors
> > easier (who can probably take care of this) instead of making a final
> > product with a planned set of features. We should put a little more
> effort
> > to make sure the foundations are right from and artist perspective
> >
> > Currently, some of those issues so bad that, in my opinion, they should
> > not be considered as a feature request. They should probably be handled
> as
> > a high priority bug, blocking a release. They make the experience of some
> > areas much worse than Blender crashing every 10 minutes. This ends up
> > hurting the opinion artists have about Blender and all the technical work
> > that is behind it.
> >
> > As an example, the Grease Pencil team spent a lot of time designing and
> > tweaking the behavior of each brush, and that clearly shows. The result
> is
> > so impressive that it almost feels like a pixel-based drawing software.
> An
> > artist is not going to care about modifiers, effects or animation
> features
> > if they feel that the brush engine is broken just by doing one brush
> stroke.
> >
> > If we only focus on long term interesting technical projects and bug
> > fixing, Blender will be able to paint PBR materials across multiple
> UDIMs,
> > while using the current brush engine on a 2D view that does not rotate or
> > flip. In my opinion, we should not touch a single line of the 3D texture
> > projection code until the 2D view and the default brushes are absolutely
> > perfect to a level they can be used for serious illustration work.
> Probably
> > the sweet spot is in the middle of these two points of view.
> >
> > Pablo
> >
> > El jue., 4 jul. 2019 a las 15:38, Nathan Letwory (<
> jesterking at letwory.net>)
> > escribió:
> >
> >> Hey all,
> >>
> >> As you all may know by now I've been asked to help coordinate and manage
> >> the Blender development.
> >>
> >> To get a better understanding of what these days is going on, and to
> >> prevent me from just acting through my personal preferences, I'd like to
> >> hear from the blender developer community how they see the current dev
> >> process.
> >>
> >> I'm most interested in finding out how devs perceive the process: what
> >> goes
> >> well, and even more so what causes trouble.
> >>
> >> An open discussion by anyone on this topic is of course welcome, but I'd
> >> like (and also a bit expect) input at least from those who are listed on
> >> the Modules [1] page.
> >>
> >> Cheers!
> >>
> >> /Nathan 'jesterKing' Letwory
> >>
> >>   [1] https://wiki.blender.org/wiki/Modules
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>