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 <[email protected]> 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 <[email protected]> > 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 (< > [email protected]>) > > 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 > >> [email protected] > >> https://lists.blender.org/mailman/listinfo/bf-committers > >> > > > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
