Page MenuHome

Sculpt Mode Multires Design
Confirmed, NormalPublicDESIGN

Assigned To
Authored By
Pablo Dobarro (pablodp606)
Jan 11 2020, 4:23 PM
"Love" token, awarded by Serva."Love" token, awarded by johantri."100" token, awarded by Isfuelo."Burninate" token, awarded by Dir-Surya."Love" token, awarded by Mark_Jackson."Evil Spooky Haunted Tree" token, awarded by AnityEx."Love" token, awarded by bnzs."100" token, awarded by ixd."100" token, awarded by martinium."Cup of Joe" token, awarded by shader."Like" token, awarded by evilvoland."Love" token, awarded by kfir."Love" token, awarded by Tetone."Like" token, awarded by Leul."100" token, awarded by AlRedd."Love" token, awarded by brilliant_ape."Dat Boi" token, awarded by ostapblender."Love" token, awarded by S_Jockey."Love" token, awarded by seaside98."Love" token, awarded by Yegor."100" token, awarded by juantxo."100" token, awarded by Floatharr."Love" token, awarded by siebeneicher."Love" token, awarded by monio."Love" token, awarded by plundh."Love" token, awarded by TheCharacterhero."Love" token, awarded by d.viagi."Love" token, awarded by hadrien."Burninate" token, awarded by 3Rton."Love" token, awarded by dlc17."Love" token, awarded by Kronk."100" token, awarded by tiagoffcruz."Love" token, awarded by ruthwikrao."Love" token, awarded by SecuoyaEx."Love" token, awarded by ReinhardK."Party Time" token, awarded by ThinkingPolygons."Love" token, awarded by dcvertice."Like" token, awarded by Schamph."Love" token, awarded by xrg."100" token, awarded by Brandon777."Love" token, awarded by symstract."Like" token, awarded by mankysee."Party Time" token, awarded by erickblender."Love" token, awarded by RodDavis."Love" token, awarded by andruxa696."Like" token, awarded by MetinSeven."Burninate" token, awarded by lopoIsaac."100" token, awarded by Jaydead."Love" token, awarded by ace_dragon."100" token, awarded by Tonatiuh."Love" token, awarded by radcapricorn."Yellow Medal" token, awarded by amonpaike."Orange Medal" token, awarded by Zino."100" token, awarded by Alrob."Love" token, awarded by Rubens91."100" token, awarded by 616."100" token, awarded by Loner."Like" token, awarded by Regnas."100" token, awarded by knightknight."100" token, awarded by D____JPS."100" token, awarded by Frozen_Death_Knight."Mountain of Wealth" token, awarded by TheRedWaxPolice."100" token, awarded by CobraA.


The purpose of this task is to describe the main uses cases and functionality that should be provided by a Multires sculpting system, as well as to discuss a plan on how to implement that in Blender.

The main use case of Multires

The problem Multires solves

When you are working on any art medium (this also applies for painting), you should always try to work from the general shapes to the details. In case of digital sculpting, this means that you should always try to work with the minimum number of vertices that represent the level of detail you are trying to add to the model.
This is also true for the current workflow we have implemented (The Voxel remesher). By default, it provides a low poly mesh (about 10K vertices), that you should deform trying to get main shape of the object you want. After that, you increase the resolution of the remesher until you have enough vertices to represent the next level of detail you want to work on, and you continue from there.
The reasons you want to work this way are:

  • Performance: It is faster (more responsive, without lag) to deform a mesh with 10K vertices than a mesh with 25M vertices. If you use a big brush size needed to modify the object proportions on 25M vertices at the same time, it is going to lag. (Unrelated note, but we should not try to optimize Sculpt Mode to support these kind of operations as they don’t make any sense with a Multires system in place).
  • (Most important) Noise: If you sculpt with more vertices than needed for the size of details and shapes you are trying to get, you are going to end with a lot of uncontrolled shape noise produced by the tools. This is not a specific problem with Blender brushes and tools, this happens in any software and in every sculpting system. If you use the Draw brush to add some volume on a big area directly onto a 25M vertices mesh, you are going to need need to clean manually all small uncontrolled imperfections that big stroke stroke produced if you want that to be the final surface. If you start sculpting from a sphere with 1M vertices, you are going to spend more time cleaning shape noise than sculpting or the sculpt is just going to look bad. This is why nobody works this way. You don’t generate unintended shape noise if there aren’t enough vertices to represent it.

