[Bf-committers] Sculpt Mode development

[Jacob Merrill]

I as thinking something like this could be used for anything
(pbvhtree) if you can query a point + radius

it would almost be handy to have some sort of threaded py command with a
pool to do this.
(so that can circumvent gil yet write equations in py)

(sculpt / paint vertex / paint weight / texture paint )


On Tue, Mar 12, 2019 at 11:18 AM Brecht Van Lommel <
brechtvanlommel at gmail.com> wrote:

> Hi Pablo,
>
> I've now given you commit rights, see private mail for details.
>
> As you are working in this branch, I suggest to carefully keep track of
> performance and memory usage, because they can be difficult to gain back
> after making many changes. I also recommend to focus on fewer really
> finished features over many prototypes, as untangling that for review and
> merging can be difficult.
>
>
> Some quick feedback from reading the proposal.
>
> Voxel Remesh solves most of dyntopo problems without any performance
> > penalty.
>
>
> Would be good to clarify which problems, or why there is no performance
> penalty?
>
> My guess is you're saying this remesh is for users to fix poor topology
> created by dyntopo, and that it runs relatively fast even for high poly
> meshes?
>
> Static Remesher - OpenVDB Voxel Remesh
>
>
> There is no need to tie this to other uses of OpenVDB in Blender, or to
> rewrite it if those come along. Just write a remeshing functions that uses
> the OpenVDB library, separate from other code.
>
> PBVH vertex paint stores colors in the mesh vertices in a way that is
> > possible to use the sculpt mode code to paint.
>
>
> This needs a better name, vertex paint already uses the PBVH and it doesn't
> explain what it means to users.
>
> For me, the main question here is how this works on a UI design level. What
> it means for modes and tools, how you combine sculpt and paint while
> keeping the UI clear.
>
> It would also be good to clarify the data design issue. From what I
> understand you want to store colors per vertex instead of per face corner,
> and that's where backwards compatibility breaks? We probably need to keep
> both per vertex and per face corner attributes storage support, but my
> guess is that only supporting per vertex for paint modes would be
> acceptable.
>
> > Node Brush
>
> The types of brushes that work ok with nodes are likely to be easy to
> implement anyway, and easier to optimize and debug then. For built-in
> brushes I think it's wrong to add this extra level of abstraction.
>
> The main potential here I see is for users to create their own brushes, but
> I did not yet see compelling examples of new possibilities. I see a risk
> here of adding complexity with little practical benefit.
>
> > New Sculpt data structure
>
> A requirement for this data structure is also to have low memory usage and
> be efficient to draw, and to some extent making the editing more complex is
> acceptable to accommodate that I think. Though the current code is
> certainly not optimal, replacing it needs very careful design.
>
> Regards,
> Brecht.
>
>
> On Mon, Mar 11, 2019 at 2:25 PM Pablo Dobarro <pablodp606 at gmail.com>
> wrote:
>
> > Hi all,
> >
> >
> > I am Pablo Dobarro. I've been working with Zacharias Reinhardt, Julien
> > Kaspar and Lukas Walzer for the last months to write a proposal to
> improve
> > sculpt and vertex paint mode. We have a document that details our main
> > goals, as well as a short/mid term planning and the current status of the
> > patches.
> >
> >
> >
> https://docs.google.com/presentation/d/1fmjdtajPzeD3ixpGIvseKMRsAzhmKC4etIE8YqacwLk/edit?usp=sharing
> >
> > We are aware that the current master branch is in feature freeze state,
> so
> > we would like to have a new branch to start developing sculpt/vertex
> paint
> > mode and have more polished patches ready to review after 2.80 is out.
> Some
> > of those patches (like tweaking the behavior of some brushes) will break
> > the compatibility, and they will need a lot of iterations and feedback
> from
> > the community to get them right. Having this in a separate branch will
> make
> > easier for us to provide test builds and to test the integration of the
> new
> > features.
> >
> > In the future, we would like to see a Sculpt Quest to happen, to help us
> > tackle the bigger features and design goals of the proposal. We know that
> > it is not realistic at this moment, but we would want to advance as much
> > work as possible before that happens. A possible Sculpt Quest is
> something
> > we need to discuss in detail with the Blender Foundation, after we made
> > progress with the separate sculpting branch.
> >
> > Could someone create a new branch and give us commit rights to start
> > working on this project?
> >
> > Best regards,
> > Pablo
> > _______________________________________________
> > 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
>