multires modifier: adjusting mesh at lower sculpt levels of subdivision adds polygonal artifacts to higher sculpt levels. #69433

New Issue

Bay Raitt · 2019-09-03T04:13:08+02:00

Bay Raitt commented

2019-09-03 04:13:08 +02:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 980/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449
Worked: (optional)

when changing mulitres sculpt levels higher, the higher resolution mesh details are not recalculated correctly.

steps:
create a cube
add multires modifier
subdiv 6 times.
Set sculpt level to 6.
sculpt details
reduce sculpt level to 2
adjust with grab brush.
Set sculpt level to 6
bug here:
notice polygonal artifacts have destroyed details.

hunch:
looks like it's not calculating the higher resolution details relative to the limit catmull clark subdiv and is just using simple subdivision stored in object space without any relative wavelet compression at each subdivision.

(this fast resolution switcher addon I wrote highlights the problem even more)
https://gumroad.com/l/subd_navigator

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce GTX 980/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: `f6cb5f5449` Worked: (optional) when changing mulitres sculpt levels higher, the higher resolution mesh details are not recalculated correctly. steps: create a cube add multires modifier subdiv 6 times. Set sculpt level to 6. sculpt details reduce sculpt level to 2 adjust with grab brush. Set sculpt level to 6 bug here: notice polygonal artifacts have destroyed details. hunch: looks like it's not calculating the higher resolution details relative to the limit catmull clark subdiv and is just using simple subdivision stored in object space without any relative wavelet compression at each subdivision. ![multri_res_bug2.gif](https://archive.blender.org/developer/F7714710/multri_res_bug2.gif) ![multri_res_subd_bug.gif](https://archive.blender.org/developer/F7714709/multri_res_subd_bug.gif) (this fast resolution switcher addon I wrote highlights the problem even more) https://gumroad.com/l/subd_navigator

Bay Raitt commented

2019-09-03 04:13:08 +02:00

Added subscriber: @spiraloid-3

Bay Raitt commented

2019-09-03 04:31:05 +02:00

hitting apply base on subdivided cube after modifying lowest and highest levels of subdivision is producing odd artifacts too.

hitting apply base on subdivided cube after modifying lowest and highest levels of subdivision is producing odd artifacts too. ![image.png](https://archive.blender.org/developer/F7714728/image.png)

Bay Raitt commented

2019-09-03 04:39:28 +02:00

on further reflection, I think I made be misunderstanding the intended behaviour of multi-res. I was expecting it to behave like open subdiv (i.e. pixar, zbrush, maya etc)
http://graphics.pixar.com/opensubdiv/docs/release_34.html

with a hierarchical subdiv relationship between different levels of subdivision. the existence of the the Apply Base button makes me realize that this is not the case.

on further reflection, I think I made be misunderstanding the intended behaviour of multi-res. I was expecting it to behave like open subdiv (i.e. pixar, zbrush, maya etc) http://graphics.pixar.com/opensubdiv/docs/release_34.html with a hierarchical subdiv relationship between different levels of subdivision. the existence of the the Apply Base button makes me realize that this is not the case.

Bay Raitt commented

2019-09-03 09:22:09 +02:00

looks to still be a problem in

blender-2.81-d74cc6c08c42-win64

hunch:
looks like it's not calculating the higher resolution details relative to the limit catmull clark subdiv and is just using and edgewise linear subdivision to store the higher levels of detail offsets. This means it's not doing relative wavelet compression at each subdivision level and each successive subdivision is being stored relative to the faces, instead of relative to the limit surface of the subd... which would explain the polygonal looking artifacts on the dense mesh.

I think the solution is that each time the sculpt_level decreases, the lower resolution cage needs to be adjusted so that it's limit surface fits the current surface. then the surface details need to be recalculated and stored in tangent space relative to the lower level's limit surface. Then to correctly the sculpt modifications from a lower level, a new limit surface gets calculated and the higher detail level's surface offsets are applied in tangent space relative to the new limit surface....

looks to still be a problem in blender-2.81-d74cc6c08c42-win64 ![image.png](https://archive.blender.org/developer/F7714899/image.png) ![image.png](https://archive.blender.org/developer/F7715098/image.png) hunch: looks like it's not calculating the higher resolution details relative to the limit catmull clark subdiv and is just using and edgewise linear subdivision to store the higher levels of detail offsets. This means it's not doing relative wavelet compression at each subdivision level and each successive subdivision is being stored relative to the faces, instead of relative to the limit surface of the subd... which would explain the polygonal looking artifacts on the dense mesh. I think the solution is that each time the sculpt_level decreases, the lower resolution cage needs to be adjusted so that it's limit surface fits the current surface. then the surface details need to be recalculated and stored in tangent space relative to the lower level's limit surface. Then to correctly the sculpt modifications from a lower level, a new limit surface gets calculated and the higher detail level's surface offsets are applied in tangent space relative to the new limit surface....

item412 commented

2019-09-04 17:29:11 +02:00

Added subscriber: @item412

Bay Raitt commented

2019-09-13 00:01:30 +02:00

After looking at it it a bit more, it looks like these issues are all because multires was not implemented as a conventional hierarchical subdiv and is instead storing the vertices relative to the edgewise linear interpolation of the parent level subdivision. it's also not adjusting the parent's cage vertice positions during level switching and instead only does a reshape when choosing "apply base" instead of on each level switch.

more info here:

https://renderman.pixar.com/resources/RenderMan_20/hierarchsubdiv.html

After looking at it it a bit more, it looks like these issues are all because multires was not implemented as a conventional hierarchical subdiv and is instead storing the vertices relative to the edgewise linear interpolation of the parent level subdivision. it's also not adjusting the parent's cage vertice positions during level switching and instead only does a reshape when choosing "apply base" instead of on each level switch. more info here: https://renderman.pixar.com/resources/RenderMan_20/hierarchsubdiv.html

Erick Tukuniata commented

2019-09-13 00:25:46 +02:00

Added subscriber: @ErickNyanduKabongo