That is the main problem Multires sculpting solves. With Multires, you are able to choose at any moment the level of detail that is appropriate for the change you want to make in you model, solving both the performance and the noise issues. This gives an artist a huge amount of freedom as you know you can always go back to tweak low frequency details (proportions, general volumes) after sculpting mid/high frequency details (wrinkles, skin alphas...) if you consider that they don’t look right, without loosing any work.

Without this, the rest of the sculpting workflows (the Voxel remesher, Dyntopo) are the same as sculpting with real clay or marble, you can only sculpt bigger first shapes, then mid details and them the small details. If it does not look right, there is not way to fix it, you need to delete what looks wrong and start again. This is why those workflows are often used for concepting general shapes, and you want two switch to Multires as soon as you can. Sculpting a complex model without using Multires, on any software, is extremely (and unnecessarily) hard and it requires an insane amount of skill from the artist to workaround the limitation. It is like sculpting without using undo. It is too risky to create a high poly sculpt with projected alphas without this feature.

In order to solve this problem, the main thing Multires needs to guarantee is that when you sculpt shapes on your model in the appropriate resolution level, all the other levels are updated accordingly to reflect the changes you did. This is what people often refer as ¨detail propagation¨.

Multires Design

When designing a sculpting Multires system that provides the previously mentioned functionality, We need to take the following points into consideration:

  1. All Multires subdivision levels contain valid information (sculpted shapes, mask, colors...) that should never be lost or damaged.
  1. The user wants to modify any subdivision level, at any time, without restrictions (there should not be limits of how much the mesh should be deformed or “not allowed modifications”).
  1. The user wants to delete and rebuild higher/lower subdivision levels in he/she considers that the shape information that level contains is not longer relevant.

For example, if the user wants to do a high poly sculpt, he/she switches to the higher level subdivision possible that the computer allows to create the high frequency detail projecting alphas. When that is done, the user may want to switch to a lower level to tweak proportions, or to a mid level to tweak small volumes with a soft brush. All the work the user put into applying the alphas should be propagated with the lower subdivision level changes with the Multires functionality and the model should look fine.

If, for some reason (a bug or an design issue in the implementation that did not consider point 1), switching and modifying lower levels may introduce mesh artifacts in the higher ones (the ones that contains the alpha projections and high frequency details), it will destroy all the work done previously by the user in that levels.

In that case, the user is again limited to not going back to select the mesh resolution needed for the modifications he/she wants to make in the mesh. A Multires system like this is not solving the intended problem and there is no reason to use it. It provides the same functionality as any of the other sculpting workflows (Voxel, Dyntopo), but even more limited as the user can’t modify the base topology to adapt it to a new shape. It does not have any reason to exist.

If you project requires you to use a fixed predefined topology in your model (for animation, for example), subdividing the mesh manually and deforming it with a cage or a datatransfer provides the same functionality. You can also get a lower subdivision level by duplicating the model and using unsubdivide if you need it for texture baking or animation. This is not the main problem Multires should be trying to solve.

Any unwanted mesh artifact in the detail propagation, no matter how small it is, invalidates all Multires sculpting features and makes it not functional for its intended use case, as it leads to irreparable data corruption.

Current Multires Modifier

Considering the previously design and use case description as valid Multires sculpting system:

  1. Multires in 2.81 does not support switching levels. This invalidates the feature completely and makes it not functional, but prevents the users to corrupt the mesh data if they use it. This is like not having Multires sculpting at all.
  2. Multires in 2.80 creates artifacts and vertex explosions when modifying any level, creating irreparable mesh data corruption. Releasing Blender with Multires in this state and without any visible UI warning could have destroyed the projects of many users in an irreparable way. Luckily, most users were not using it to create their models in the previous versions because it was also not working as intended.
  3. Multires in 2.79 and before creates a visible grid pattern on higher levels when modifying lower ones. This introduces unwanted shape noise and effectively destroys valid sculpted information, making it not functional for its intended use case. Users are limited to work considering of how much they can deform lower levels by the amount of noise they are predicting Multires will produce in the higher ones. This is not something that should be happening in a production ready implementation of the feature.

