The big Blender Sculpt Mode thread (Part 2)

[ slight off topic maybe…]

A splendid example about what you can do with SDF… or more commonly with math:

(Aren’t metaballs somekind of SDF ???)

And in those tools you do this somekind of easier like with any meshtools or with nodes…

2 Likes

Interesting stuff. How does the addon shown few post above compare to doing it with geonodes in alpha builds? Is the geonode way viable?

ctrl+r, move mouse to set the size, left click or enter to apply the remesh, right click to cancel but remember the size, escape to cancel and remember the previous size instead.

Try to look for videos of magicacsg on youtube…

Also take a look at this thread:

2 Likes

Hi , I made this add-on because the size adjustment widget is too difficult to control.
There’s two buttons 1/2 and 2x that will halve or double the size of voxel remesh. You can right click each button and assign a shortcut to each. Personally i have it setup as r to 1/2 and shift r to remesh, easy and fast. For 2X i use alt r. Hope it helps.
image
remesh_size_ops.py (2.0 KB)

7 Likes

2023-07-25 Sculpt/Texture/Paint Module Meeting

Attendees

  • Dalai Felinto
  • Julien Kaspar
  • Sergey Sharybin
  • Daniel Bystedt
  • Hans Goudey

Announcements

  • 2023-07-13 Texture Painting Polishing Workshop
    A small workshop to discuss possible targets for improving the texture painting experience.
    No definitive goals were set yet. The meeting notes will be used to align short term targets with core developers becoming available to work on the module.
    With recent developments this might take longer because wrapping up current sculpting tasks likely will take precedent.
  • Joe Eagar’s contract ended.
    Ton’s statement:

For personal reasons, Joe Eagar, one of the Sculpt/Paint module team members, was asked to step aside. His development grant (which lasted 18 months) will be ended by the end of July as well. (…)

Agenda

High Priority Bugs

Current state of the module and short term plan

The module remains for now in an orphaned state without a module owner. Module meetings will be halted until more active development continues.

  • Julien will coordinate and keep an eye on the state of the module just like before.
  • Sergey will be available for important bug fixes.
  • Hans is also interested in branching out into the module and tackle technical topics, performance issues and fixing technical debt in the code.
    This would help fix various bugs and open doors for new features.
    His area of experience is more for mesh and sculpting, so he likely won’t be available for textures and udim work.

Existing developers are already involved in many project and can’t immediately help out in module projects. Until new developers join the module the focus will be on Julien & Daniel to define the strategic goals of the module:

  • Wrapping up existing patches (Dyntopo and Roll Brush)
  • Design goals and requirements of Multires and Layered Sculpting (Sergey will eventually be able to work on this)
  • Any vital features and fixes to strengthen the experience of sculpting in Blender

Daniel & Julien will also actively contribute to the Brush Assets project to make the Brush Essential Assets ready for sculpting and painting modes.
Julian Eisel and Bastien Montagne are also involved in that project for porting the tools over to brush assets in the code.

Aligning resources and developer time to finish the Dyntopo PR

A lot of time and resources were invested in reworking Dyntopo and the feature is in a relatively final state.
Although the rest of the team is busy now, there would be time soon to tackle this as an internal project (if it is still waiting then).
Sergey will still take a few weeks to wrap up compositor work and Hans is taking time off soon.

Dalai asked Sergey to analyze how he would suggest the patch to be split (see below in this document).
This is intended to map out what the initial future step would be for the development team.
But it can also serve as a guideline in case Joe wants to keep iterating on the patch (given that he did a few updates on it since last week).

Split Strategy for Dyntopo

General notes

The presentation of the project needs to be updated.

The project is not about refactoring, but about bringing new functionality: performance and attribute preservation. Refactoring by its definition does not change an external behavior.

The description needs to be updated to become a single-read self-sufficient information. Start with the description of the problem the patch solves, description how it is done.

Referring to state of other branches and their history should be avoided in the general part of the PR description. It is fine to have such information later on (after the “—” marker). It is important to give context about such referring, because reviewers are not familiar with the state and history of code outside of the PR.

Inspirational read:

Splittable parts

Based on a quick pass over the patch and personal experience of structuring projects.

NotForPR

Changes marked as NotForPR should be removed prior to asking for a review.

startup.blend

It is hard to tell what exactly is changed in the file.

A lot of versioning is to be done in the versioning_default.cc. There might be a good reason to update the file, but more information about it is needed.

MSVC + Clang changes

Similar to other platforms and compiler configuration we are open for compilation error fixes. That being said, the compilation fix needs to be submitted and presented separately.

BKE_dyntopo_set.hh

There are likely other places where iteration over unique set of elements is needed, and the implementation does not seem to be bound to Dynamic Topology. Should consider:

  • Make it a BLI primitive
  • Cover it with regression tests
  • Include (rudimentary) benchmarking, similar to the BLI_set_test.cc

BLI_heap_minmax.hh

Move to a separate PR and consider:

  • Expand the description. I.e. it states it does priority queue, so how is it comparable/different from std::priority_queue.
  • Cover with regression tests

BMesh edge collapse

The current PR description states that the current algorithm in the main branch has bugs. Having a more robust edge collapse is a general good improvement to have outside of dyntopo. It should be presented and reviewed from this pesrpective.

The implementation probably needs a re-iteration, as it is a bit strange to generate specializations of such non-trivial algorithm for all types of callbacks.

Edit BMesh fair vertices

It does not seem to be used in the patch, and the intent is not really clear. If this is a new operator which is intended to be exposed it should go into a separate PR.

CD_FLAG_TEMPORARY

Such semantic change should be isolated to own incremental step. This is likely to touch some API changes in the BKE_attribute.h and BKE_customdata.h

