Multires design validation #84864

New Issue

Pablo Dobarro · 2021-01-19T15:25:07+01:00

Pablo Dobarro commented

2021-01-19 15:25:07 +01:00

The goal of this tasks is to validate the design of Multires as Blender's main subdivision based sculpting system.

In order to do that, I'm not focusing on the current state of Multires taking into account its current implementation (bugs, missing features, technical debt), but on the design of Multires itself. The idea here is to ask the question “if Multires was working exactly as intended (no bugs, no TODOs, all possible optimizations...), is that what we want for the sculpting/painting modes?”

Pros

Tangent space sculpting layers: This is a feature that even specialized software doesn't support and which is really important for retouching VFX animation. By having multiple CD_MDISP datalayer, it should be possible to tweak the influence of each one of them on the final displacement. As these layers are in tangent space, this supports any transformation on the base mesh without applying the layers displacement in random directions.
Supports features that require base + displacement: Features like displacement eraser or displacement smear rely on having the sculpt geometry stored as a base and a displacement. The current Multires design makes supporting these features straightforward. When Multires is not being used, it is still possible to implement these brushes by creating an operator that generates a base (by smoothing the mesh multiple times) and a displacement. So, this is not a feature that relies on the design of Multires, but it makes it better integrated.
Sculpting and rendering different levels: It is possible to use sculpt mode to deform the limit surface and let the modifier evaluate the displacement of other level. With a delete lower operator and unsubdivide, it should be possible to create a temporally base mesh for any level so it can be sculpted as a limit surface.
Easy to integrate with rigs: For the rest of the animation system, multires is just like having a vector displacement texture on top of a model. Animating models with sculpted displacement does not require any further workflow or features from other modules.
Saves a lot of memory: As it does not store any topology information for the higher levels of the sculpt, it is memory efficient both when sculpt mode is in use and when saving the files.
Faster PBVH building times: as the BVH primitives are the grids, building the tree is faster than building it for the individual triangles of a mesh.

Cons

No references or indices for edges and loops: Mesh algorithms that require storing information or topology queries based on edges can't be implemented. This means like features like fairing, geodesic distances or a better cloth solver can't be directly available from the SculptSession (I still don't understand why the current cloth solver works, but its performance is really bad). In order to have those features working, I can only think of workarounds like converting the grids to a mesh or adding some kind of map to store the grids topology as edges and vertex references, which adds extra code that needs to be maintained and misses the point of using grids directly to save memory.
Computed and displayed resolution does not match: When working on level 1 of a quad mesh, all vertices will have 4 duplicates which will be deformed independently when computing the brushes and tools. For the user, this means that performance and vertex count won’t match the sculpt mesh that is being rendered. This makes Multires usually slower on level 1 than on level 5. It also creates unexpected results when adding a single subdivision to a mid/high poly mesh, as the vertex count will increase at a rate users won’t expect.
Allows vertices with invalid data state: This design allows to have a vertex with multiple mask, colors or visibility values. This can be solved with stitching the grids, but this should be something that the design should not allow. It is the cause of constant bugs in all tools that require storing data per vertex. (see #79317)
Performance depending on grids dimensions: In lower levels (on a 2x2 grid), the number of duplicates exposed to the tools is so high that creates performance problems. When the grids are too big, performance decreases because the tool iterations are per grid. This causes that multires optimal performance is only achieved in levels around 5. This is something that users don't expect. For example, subdividing 4 vert plane 8 times will create a reasonable vertex count for sculpting, but because grids at level 8 are so big, sculpt mode will always update at least a quarter of the plane regardless of the size of the brush.
PBVH limited to building per grid: In order to get the PBVH building speed, grids are used as primitives. This means that the number of nodes can't never be higher than the number of grids. On higher multires levels, this is a problem as the PBVH can't have as many nodes as it should for optimal performance.
Undefined behavior with undo and shape keys: The relation between shape keys in the base mesh, sculpt layers and multiple CD_MDISP layers is not clear. We don't know if shape keys should also contain the info about the displacement of the grids, if they should only deform the base mesh or both. What undo should do with features like propagation and reshaping from sculpt mode is also not clear.
Incompatible design with automatic apply base: With the current Multires design it makes total sense to not apply the deformation to the base mesh automatically. The workflow is more similar to painting a displacement texture than to subdivision based sculpting. As it is exposed in the UI as it was a standard subdivision based sculpting system, this often confuses users. As the main use case for having subdivisions in sculpt mode is to be able to control the surface noise, it does not make much sense that level 0 is not directly available for that.
Unpredictable displacement interpolation in edit mode: (To be checked with @JosephEagar ). It looks like it may not be possible to properly implement grid interpolation in edit mode due to numerical stability problems.
No support for other custom data layers: The only datalayer that is supported in Multires is the mask, which is hard coded. Multires does not have any system in place to support editable datalayers in the grids. Mode info in #80609.
Depends on editable limit surface: As the high poly version of the sculpt is stored as displacement on top of the limit surface, any other Blender tool that changes the limit surface will break it without any warning to the user (for example, changing the crease values in Edit mode). See #81958
Extremely hard to develop and maintain: Blender most advanced sculpting tools don't rely that much on displacing vertices, but more on topology algorithms for calculating transformations (pose, relax, boundary, expand...). Making and debugging these tools to work on grids usually takes 70% of their development time (I measure it when developing the boundary brush). A feature that may require a slightly different topology query (which is often trivial to implement for Mesh) requires an amount of development for Multires that is usually bigger than the tool itself.
No friendly workflow with other softwares: Having surface detail stored as displacement in Multires is convenient to work inside Blender, but what other software expect is to handle surface detail at render time with UDIMS and vector displacement textures (Blender supports both). If you have an animated scene with multires, for exporting it to other software you need to bake all the displacement at its highest resolution per frame, which is not ideal. Even if Multires displacement data can be stored as a separate file, it can't be read by any other render engine.

My opinion

The main technical limitations are about exposing the grids directly to the sculpting code. Because of this, I think that it makes sense for Multires to be used as a different feature. By design, Multires use case is closer to being an alternative to vector displacement for rendering than to a subdivision based sculpting system. To me, it makes sense for Multires to support features like storing displacement into the grids, baking the deformation of modifiers to the grids, reshaping a base mesh based on a displacement, unsubdividing and storing the grids as separate files (it already does all that). What I don't see any value is in being able to edit the grids displacement directly with the tools. For users, Multires should be exposed in the UI as something similar to baking a vector displacement texture to use in rendering, or “ptex based displacement”. After the fixes and the features added in 2.90, Multires is completely functional for this use case.

I would rather prefer starting discussing the design of a dedicated subdivision based sculpting system and leave Multires for what it does well instead of keep trying to add workarounds a hacks to make it meet the requirements of something that was not designed for. We need to consider that supporting the existing and planned features (like sculpt vertex colors or layers) in the current Multires will take a lot of development time that can be used for something else.

For Multires, I imagine the workflow to be like:

The user creates a subdivision based sculpt with a dedicated subdivision based sculpting system (not Multires).
When done, the user adds a Multires modifier to the high poly version and uses rebuild subdivisions. This will convert the sculpt to a base mesh + displacement. It is the same concept as baking a displacement texture from the high poly mesh into level 0, but slightly more convenient as it does not require UVs and geometry will look exactly the same as the sculpt.
After having the new low res based mesh, the user can rig and animate the mesh with displacement.

The goal of this tasks is to validate the design of Multires as Blender's main subdivision based sculpting system. In order to do that, I'm not focusing on the current state of Multires taking into account its current implementation (bugs, missing features, technical debt), but on the design of Multires itself. The idea here is to ask the question “if Multires was working exactly as intended (no bugs, no TODOs, all possible optimizations...), is that what we want for the sculpting/painting modes?” ## Pros - **Tangent space sculpting layers**: This is a feature that even specialized software doesn't support and which is really important for retouching VFX animation. By having multiple `CD_MDISP` datalayer, it should be possible to tweak the influence of each one of them on the final displacement. As these layers are in tangent space, this supports any transformation on the base mesh without applying the layers displacement in random directions. - **Supports features that require base + displacement**: Features like displacement eraser or displacement smear rely on having the sculpt geometry stored as a base and a displacement. The current Multires design makes supporting these features straightforward. When Multires is not being used, it is still possible to implement these brushes by creating an operator that generates a base (by smoothing the mesh multiple times) and a displacement. So, this is not a feature that relies on the design of Multires, but it makes it better integrated. - **Sculpting and rendering different levels**: It is possible to use sculpt mode to deform the limit surface and let the modifier evaluate the displacement of other level. With a delete lower operator and unsubdivide, it should be possible to create a temporally base mesh for any level so it can be sculpted as a limit surface. - **Easy to integrate with rigs**: For the rest of the animation system, multires is just like having a vector displacement texture on top of a model. Animating models with sculpted displacement does not require any further workflow or features from other modules. - **Saves a lot of memory**: As it does not store any topology information for the higher levels of the sculpt, it is memory efficient both when sculpt mode is in use and when saving the files. - **Faster PBVH building times**: as the BVH primitives are the grids, building the tree is faster than building it for the individual triangles of a mesh. ## Cons - **No references or indices for edges and loops**: Mesh algorithms that require storing information or topology queries based on edges can't be implemented. This means like features like fairing, geodesic distances or a better cloth solver can't be directly available from the `SculptSession` (I still don't understand why the current cloth solver works, but its performance is really bad). In order to have those features working, I can only think of workarounds like converting the grids to a mesh or adding some kind of map to store the grids topology as edges and vertex references, which adds extra code that needs to be maintained and misses the point of using grids directly to save memory. - **Computed and displayed resolution does not match**: When working on level 1 of a quad mesh, all vertices will have 4 duplicates which will be deformed independently when computing the brushes and tools. For the user, this means that performance and vertex count won’t match the sculpt mesh that is being rendered. This makes Multires usually slower on level 1 than on level 5. It also creates unexpected results when adding a single subdivision to a mid/high poly mesh, as the vertex count will increase at a rate users won’t expect. - **Allows vertices with invalid data state**: This design allows to have a vertex with multiple mask, colors or visibility values. This can be solved with stitching the grids, but this should be something that the design should not allow. It is the cause of constant bugs in all tools that require storing data per vertex. (see #79317) - **Performance depending on grids dimensions**: In lower levels (on a 2x2 grid), the number of duplicates exposed to the tools is so high that creates performance problems. When the grids are too big, performance decreases because the tool iterations are per grid. This causes that multires optimal performance is only achieved in levels around 5. This is something that users don't expect. For example, subdividing 4 vert plane 8 times will create a reasonable vertex count for sculpting, but because grids at level 8 are so big, sculpt mode will always update at least a quarter of the plane regardless of the size of the brush. - **PBVH limited to building per grid**: In order to get the PBVH building speed, grids are used as primitives. This means that the number of nodes can't never be higher than the number of grids. On higher multires levels, this is a problem as the PBVH can't have as many nodes as it should for optimal performance. - **Undefined behavior with undo and shape keys**: The relation between shape keys in the base mesh, sculpt layers and multiple `CD_MDISP` layers is not clear. We don't know if shape keys should also contain the info about the displacement of the grids, if they should only deform the base mesh or both. What undo should do with features like propagation and reshaping from sculpt mode is also not clear. - **Incompatible design with automatic apply base**: With the current Multires design it makes total sense to not apply the deformation to the base mesh automatically. The workflow is more similar to painting a displacement texture than to subdivision based sculpting. As it is exposed in the UI as it was a standard subdivision based sculpting system, this often confuses users. As the main use case for having subdivisions in sculpt mode is to be able to control the surface noise, it does not make much sense that level 0 is not directly available for that. - **Unpredictable displacement interpolation in edit mode**: (To be checked with @JosephEagar ). It looks like it may not be possible to properly implement grid interpolation in edit mode due to numerical stability problems. - **No support for other custom data layers**: The only datalayer that is supported in Multires is the mask, which is hard coded. Multires does not have any system in place to support editable datalayers in the grids. Mode info in #80609. - **Depends on editable limit surface**: As the high poly version of the sculpt is stored as displacement on top of the limit surface, any other Blender tool that changes the limit surface will break it without any warning to the user (for example, changing the crease values in Edit mode). See #81958 - **Extremely hard to develop and maintain**: Blender most advanced sculpting tools don't rely that much on displacing vertices, but more on topology algorithms for calculating transformations (pose, relax, boundary, expand...). Making and debugging these tools to work on grids usually takes 70% of their development time (I measure it when developing the boundary brush). A feature that may require a slightly different topology query (which is often trivial to implement for `Mesh`) requires an amount of development for Multires that is usually bigger than the tool itself. - **No friendly workflow with other softwares**: Having surface detail stored as displacement in Multires is convenient to work inside Blender, but what other software expect is to handle surface detail at render time with UDIMS and vector displacement textures (Blender supports both). If you have an animated scene with multires, for exporting it to other software you need to bake all the displacement at its highest resolution per frame, which is not ideal. Even if Multires displacement data can be stored as a separate file, it can't be read by any other render engine. ## My opinion The main technical limitations are about exposing the grids directly to the sculpting code. Because of this, I think that it makes sense for Multires to be used as a different feature. By design, Multires use case is closer to being an alternative to vector displacement for rendering than to a subdivision based sculpting system. To me, it makes sense for Multires to support features like storing displacement into the grids, baking the deformation of modifiers to the grids, reshaping a base mesh based on a displacement, unsubdividing and storing the grids as separate files (it already does all that). What I don't see any value is in being able to edit the grids displacement directly with the tools. For users, Multires should be exposed in the UI as something similar to baking a vector displacement texture to use in rendering, or “ptex based displacement”. After the fixes and the features added in 2.90, Multires is completely functional for this use case. I would rather prefer starting discussing the design of a dedicated subdivision based sculpting system and leave Multires for what it does well instead of keep trying to add workarounds a hacks to make it meet the requirements of something that was not designed for. We need to consider that supporting the existing and planned features (like sculpt vertex colors or layers) in the current Multires will take a lot of development time that can be used for something else. For Multires, I imagine the workflow to be like: - The user creates a subdivision based sculpt with a dedicated subdivision based sculpting system (not Multires). - When done, the user adds a Multires modifier to the high poly version and uses rebuild subdivisions. This will convert the sculpt to a base mesh + displacement. It is the same concept as baking a displacement texture from the high poly mesh into level 0, but slightly more convenient as it does not require UVs and geometry will look exactly the same as the sculpt. - After having the new low res based mesh, the user can rig and animate the mesh with displacement.

Brecht Van Lommel commented

2021-01-19 18:51:07 +01:00

I don't think there is much point changing Multires to be aimed at animation and rendering. It's not much used for that or really suitable, and for interop with other apps and renderers it's not the right format anyway.

There's two distinct types of issue being mentioned here.

One is the multires data structure used in sculpt mode. It's more memory efficient but also complicated to work with. If approximate double memory usage is an acceptable trade-off for having all sculpt tools working and more easily development in the future, then D5491: Multires: remove CCG grids storage for sculpting, use Mesh instead could be reconsidered. There are likely memory optimizations possible that benefit both regular meshes and multires, as hinted in the comments there, to get it somewhat closer.

The other is various issues with the multires implementation. If there's a concrete idea for another subdivision system that's interesting, but without that it's impossible to evaluate pros and cons between the systems.

I don't think there is much point changing Multires to be aimed at animation and rendering. It's not much used for that or really suitable, and for interop with other apps and renderers it's not the right format anyway. There's two distinct types of issue being mentioned here. One is the multires data structure used in sculpt mode. It's more memory efficient but also complicated to work with. If approximate double memory usage is an acceptable trade-off for having all sculpt tools working and more easily development in the future, then [D5491: Multires: remove CCG grids storage for sculpting, use Mesh instead](https://archive.blender.org/developer/D5491) could be reconsidered. There are likely memory optimizations possible that benefit both regular meshes and multires, as hinted in the comments there, to get it somewhat closer. The other is various issues with the multires implementation. If there's a concrete idea for another subdivision system that's interesting, but without that it's impossible to evaluate pros and cons between the systems.

Pablo Dobarro commented

2021-01-19 19:21:55 +01:00

If approximate double memory usage is an acceptable trade-off for having all sculpt tools working and more easily development in the future

I think that the double memory usage may not be a problem. When working with those resolutions using ##Mesh## usually the multicore design and drawing code become a bottleneck before an average configured computer runs out of memory.
From my experience, I made sculpts only using the voxel remesher (all objects always at max resolution, no Multires) with around 10M vertices on a 16GB laptop without swap and it was working just fine. This is something that can be tested by more people, but I think they won't expect to work on sculpt VFX assets with computers with less than 32GB.

The other is various issues with the multires implementation. If there's a concrete idea for another subdivision system that's interesting, but without that it's impossible to evaluate pros and cons between the systems.

Not sure if this makes sense or if it is feasible, but I would attempt to do something like this:

Remove Multires Modifier, move the subdivision levels to a property of ##Mesh##
Assume that an original ##Mesh## datablock can have multiple sets of arrays, but only one of them active at a time, which will be set to the current mesh arrays pointers in the struct
When adding/removing a datalayer, it is added to all mesh arrays of that same datablock. This should solve all custom data sync issues as it should be possible to assume that the mesh at an any level always has the same data available.
When changing subdivision of ##Mesh##, the propagation updates runs, it changes the references of the datablock to point at other arrays and rebuild the SculptSession.
Level 0 is just another level without any special meaning, so concepts like apply base and base + displacement should not be needed anymore. The propagation code needs to be updated to take this into account.
This same concept can also be used to implement Keymesh. In fact, this is similar to how Grease Pencil datablock change their content depending on the frame.

> If approximate double memory usage is an acceptable trade-off for having all sculpt tools working and more easily development in the future I think that the double memory usage may not be a problem. When working with those resolutions using ##Mesh## usually the multicore design and drawing code become a bottleneck before an average configured computer runs out of memory. From my experience, I made sculpts only using the voxel remesher (all objects always at max resolution, no Multires) with around 10M vertices on a 16GB laptop without swap and it was working just fine. This is something that can be tested by more people, but I think they won't expect to work on sculpt VFX assets with computers with less than 32GB. > The other is various issues with the multires implementation. If there's a concrete idea for another subdivision system that's interesting, but without that it's impossible to evaluate pros and cons between the systems. Not sure if this makes sense or if it is feasible, but I would attempt to do something like this: - Remove Multires Modifier, move the subdivision levels to a property of ##Mesh## - Assume that an original ##Mesh## datablock can have multiple sets of arrays, but only one of them active at a time, which will be set to the current mesh arrays pointers in the struct - When adding/removing a datalayer, it is added to all mesh arrays of that same datablock. This should solve all custom data sync issues as it should be possible to assume that the mesh at an any level always has the same data available. - When changing subdivision of ##Mesh##, the propagation updates runs, it changes the references of the datablock to point at other arrays and rebuild the SculptSession. - Level 0 is just another level without any special meaning, so concepts like apply base and base + displacement should not be needed anymore. The propagation code needs to be updated to take this into account. - This same concept can also be used to implement Keymesh. In fact, this is similar to how Grease Pencil datablock change their content depending on the frame.

Brecht Van Lommel commented

2021-01-22 15:17:39 +01:00

In #84864#1096727, @PabloDobarro wrote:

Assume that an original ##Mesh## datablock can have multiple sets of arrays, but only one of them active at a time, which will be set to the current mesh arrays pointers in the struct

This pushes the complexity elsewhere, and I expect that the overall complexity would be significantly higher. Almost every mesh operation mode would need synchronization between the levels.

It would also likely mean that no topology changes are allowed in edit mode, since I'm not sure how you could practically sync them.

> In #84864#1096727, @PabloDobarro wrote: > - Assume that an original ##Mesh## datablock can have multiple sets of arrays, but only one of them active at a time, which will be set to the current mesh arrays pointers in the struct This pushes the complexity elsewhere, and I expect that the overall complexity would be significantly higher. Almost every mesh operation mode would need synchronization between the levels. It would also likely mean that no topology changes are allowed in edit mode, since I'm not sure how you could practically sync them.

Pablo Dobarro commented

2021-02-01 19:12:18 +01:00

@brecht I don't think the automatic handling of subdivision levels when changing the mesh topology is a realistic goal for us. Even if it was working to some extend (like the current multires), it is still too unpredictable to be useful. In most workflows, if you change the base mesh topology, you are already expeting to do a reprojection of the details afterwards. We can have tools to facilitate this task, but I don't think this functionality needs to be build into the data structure.

Even if the "convert grids to mesh internally" is a possible solution to facilitate the development of new tools, we need to consider the following:

The performance of switching levels and switching objects will be significantly worse, and that is already a problem when working with high poly scenes. See #81989
We need to think how Face Set propagation will work across levels (not that important, picking the highest value ID from the higher level mesh should work just fine)
About memory usage, for making some of the tools work using ##Mesh## I already need 3 extra mesh maps on top of ##Mesh##. By doing this change we are kind of committing to use ##Mesh## as the default mesh representation for high poly sculpting, and I'm not sure if that is ideal.

In order to tackle this properly, I was considering that maybe it is worth to invest a little bit more time into writing a custom mesh representation for sculpt mode and do the code to convert both ##Mesh## and grids to it, instead of converting to ##Mesh##. We now have tools complex enough that provide a well defined set of requirements to at least have an idea on were to start designing it. I would like to start moving the code and how sculpt mode works in general into this direction https://developer.blender.org/rBf68493f5bee352d4a7feb90c2488a264607c84ac

@brecht I don't think the automatic handling of subdivision levels when changing the mesh topology is a realistic goal for us. Even if it was working to some extend (like the current multires), it is still too unpredictable to be useful. In most workflows, if you change the base mesh topology, you are already expeting to do a reprojection of the details afterwards. We can have tools to facilitate this task, but I don't think this functionality needs to be build into the data structure. Even if the "convert grids to mesh internally" is a possible solution to facilitate the development of new tools, we need to consider the following: - The performance of switching levels and switching objects will be significantly worse, and that is already a problem when working with high poly scenes. See #81989 - We need to think how Face Set propagation will work across levels (not that important, picking the highest value ID from the higher level mesh should work just fine) - About memory usage, for making some of the tools work using ##Mesh## I already need 3 extra mesh maps on top of ##Mesh##. By doing this change we are kind of committing to use ##Mesh## as the default mesh representation for high poly sculpting, and I'm not sure if that is ideal. In order to tackle this properly, I was considering that maybe it is worth to invest a little bit more time into writing a custom mesh representation for sculpt mode and do the code to convert both ##Mesh## and grids to it, instead of converting to ##Mesh##. We now have tools complex enough that provide a well defined set of requirements to at least have an idea on were to start designing it. I would like to start moving the code and how sculpt mode works in general into this direction https://developer.blender.org/rBf68493f5bee352d4a7feb90c2488a264607c84ac

Brecht Van Lommel commented

2021-02-01 19:43:31 +01:00

A better mesh representation in sculpt mode would make sense, at least the current adjacency data overhead is quite bad.

The commit you are referencing no longer exists, so I don't know what's in there.

The biggest cost in conversion is going from tangent space to object space coordinates and back. Changing the design to store coordinates in object space to avoid this cost is something that could be done, without storing arrays for every level. What it would mean is that e.g. rotating objects in edit mode or using a deforming modifier on the base mesh either would not work well, or would need additional code and become slower and more complex. That may be an acceptable trade-off.

A better mesh representation in sculpt mode would make sense, at least the current adjacency data overhead is quite bad. The commit you are referencing no longer exists, so I don't know what's in there. The biggest cost in conversion is going from tangent space to object space coordinates and back. Changing the design to store coordinates in object space to avoid this cost is something that could be done, without storing arrays for every level. What it would mean is that e.g. rotating objects in edit mode or using a deforming modifier on the base mesh either would not work well, or would need additional code and become slower and more complex. That may be an acceptable trade-off.

Pablo Dobarro commented

2021-02-01 20:07:02 +01:00

If that means moving the overhead from the level/object switching to edit mode or deform modifiers transformations, I think that is totally reasonable. We will loose the "Sculpt base mesh" features and the potential ability to sculpt and preview different levels, but I would rather have the expected basics working in a more predictable way.
Maybe I can start a different design task for the requirements of this data structure?

If that means moving the overhead from the level/object switching to edit mode or deform modifiers transformations, I think that is totally reasonable. We will loose the "Sculpt base mesh" features and the potential ability to sculpt and preview different levels, but I would rather have the expected basics working in a more predictable way. Maybe I can start a different design task for the requirements of this data structure?

Brecht Van Lommel commented

2021-02-01 20:32:28 +01:00

It doesn't hurt to create a task, it's up to you and Dalai to figure out what to prioritize in sculpt development.

I'm not sure you necessarily lose particular features, it depends. In theory you can do the same things but performance, memory usage and effort to implement are different.

It doesn't hurt to create a task, it's up to you and Dalai to figure out what to prioritize in sculpt development. I'm not sure you necessarily lose particular features, it depends. In theory you can do the same things but performance, memory usage and effort to implement are different.

Dalai Felinto commented

2021-02-02 18:08:53 +01:00

(for the records, the commit Pablo was referring to is: P1939)

(for the records, the commit Pablo was referring to is: [P1939](https://archive.blender.org/developer/P1939.txt))

Julien Kaspar added this to the Sculpt, Paint & Texture project 2023-02-08 10:20:48 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Multires design validation #84864

Pros

Cons

My opinion