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