The most advances tools Blender has right now that were added in the last releases (Quadriflow, Elastic deform, IK Pose brush...) are designed to work with a Multires system:

  • The main purpose of Quadriflow is to produce subdividable geometry for a Multires. When you are done sculpting with Dyntopo/Voxel remesher, where you can’t have the freedom to choose the level of detail you want to work on, you can quickly generate a base mesh, subdivide it and reproject the details back. That way you can tweak again general proportions and low frequency detail.
  • These brush tools are designed to tweak proportions/big shapes of models, which is something you most likely want to do after sculpting more detail to have an idea of how your model looks like. Multires solves that problem.
  • These brushes can’t be used directly on high poly meshes. These tools needs to have disabled some sculpt mode optimizations in order to work, so they are much slower than regular brushes. In fact, if you try to use the IK pose brush directly on a high poly mesh, most likely you are going to run out of memory. If you don’t, it is going to create terrible artifacts between each segment. In order for these brushes to work as intended on high poly meshes, you need to use Multires to switch to a lower level, use the brush, and then switch to a higher level again to get the intended result.

Multires implementation reference

SculptGL contains a valid and functional Multires sculpting implementation. You can try it by sculpting different details at different levels and switching between them, as well as creating and deleting subdivision levels:

This implementation of Multires provides:

  • Detail propagation that works across all levels. You can choose the desired level you want to sculpt on and that deformation is propagated correctly to all subdivision levels. There are not visible artifacts of any kind.
  • You can both create and delete levels in both directions (higher levels and lower levels) with subdivide/delete higher and reverse/delete lower.

These features are the minimum and required a Multires implementation in Blender should provide, as they are pretty much the definition of a Multires sculpting system. Any other Multires related feature or optimization (being part of the modifier stack, baking, shape keys, layers, exporting, reprojection, tool compatibility, Quadriflow...) should always come later. There should not be a design decisions that prioritize any other Multires feature or optimization without having those minimums perfectly working, bug free and functional.


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. I still can’t understand what it is doing in some places or what was the reasoning to make it work that way in the first place.
  • New features are planned that require Multires support (masking tools, vertex colors, visibility operators). Adding Multires support for those features should not be a project bigger than the feature itself. This was the case with most of the 2.81 tools, and probably with the future planned features (Sculpt vertex colors or visibility management, for example)
  • We already have and sculpt tools abstraction layer in place. Making changes on the underlying data structures of sculpt mode should be easier than before
  • 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. We are now trying to build state of the art sculpting features on top of a broken foundation that has more than 10 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. We can keep the current Multires modifier for compatibility, but we need to evaluate if supporting the features and fixes described in this task on the current code (and make it work exactly as the SculptGL Multires) is going to take more time than implementing something based on the SculptGL code from scratch. We also need to look that the new features that are planned and evaluate how hard they are going to be to add to the current Multires code (colors, per face data...) knowing that the SculptGL implementation already supports them.
  • 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. In that case, it would be needed better documentation and code organization to be able to integrate new features into it easily.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I would certainly like to raise... is it really necessary that the multires be a modifier? Given that having more than one modifier of this type is a nonsense and that it is always forced to be the first modifier... wouldn't it be more logical that it simply be a property of the mesh like the vertex groups? Maybe I'm wrong, but I don't see any sense in it being a modifier. Also future sculpt layers could be placed in same mesh tab, like vertex groups or shapes, where have more sense than inside a modifier.

Multires as part of the mesh data sounds good to me - I also see a future where shapekeys can exist at different multires levels, like sculpt layers in other programs - they're really the same thing after all.

And there is another important aspect that I think went unsaid : in rigging, we either use blendshapes or displacement maps (baked from Zbrush multires) to correct deformations or add medium-frequency detail such as wrinkles : if it's a big structural modification/correction, then we're going to use blendshapes ; if it's smaller, superficial/cosmetic change then we're going to use displacement maps. Some corrections however, to be optimal, need a higher resolution than what the basemesh allows - a workflow with multires layers/shapekeys has the potential to completely streamline the creation of both corrective shapes and expressions, as well as everything in-between - so I think it's really essential to consider.
In that case we can imagine that only static, very high frequency detail would be left for rendertime displacement.

From there, it's not a big leap to imagine accessing different multires levels in edit mode as well, although I can see the conversions between edit mesh and sculpt bvh quickly become unmanageable.

I am agree, if multires will have shapekeys support in future, then we need to keep the ability to move the low level of mesh by bones and keep all details of multires on high levels in new bone pose. It will give more possibilities for realistic face rigging for example.
Of course it not should be in the first version of new implantation , but need to keep it in mind at the beginning.

