[Bf-committers] Blender 2.8x - support and core development goals

[Howard Trickey]

There's been a lot of complaining about edit mode performance in 2.8, and
some
amount of complaints (but not as much) about edit mode memory footprint.
Some of the complaints seem specifically about what happens with modifiers,
especially subdivision, but some seem to feel it is not just limited to
that.

I wonder if it should be a goal to profile and then come up with and
implement ideas
for edit mode performance improvements?  There are an awful lot of
algorithms
inside the edit tools and modifiers that go over every element (vertex,
edge, face)
of a mesh, often multiple times. E.g., looking for selected elements. I
have a
suspicion that that might be some of the problem. Or maybe I'm completely
wrong
and the whole problem is incrementally updating the display code with only
those
things that have been changed by the edit operation that just happened.

I might be willing to work on this kind of investigation instead of the
Boolean
stuff; though it might make more sense for a full-time developer...


On Thu, Aug 1, 2019 at 10:26 AM Clément FOUCAULT <foucault.clem at gmail.com>
wrote:

> For the next release I would like to:
> - Merge my refactor of Mesh Batch Cache for quicker mesh update.
> - Merge my refactor of the DRWManager for better instancing.
> - Help refactor GPencil drawing pipeline (with antonioya). (fix many issues
> for GPencil)
> - Help refactor Selection drawing (with manowii). (faster and more reliable
> selection for edit mode)
> - Merge Object/Edit/Wireframe and all others overlay engines together to
> reduce compositing complexity.
> I think it is good to do this cleanup now before adding more features.
>
> I would like to also start looking into making EEVEE faster and a bit more
> simpler to use notably:
> - Volumetrics: Using some opengl extension I should be able to speedup
> their evaluation. Should be rather simple.
> - Shadows: Defaults are not good and the system does not support dupli
> lights. Refactoring this to use a "screenspace" approach would make it
> possible to have raytraced shadows in the future.
>
> I think this is enough for 2.81.
>
> Of course there is more to do for EEVEE but I try to keep it realistic.
> I'll update the TODO's on phabricator.
>
> Le lun. 29 juil. 2019 à 18:28, Jacques Lucke <mail at jlucke.com> a écrit :
>
> >
> >
> > I intend to continue to work on the new particle system in the next
> > couple of months. It is unlikely that we can release this in Blender
> > 2.81, mainly due to missing features. Releasing it in Blender 2.82 might
> > be possible. It should be stable and usable by then, but it will
> > probably still lack many features. Maybe other developers are interested
> > in contributing to it as well. I happily help them to get started with
> > this project.
> >
> > It would be good if we could merge some of the
> > particle-system-independent code from the functions branch already. That
> > mainly includes some c++ data structures I developed in the process. I
> > already prepared D4966, but need to update it again. Other encapsulated
> > code of the functions branch could be merged as well, but it makes more
> > sense to wait until it is actually used by e.g. the particle system.
> >
> > Besides that I want to continue designing what I like to call
> > "simulations as first class citizens" in Blender. I already wrote some
> > documents [1] on the topic, but there are still to many unknowns.
> >
> > Finally, I will also help reviewing the code written for the procedural
> > shading GSOC project.
> >
> > [1] https://wiki.blender.org/wiki/Source/Nodes
> >
> > Am 2019-07-26 08:00, schrieb Dalai Felinto:
> >
> > > Dear developers,
> > >
> > > Which areas would you like to focus on in the next few months? Which
> > > code improvements, performance, stability, new features in those areas
> > > would you work on first [1]?
> > >
> > > Finally which bigger new features are you confident would make it in
> > > the 2.81 release, and which are the ones that might happen? These are
> > > particularly important so we can allocate more time for code review
> > > early in the release cycle and work together to assess their
> > > feasibility.
> > >
> > > That should empower us to set priorities and keep our ongoing
> > > development on track. The original goal of a more strict 2-3 month
> > > release cycle is still on the table, and it is up to us to set dates
> > > the deliverables. As long as we are working in the right priorities,
> > > and strive for quality, which specific features land in 2.81 are
> > > secondary.
> > >
> > > I'm away for Siggraph (28-1) so there is no need to rush to reply to
> > this.
> > >
> > > [1] - Please update the module page to reflect this -
> > > https://wiki.blender.org/wiki/Modules /
> > > https://developer.blender.org/T63725
> > >
> > > Best regards,
> > > Dalai
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>