Page MenuHome

Multires
Confirmed, HighPublicTO DO

Tokens
"Love" token, awarded by d.viagi."Love" token, awarded by Isfuelo."Love" token, awarded by cfnjrey."Love" token, awarded by gilberto_rodrigues."Love" token, awarded by dbystedt."Burninate" token, awarded by Dir-Surya."Love" token, awarded by Rasta."Love" token, awarded by RC12."Like" token, awarded by wevon."Love" token, awarded by ebarranco."Love" token, awarded by monio."Party Time" token, awarded by franMarz."Burninate" token, awarded by sid350."Pterodactyl" token, awarded by Way."Love" token, awarded by 3dline."Love" token, awarded by bnzs."Burninate" token, awarded by ostapblender."Love" token, awarded by Yegor."Love" token, awarded by Dangry."Love" token, awarded by plundh."Love" token, awarded by jubi."Burninate" token, awarded by martinium."Love" token, awarded by Shimoon."Love" token, awarded by ate1."Love" token, awarded by RyanJEC."Love" token, awarded by alfredbaudisch."Love" token, awarded by bintang."Love" token, awarded by dlc17."Love" token, awarded by brilliant_ape."100" token, awarded by 616."Burninate" token, awarded by Pipeliner."Love" token, awarded by unumex."Love" token, awarded by Floatharr."Love" token, awarded by tiagoffcruz."Love" token, awarded by nunoconceicao."Love" token, awarded by kfir."Y So Serious" token, awarded by ThinkingPolygons."Grey Medal" token, awarded by Regnas."Love" token, awarded by Blendork."Love" token, awarded by Schamph."Love" token, awarded by LukeD."Like" token, awarded by CobraA."Like" token, awarded by MetinSeven."Love" token, awarded by oobma."Love" token, awarded by lopoIsaac."Love" token, awarded by jfmatheu."Like" token, awarded by Frozen_Death_Knight."Like" token, awarded by Ztreem."Love" token, awarded by Jaydead."Love" token, awarded by RodDavis."Love" token, awarded by Alrob."Love" token, awarded by siebeneicher."Love" token, awarded by xrg."Love" token, awarded by andruxa696.
Authored By
Dalai Felinto (dfelinto)
Jan 22 2020, 3:53 PM

Description

Status: Multires algorithms are implemented, need work on Undo to allow sculpt on non-top level


Team

Commissioner: @Pablo Dobarro (pablodp606)
Project leader: @Sergey Sharybin (sergey)
Project members: @Brecht Van Lommel (brecht)

Description

Big picture: Support non-destructive sculpting in different levels of detail for skinned characters preserving a base mesh for baking and animation.

Use cases:

  • Sculptor working in different resolution levels.
  • Animation and playback of base meshes, in fully sculpted characters.

Design:

All the operations (Sculpting, Apply Base, Subdivide, propagation) should be using the same tangent space of the base mesh. This way there will be no inducted artifacts caused by differences between the way how old algorithms were calculating tangent space and how it's happening in the new subdivision surface code.

Propagation should be using Catmull-Clark smoothing of sculpted mesh and propagate changes to the top level.

Engineer plan:

  • Memory/performance optimization
  • Enable optimal display by default in subsurf and multires modifiers
  • Don't allow editing Quality after subdivision is done
  • Don't allow editing simple/catmull-clark and quality after subdivision is done
  • Remove simple mode, and replace with a way to apply simple subdivision as an operation (modifying multires or a base mesh)
  • Fix undo bugs for switching between multires levels
  • Re-enable editing of intermediate sculpt levels
  • Always auto apply base when sculpting, instead of having a button for it
  • Investigate if propagation is need for edits in edit mode
  • Investigate how to support "Apply Base" for meshes with shapekeys
Work plan

Time estimate: 1 month


Relevant links:

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Aaron Carlisle (Blendify) changed the task status from Needs Triage to Confirmed.Jan 29 2020, 11:43 PM
Aaron Carlisle (Blendify) changed the subtype of this task from "Report" to "To Do".
Yegor (Yegor) added a subscriber: Yegor (Yegor).
Way awarded a token.Mar 6 2020, 4:55 PM

I was going to post a bug but it is already solved. In version 2.82 a vertex with 2 egdes generated a hole when deforming with Subsurf, but not with Multires.
When trying to report this error I have noticed that in version 2.83 the same model is not smoothed in the same way with Subsurf as in Multires. I thought the algorithm was the same.
I upload the file in case you want to investigate.



Multires = Subsurf Modifier + displacement. So in this regard yes, the subdivision algorithm is exactly the same, and it works on the same input mesh.