An important aspect of Blender I rarely find someone speaking about. Its about how to push complexity of your project to its limit without freezing your PC.

Some people mentioned idea, that Multires should not be a modifier, but integrated directly into mesh objects.

On smaller projects, we might not bother about space efficiency. But, what happens, if we push a scene to its limits? Imagine a scene with many thousands of mesh objects.

We could apply same way of thinking on question, wether we use (multires) or (subdiv&displace) in our animation projects. A single multires sculpt could eat away 10G memory. Again, for smaller projects you wont need to bother. But if you have a more complex setup, with many objects (10G each), you freeze your machine by depleting its memory.

If we bake a high res model to displacement, it helps us to reduce memory footprint of our scenes.

@Pablo Dobarro (pablodp606)
Overall this all sounds pretty good. One thing that concerns me right now is backwards compatibility.
Like @William Reynish (billreynish) said there is an important use-case for multires at the moment:

IMO one of the main original use-cases for Multires, was as an alternative to using Sub-Ds, but with hierarchical detail. So you can animate, rig and play >back simpler geometry, but render at a higher level. That is one of the core use-cases, which I don't think you mention here.

This is mainly because there is no alternative to this workflow right now since displacement baking is not there yet. But once it is and the old multires has no reason to stay, how will old files, even project files from the Blender Open Movies like Spring react if you open them in a new version of Blender?

I think we need to be careful in this case about being slavish to backwards compatibility. As a developer, I recognize that it's not always smart or sometimes even possible to force yourself to be beholden to the sins of past bad design choices. Sometimes you need to tear things down and start over without being concerned about what effect it's going to have on older work. Do we really have people storming the gate over the fact that you can really only open Sintel in a special Blender branch? I don't think so. Make a breaking change sometimes. It's freeing. The beauty of Blender is that old versions aren't going anywhere for people who want to open legacy data.

Multires for sculpting is good, and baking vector displacement is also good, but one vital use case that is important in Blender (and not important in other pure sculpting apps) is sculpting on a rigged, posed, animated mesh. This is important for animating muscles and such. Blender has no alternative solution for this such as a muscle system or a robust system for rigging physics-simulated objects.

Granted, the old Multires system is bust anyway, so once you get rid of it, you might as well start small. But you should keep this important functionality in mind for the future.

What I get from this proposal is mainly the requirement that propagation must be really reliable. So to be clear, the current code is just broken. There are bugs and incomplete code, so that even the intended algorithms are not working, and those algorithms might not be ideal. For me the interesting discussion is really a technical one, getting down to the actual code and algorithms and figuring out the solutions. And then if it turns out rewriting big parts is needed, so be it.

I looked at SculptGL, and found relatively simple code in these two files. However from reading this task I feel like I'm missing something, because to me it seems these algorithms are rather limited:

For example this basic test:

  • Clear Scene
  • Add Cube

  • Change Resolution from 4 to 1
  • Activate transform tool and rotate 90°
  • Change Resolution from 1 to 4

  • Note corners are now distorted.
  • Undo some steps back to try to get the original cube

  • Note sure what happened there, but I guess undo works by doing reverse operations and the algorithms are not strictly reversible?

Without proper handling of rotations, for example IK posing at lower levels will not work. For animation it's important to handle this kind of rotation case well of course. The implementation can be simpler like SculptGL if it's not important. But from reading the proposal, probably we need something more advanced.

The classic paper about multiresolution mesh editing is this one, it can be a good starting point for those wanting to understand the problem:

@Brecht Van Lommel (brecht) Right, the most important thing is a reliable detail propagation. I mentioned the SculptGL implementation because it has the expected design and behavior for a sculpting multires feature (no need for reshape/apply base, it creates and deletes levels in both directions), and it does not fail when working with brushes. I looked at the code and it also seemed to me that it was simple, so I assumed that it may have limitations like the artifact you mentioned with rotations.

Does the "fixed" version of the current multires modifier have a detail propagation without the SculptGL limitations? Also, some of the mentioned features (like delete lower) are considered as a TODO in the code, so I assume that they are possible to integrate into the current modifier, but I'm not sure if rebuilding lower levels will conflict with some of the existing assumptions (like apply base).

