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 < brechtvanlom...@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 <pablodp...@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@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers