Can you explain when you would do that, what the reason for this is? Is it for initial modeling of the rough shape, after which you would “delete lower”? Or is it also for adding fine details?
personally i only do simple first and smooth sub-d later. i also can’t really think of a use case where a simple subdivision of a mid to high poly model brings any advantages. if the simple > catmull workflow is somewhat “easy” to implement to the current multires mod it could be released in parts, later to be expanded with catmull > simple.
2 Likes
It’s mostly to preserve the volume.
It really depends.
Even if I start subdividing in smooth mode, sometimes you already know that your next subdivision might shrink the mesh a little too much, so a flat subdivision in-between helps to control the mesh.
For adding fine details is also very useful, sometimes you just need more polys with no smoothing. Great for hard surface stuff.
One other thing I would like those Smooth/Simple operators to support is localized subdivision. Like, you mask one area and hit subdivide, and the subdivision only happen in that masked (or unmasked) area. Very very useful. That’s another neat feature of zbrush.
3 Likes
+1000
1 Like
And while we are at it, can’t Catmull-Clark be renamed to Smooth in the multires? Sounds more clear to me.
2 Likes
Maybe change both of their names to Smooth and Hard to reflect their intended purpose while subdividing? At least I think that makes the most sense.
“Hard” sounds like something else, I’d go with Smooth and Flat. Sounds familiar huh?
Either option works in my book.
@ThinkingPolygons @Frozen_Death_Knight
It doesn’t even need to be two buttons. Just one Smooth toggle is enough. When enabled = Smooth subdivide, disabled = Flat subdivide.
Less clutter… 
1 Like
Is this the new implementation of the multires that Pablo talked about or is the old one getting patched up? I didn’t think that it would be ready at least for another release but i hope it’s not rushed out before it’s solid.
1 Like
There is no distinction between these things. What works well gets reused, what doesn’t gets replaced. It’s an iterative process. Multires will be better in 2.83, but that doesn’t mean development on it stops.
2 Likes
Few quotes from what’s written on the design task.
Given the fact that, as described here, Multires was never a functional feature for its intended purpose and
The code is extremely hard to read and maintain.
The original Multires comes from before 2.5. The basics of how it should works were never correct and a lot of features and modifications were added during the years.
Some options are:
Replace Multires modifier with a simple implementation based on the SculptGL code (something we know it works) and start again from there.
Try to add this functionality to the current Multires modifier. In that case, the priority should always be supporting the functionality described in this task first, and the bring all the rest of the features back.
This implies that the mulitres will be reworked to something like in SculptGL, a simplified version or patch the old one to a reusable state that had a different purpose than just a subdivision levels for sculpting.
So your reply doesn’t give a precise answer more than it’ll get developed…haven’t you guys agreed on it’s purpose?
For that task, you should only really look at the requirements mentioned by Pablo rather than the suggestions on how to implement it. The SculptGL implementation fails on basic cases (see my comment in the task), so that was not a viable option.
There’s a significant amount of new multires code in 2.83 already, which % of that is new I haven’t counted and it doesn’t really matter either. The plan for further multires development is here:
https://developer.blender.org/T73317
5 Likes
Okay thanks, that clears things up to what direction the mulitres is going to take.
1 Like
Nice work on the volume object, @brecht! Can’t wait to see that utilized for volume sculpting / dynamic topology in Sculpt Mode.
1 Like
It almost certainly would not be used for that. OpenVDB can be used for meshing under the hood, but that does not require a volume object that the user interacts with. It’s just not helpful for either the implementation or UX.
1 Like
That’s a pity. Then I hope Pablo will soon introduce a new way to use voxels for dynamic topology generation now that Dyntopo support has been frozen.
1 Like
Something that would be really nice is to be able to switch from one mesh to another inside of sculpt mode.
In the Edit menu, deselect Lock Object Modes. After that you can Alt + click on a separate object in Sculpt Mode to select it.