I think that before choosing a solution, we should know how much work different options are going to take to develop, how reliable the result will be and how easy it would be to maintain and integrate with existing and new features (layers, colors, baking, animation...).

I want to remember, that actual blender Multires baking is not reliable, because the bake is incorrect in at least the normal map baking.

mankysee (mankysee) added a comment.EditedJan 17 2020, 12:32 AM

I would like to chime in about the implementation of multires in terms of technical things. I haven't read the paper Brecht provided and haven't look into the code of the current multires system but from my user point of view implementation of something in vein of ptex would be the next best thing since it's fairly simple to implement for a quad-based mesh(its just a ptex with vertex displacement data instead of colored pixels), it supports animation pipelines and allow a user to go up and down in resolution at any given time.

the downside of this that the modification of the mesh after ptex multires created upon it can be difficult although it's something that needs to be investigated.

@mankysee (mankysee) I'd avoid ptxes by any means. Long story short, any scenario that I've experienced throughout my career with ptxes was a huge pain.

Why bother with an image-based format, especially one with such widely known performance and implementation limitations as PTex? There's no reason multires data can't be encoded directly into mesh data structures.

Why bother with an image-based format, especially one with such widely known performance and implementation limitations as PTex? There's no reason multires data can't be encoded directly into mesh data structures.

I think the important part is not PTex as such, but merely the separation of the vector displacement data from the tessellation scheme. An image format of some sort is good because it's well understood by users and relatively easy to edit, import and export. Additionally, with images you can easily visualize and debug the displacement data, and manipulate it with texture nodes in the future. Also makes layers simple.

A plain old UV-based image can be used as well as long as the initial automatic unwrap can be made quick, reliable and not too wasteful. That places some limitations on the extent of basemesh editing that can be done after starting to sculpt, but these limitation are again well understood thanks to users' experience with uvs in texturing, and can be mitigated with solid baking tools.

mankysee (mankysee) added a comment.EditedJan 24 2020, 11:54 AM

Why bother with an image-based format, especially one with such widely known performance and implementation limitations as PTex? There's no reason multires data can't be encoded directly into mesh data structures.

I think the important part is not PTex as such, but merely the separation of the vector displacement data from the tessellation scheme. An image format of some sort is good because it's well understood by users and relatively easy to edit, import and export. Additionally, with images you can easily visualize and debug the displacement data, and manipulate it with texture nodes in the future. Also makes layers simple.

Yes, that's what I meant more or less. Ptex is a good example not in an actual implementation but of the principle of generating textures without the need of additional work required to map such images.

In terms of an actual implementation I can imagine a system generating uvs for each subdivided quad and applying sparse textures on top of those. Something not unlike Zbrush is doing(under the hood it's using subdivided meshes and displacement textures of some kind containing various information like depth, orientation and so forth).

It's interesting that @Alberto Velázquez (dcvertice) should mention multi-res baking. Having done some poking around in the baking code myself, it seems multi-res baking is a major branch in the bake code that complicates things tremendously. I think it's one of the few parts of Blender that still uses DerivedMesh. Removing this branch in the bake code by redesigning multi-res may have the benefit of making it easier to design features like AOV baking, bake denoise, etc.

I'm of the opinion that there's no reason to maintain compatibility if the feature was broken to begin with. If people want to bring multi-res meshes in from older versions of Blender, they will probably still be able to do so by saving the various levels of subdivision and applying the shapes to the new multi-res modifier (perhaps this could even be automated somehow).

Aaron Carlisle (Blendify) changed the task status from Needs Triage to Confirmed.Feb 17 2020, 8:21 PM

It sounds to me that the old multires modifier is built on a weak foundation and that maintaining it is increasingly difficult and more effort than is worth doing.

The path forward seems obvious: build a new multires from scratch on top of a strong foundation. Whether that means using SculptGL as a base or something else entirely is up to the implementer.

  1. Quickly getting a working multitres into Blender for sculpting is a high priority.
  2. Having the strong foundation in place will then allow additional feature development on top of the new multires to come after.
  3. However, the old multires should also exist for backwards compatibility. Over time we might rebuild old features/workflow into the new multires on top of the strong foundation, at which point the old multires will become redundant and can be deprecated.

Hello, any idea when work on this is going to start?

I support the first option. Starting clean with SculptGL base implementation and then add more features with time. It is very often the case with other older software that rely on very old code, always dragging its limitations and issues forward instead of starting clean with fast code...