The tricky part is that "Subdivide" button on multires modifier is intended to preserve all details, and keep them smooth. This is done by applying subdivision surface on the currently top level you are subdividing from. This generates nice smooth displacement (there is an extra step is involved to have the new smooth displacement to work from the original multires base mesh, but that's details).

You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier.
So algorithm is not the same since the endgoal of it is different.

You can think of it as if you temporary add subsurf modifier with subdivision level one and then "merge" it into the multires modifier.

True. If the quality parameters are the same, the two meshes coincide, when applying each step of the subdivision. Thanks for the explanation.

Some notes about the engineering plan:

  • I think we should focus on having the unsubdivide operator available as soon as possible when working on the development of sculpting across multiple levels. The issue is that we almost have no production Blender files sculpted from start to finish in Multies, so we can't really validate if the propagation is working as it should in real use cases. With unsubdivide, we can import high poly sculpted meshes with surface detail that were subdivided in any other sculpting software and rebuild all levels inside Blender Multires. Also, once we are able to import sculpting projects, we can evaluate a lot better what is the status of the sculpting system in general (can that file be edited without lag, does it work with a reasonable amount of memory, how much time does it take to switch between modes...)
  • I would left all Shape Keys related features for later after we have a more clear design for Multires sculpting layers in T68898. Shape Keys and sculpt layers are fundamentally the same concept, so maybe we can solve those problem with a conversion operator from a shape key to a sculpt layer instead of adding more complexity to Multires to be able to work with shape keys directly.

The list isn't really in order. Is more like a set of things to be tackled to cut off all the loose ends.
Extra features can surely be added, but this can happen as regular development and not necessarily by me. We can have a separate task with a wider look and roadmap of features we want and plan to implement.

For importing sculpts, you may be able to export a base mesh and vector displacement map in another app. The add a subdivision modifier, displacement modifier RGB to XYZ, and reshape.

But for that you need UVs in all objects of the model, and probably not all high poly meshes have UVs inside of the sculpting software if they were intended to be baked in another software (basically, all models made for game assets). I think we should try to make the importing process as straightforward as possible to get as many reports from users with production files as we can before the release.

Is there any particular reason for removing Apply Base? This can be very problematic since Blender lost its ability to bake displacement maps from two different objects and the only way to bake a displacement map right now is to use "Bake from Multires": when you, for example, baking a height map for a landscape, you need the difference between an initial flat plane and a final landscape but with Apply Base permanently applied you will only get the difference between the lowpoly version and highpoly version which is not suitable for landscape heightmaps. The same problem can arise with characters – you may need to get the difference between an initial model without deformations and a sculpted one, Multires can also be used for small touch-ups on a static model without deforming an initial mesh so unless there are very good reasons for removing that option I think it should be left as it is or at the very least there must be an option somewhere like “Apply Base by default”.

@Alex (SpectreFirst), There are two things here I guess.

First, the displacement baking is to be brought back.

Second, I also not sure completely loosing ability to sculpt on multires without affecting base mesh is the way to go. Just need to find a way to allow both workflows in a non-confusing manner.

@Alex (SpectreFirst) The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done on the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs.

Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter.

@Alex (SpectreFirst) The reason why it needs to always be automatic is because it is a giant time waster for people who actually work on sculpts. Coming from ZBrush it is incredibly jarring that the 0 subdivs mesh is not reflecting the changes done in the higher subdivs, especially when the entire point of a subdiv system is to quickly jump from subdiv to subdiv, often to the lowest subdiv, and make the necessary adjustments. When it is done automatically, you don't have to think much about moving an arm or a leg to a certain position and how it will look in higher subdivs, but with the manual approach you always have to Apply Base when having done major changes so that the placements of your limbs and other body parts reflect on the original model. Especially with the improvements done to the Pose brush it is crucial that the 0 subdiv model is always in sync with the other subdivs.

Even with the improved MultiRes no longer breaking like the old one it still isn't up to the standards that professional sculpting tools provide like ZBrush because of design decisions like Apply Base. Displacement map baking can be added to solve your problem, but for sculptors we can't compromise on this feature since we need it to work efficiently. If the devs somehow can provide automatic (default) Apply Base and the manual (non-default) Apply Base without any issues, then fine, but if they can't, then the manual approach has to go. MultiRes is primarily a tool for sculptors and should be designed as such. I would much prefer if MultiRes got split into two separate modifiers with automatic and manual Apply Base if you have any intentions of keeping the latter.

I totally agree, apply base should be default behavior, or at least an activatable checkbox option in the multires modifier.

No "Delete Lower" movement here? 👀

Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button, if you need to pose something you can just press the button once in a while and again, if something goes wrong you can just remove the modifier and apply it again. Applying base into a shape key would be a possible solution but as far as I can see, Multires cannot do that yet.

Permanently applied base is a great way to permanently destroy your model because if you'll sculpt on a Multires and remove the modifier later your mesh will stay permanently deformed and there will be no way to restore it to its original state. Only a handful of people actually need this because in my experience most people never even use the “Apply Base” button

True. Aren't modifiers designed for non-destructive workflow? This point is right there in the description of the task.

Perhaps the easiest way to deal with Apply Base is to turn it into a checkbox "Automatically Apply Base" that will let you apply Multires, manually check it and start working, checkbox will also inform you that everything you do will be permanent on a base level.

I suggest a

  • checkbox for "auto update base" (BoolProperty)
  • drop down menu (EnumProperty) for choosing either
    1. Apply base ("cage" workflow where base (subdiv 0) resembles shape of high res sculpt when subdiv is applied.)
    2. Fit base (workflow where base (subdiv 0) is resembling the shape of the highres sculpt. This is the best workflow when creating realtime/game assets.
  • Keep the button/operator for "Apply base", but rename the label to "Update base"

@Regnas (Regnas) Its currently waiting for review. Here: https://developer.blender.org/D7582

And yes auto update base should be optional to be automatic.