ATTR_NO_OPT

Either needs to be completely removed, or presented as a separate PR.

It was mentioned the change was rejected, but I did not find a PR to get more context on this topic.
From personal experience sometimes it is handy to be able to disable optimisation of a specific function during development/troubleshooting. Being able to do so without looking up for an exact syntax sounds good. So to me it does seem to be a reasonable thing to have.

BLI_mempool.h

The patch introduces BLI_mempool_get_size. Is not very clear what the difference from BLI_mempool_len is. If it does something else it needs to go to a separate review.

BMesh tool flags

The belief is that it is possible to extract this part of the patch, keeping it no-functional-changes for the current state, and review it from this perspective.

Doing so will give ability to present the need of such change and understand it and validate more efficiently, as well as removing bulk of changes related on the API change.

geometry_attributes.cc / mesh_data.cc

From reading the code it seems that it is actually a bug fix to something that is already in the main branch: make undo in sculpt mode do what one expect it to do after adding attribute.
If it is indeed so, the change needs to be split and explained what the fix mean on user level.

join_mesh_single

It seems that this is a change which Blender benefits from outside of the dynamic topology project. So seems reasonable to split the change out and review it by the modelling team.

space_image folder

Seems to be a lot of changes, and not needed for the dynamic topology project.

Auto-save changes

Needs to be split out, and seems to be already submitted as #110088
The issue is the performance and UX.

Closing notes

Surely the notes above do not cover the juicy parts of the actual dynamic topology changes. The goal so far was to bring the patch in an easier to review state. With the size of this patch it takes a lot of mental energy to even go over those easy-to-separate changes, and it will be an iterative process to tackle the entirety of the patch.

24 Likes

If there is any relief, it is that Julian starts off with the bad news and then goes on to talk about the plan to get the Dyntopo rewrite into main (even if it means taking other developers off of other modules as soon as their current project is done). He also once and for all stresses that Joseph Eager is still welcome to make commits even though his contract ended early (though likely at a slower pace).

The Multires overhaul and other projects are uncertain at this point, but the new Dyntopo will still allow for high resolution models with the bonus of adaptive subdivision.

11 Likes

Sculpt+SDF

14 Likes

Wip²

5 Likes

I would love shape keys to be a part of these vital features.
Multires shape keys love.

Edit: I don’t know much about developing process and about all that is written here, but it seems the problems flagged by Joe are getting addressed and that people in the meeting are aware of the sculpting module.
Maybe no owner of the module for now but it might even be good that others temporarily throw an eye on it, new ideas and perspectives might come out of the process.

I hope Joe is not traumatized by this experience and that everything from now on takes a positive path, it feels like that is what is happening.

I complain a lot about BF and about things could be better but honestly, in general, I really love that Blender project, the software, the devs and the community.
I just hope one day I can have my shape keys on multiple subdivision levels.
Nevermind that, I just hope time does it’s thing, like usual, of course sooner than later.
I hope for more money for BF, and owner of sculpt module asap.

That era when Pablo was posting videos of new features and improvement almost daily got us spoiled but one can still wish that comes back one day.

3 Likes

Joe added options to brushes.
To me, that is obvious that he had to create defaults for these options ; that may be different from one brush to another.
No Dyntopo option was disabled for most of brushes. But it is enabled for Smooth, Rotate, Slide/Relax, Cloth, Draw Mask, Draw Face Set and Paint brushes…
It was also the case for Weight by Area option.
Brushes not being a bundle of assets from a separated file, that seems logical that startup.blend file was modified.

Entering Sculpt mode will now be faster for big meshes https://projects.blender.org/blender/blender/commit/79115c5c56fa52ff77e6476b37cacd740815be54

15 Likes

PBVH building optimizations as well.
Sculpt: Replace GHash with Map when building PBVH · 69cf65732a - blender - Blender Projects

This may or may not be related to wrapping up Joe Eager’s work on sculpt mode, I would also not be surprised if the new Dyntopo is committed in stages as hinted by the meeting notes.

9 Likes

What? New module owner already? :stuck_out_tongue_winking_eye:

Do you know C++? It could be you someday.

This is also why the BF really needs to get Blender into a position where a lot more patches by volunteers are going in. The conversion to C++, the DNA rework and the termination of the old mailing lists in favor of the forum is a good start. I can easily see someone taking an interest in the sculpt code.

5 Likes

Hans is on fire…
Sculpt: Reduce overhead of PBVH draw with blender::FunctionRef
Sculpt: Parallelize grid bounds calculations for creating PBVH
Sculpt: Remove dynamic topology “Smooth Shading” option


I understand the basics of C++ actually, but Blender’s code base is no joke… ::smile:

7 Likes

Like I hinted at, I wonder how much of this is the finalizing and committing of Joseph’s code (if it is, then the Dyntopo stuff will come in a little later).

How much later will depend since Hans will be on his annual break soon, and Sergey needs to finish up on the compositor rework.

Hi! :slight_smile: This is mostly just me trying to familiarize myself with the sculpt code and spending a bit of time with a profiler in between other projects, it doesn’t really relate to any existing work. Luckily there see to be some low hanging fruit that’s fun to deal with, at least for regular mesh sculpting.

47 Likes

I can’t confirm any improvement. Tested with a 10 million quads mesh on 4.0 alpha from today and 3.6.0. Same (bad) result.

Can someone else check this?

25mil mesh without any custom attributes

4.0 from last week:
Object → Sculpt mode - 00:21.61s
Sculpt → Object mode - 00:07.69s

4.0 from today:
Object → Sculpt mode - 00:15.02s
Sculpt → Object mode - 00:07.11s

16 Likes