Blender 2.8 subsurface modifier bug. #62008

New Issue

harun · 2019-02-27T10:20:22+01:00

harun commented

2019-02-27 10:20:22 +01:00

System Information
Operating system: Windows 10
Graphics card: MSI GTX 1060

Blender Version
2.80 Beta
Short description of error
Subsurface Modifier 2.8 behaved differently compare to 2.7 version

Exact steps for others to reproduce the error
Create a cube,
add Subsurface Mod level 1.
Go to edit mode.
The edge of the mesh doesn't stick to the bounding box.
Link for example with video and image.
https://blender.stackexchange.com/questions/132951/blender-2-8-subfsurf-modifier-behave-different-compare-to-2-7
Based on the default startup or an attached .blend file (as simple as possible).

**System Information** Operating system: Windows 10 Graphics card: MSI GTX 1060 **Blender Version** 2.80 Beta **Short description of error** Subsurface Modifier 2.8 behaved differently compare to 2.7 version **Exact steps for others to reproduce the error** Create a cube, add Subsurface Mod level 1. Go to edit mode. The edge of the mesh doesn't stick to the bounding box. Link for example with video and image. https://blender.stackexchange.com/questions/132951/blender-2-8-subfsurf-modifier-behave-different-compare-to-2-7 Based on the default startup or an attached .blend file (as simple as possible).

harun commented

2019-02-27 10:20:22 +01:00

Added subscriber: @harun

Sebastian Parborg commented

2019-02-27 11:06:32 +01:00

Added subscribers: @Sergey, @ZedDB

Sebastian Parborg self-assigned this 2019-02-27 11:06:32 +01:00

Sebastian Parborg commented

2019-02-27 11:06:32 +01:00

The issue here is that the new subdiv code uses the limit surface (the surface of the cube is you subdivide it an infinite amount of times) to place the verts.

IIRC there is already a toggle to enable/disable this in the code.

@Sergey I guess we could add an option in the modifier to toggle this on and off?
I can do it if you want to.

The issue here is that the new subdiv code uses the limit surface (the surface of the cube is you subdivide it an infinite amount of times) to place the verts. IIRC there is already a toggle to enable/disable this in the code. @Sergey I guess we could add an option in the modifier to toggle this on and off? I can do it if you want to.

Sergey Sharybin commented

2019-02-27 15:49:27 +01:00

@ZedDB, i would not consider difference in behavior a bug, and would not expose that option. The drawbacks are much more serious than one might think:

With current OpenSubdiv release 3.3.3 UVs evaluator will crash, without us being able to work this around. The upcoming OpenSubdiv release has this resolved, but is still lacking support of vertex-varying data interpolation. Upcoming release is not stable enough to be used in other ways as well. Surely, with time this is not a limitation anymore.
Topology refinment will happen way slower on a higher quality level (what we call Quality in the interface translates to how deeply OpenSubdiv analyzes topology).
What we currently use is called "adaptive refinment", which basically means topology refiner will stop analyzing mesh once its reached certain threshold of how close patch is to the limit surface. For a regular character like meshes this is really only few levels deep.
The alternative is called "uniform refinment", and that will keep creating patches which approximate the surface for until the very last level. This is because you can't approximate those with a b-spline surface, and effectively ending up creating patches for every high-res face.
The previous point also has affect on evaluation time: more patches there are, slower evaluation becomes. This is not as drastic as previous point, but is still quite measurable (this is also a reason why subdiv modifier is now slower when mesh has a lot of extraordinary vertices).
We are planing to restore GPU support of OpenSubdiv, and in there uniform refinment makes it hard to have smooth normals: those are no longer possible to be evaluated from the patch, and needs to be calculated as some sort of averaging which can not be done on GPU effectively.
Other downside of uniform refinement on GPU is that it does not support screen space level of details, which we might also want to make benefit of.

@ZedDB, i would not consider difference in behavior a bug, and would not expose that option. The drawbacks are much more serious than one might think: - With current OpenSubdiv release 3.3.3 UVs evaluator will crash, without us being able to work this around. The upcoming OpenSubdiv release has this resolved, but is still lacking support of vertex-varying data interpolation. Upcoming release is not stable enough to be used in other ways as well. Surely, with time this is not a limitation anymore. - Topology refinment will happen way slower on a higher quality level (what we call Quality in the interface translates to how deeply OpenSubdiv analyzes topology). What we currently use is called "adaptive refinment", which basically means topology refiner will stop analyzing mesh once its reached certain threshold of how close patch is to the limit surface. For a regular character like meshes this is really only few levels deep. The alternative is called "uniform refinment", and that will keep creating patches which approximate the surface for until the very last level. This is because you can't approximate those with a b-spline surface, and effectively ending up creating patches for every high-res face. - The previous point also has affect on evaluation time: more patches there are, slower evaluation becomes. This is not as drastic as previous point, but is still quite measurable (this is also a reason why subdiv modifier is now slower when mesh has a lot of extraordinary vertices). - We are planing to restore GPU support of OpenSubdiv, and in there uniform refinment makes it hard to have smooth normals: those are no longer possible to be evaluated from the patch, and needs to be calculated as some sort of averaging which can not be done on GPU effectively. - Other downside of uniform refinement on GPU is that it does not support screen space level of details, which we might also want to make benefit of.

Sebastian Parborg commented

2019-02-27 16:06:07 +01:00

Changed status from 'Open' to: 'Archived'

Sebastian Parborg closed this issue

2019-02-27 16:06:07 +01:00

Sebastian Parborg commented

2019-02-27 16:06:07 +01:00

I see. Thanks for the explanation. Then I don't think there is much to do here in this regard either.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender 2.8 subsurface modifier bug. #62008