Shrinkwrap issue on 2.79 ... Bug?

Support Modeling
1

Hi,

I found this problem on a big scene, but I managed to reproduce on a simple scene :
Let’s say I have this cube, with subsurf modifier, and an already subdivided plane above the cube :

shrinkwrap_1
shrinkwrap_1512×512 11.3 KB

The subsurf on the cube is set to level 2 on both viewport and render.
If I use a Shrinkwrap modifier on the plane to wrap it on the cube, it works :
shrinkwrap_2
shrinkwrap_2512×512 14.6 KB

And so is the render :
shrinkwrap_render
shrinkwrap_render512×512 62.2 KB

Now, here is my problem, let’s say I want the cube to be subsurfed at level 4 at render :
Screenshot%20from%202019-06-04%2010-29-59
At rendertime, the shrinkwrap is not uptaded, it’s still refering to viewport level 2 :

shrinkwrap_3
shrinkwrap_3512×512 65.7 KB

The ONLY way to have the shrinkwrap working, is to set the subsurf to 4 on viewport param :
Screenshot%20from%202019-06-04%2010-30-21
And here comes the “good” render :
shrinkwrap_4
shrinkwrap_4512×512 67.4 KB

To sum it up, it means that on my original heavy scene, I MUST set the final subsurf level on viewport if I want it to work at rendertime :scream:

Is it a known bug ?

By the way, this does not happen on 2.8, where the shrinkwrap is well refering to the render level of the target object.
But I’m working on a project I cannot transfer on 2.8 for now…

See you ++
Tricotou

2

The fact that it’s been cleaned up in 2.8 makes me think that it WAS a known bug.

Could you… set the shrinkwrap to only appear in Render? Maybe that would help? (total guess)

3

@OP Thanks for highlighting this, which appears quite a major issue!

I often shrinkwrap clothing to characters which I know have higher render subsurface level.
Must check when I get home to see whether this error harms the render!

BR
JN

4

I agree, but it’s weird not to have solved it in 2.79 … Specially when you know that only thing to do to fix the bug is to change a variable “levels” to “render_levels”.
By the way, for the developpement of 2.8, this issue with ambiguity in var names was pointed up. For example for hiding objects in 2.79, the variables are “hide” and “hide_render” and when you are dealing with “hide” you might make mistakes because nothing says if it’s for viewport or render, unless having a “hide_render” var just in front of you.
That’s why in Blender 2.8 they changed it to “hide_viewport” and “hide_render” just to definitively fix things. But they didn’t fix the exact same problem for levels and render_levels in the Modifiers Params… Quite unlogical.
I’m pretty sure that this bug actually comes from this ambiguity.

For the moment, that’s what I’m actually doing, as my project is fully managed by python script, the levels are dynamicly moved by code at render time, in order to get around this bug…

NP ! :slight_smile: