Bug with Simply option when rendering #46255

New Issue

Emmanuel LORANT · 2015-09-24T23:31:53+02:00

Emmanuel LORANT commented

2015-09-24 23:31:53 +02:00

System Information
Operating system and graphics card

Windows 7 x64, GTX 580 3Gb for display, GTX 780 6 Gb for render

Blender Version
Broken: (example: 2.69.7 4b206af, see splash screen) : 2.76 x64 RC2 (and 2.75 x64)
Worked: (optional)

Short description of error

I checked the Simplify option in the Scene panel and set the subdivsion level for viewport at 0. I let the Render subdivision at 6.
The tail has a subsurf level at 2 and as you can see in the picture, the sticker which is a subdivided plane (no subsurf modifier) with a modifier shrinkwrap (settings in the picture) is no rendered as expected when Simplify option is checked. If I uncheck the Simplify option, the render is ok.

http://www.pasteall.org/pic/93476

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

**System Information** Operating system and graphics card Windows 7 x64, GTX 580 3Gb for display, GTX 780 6 Gb for render **Blender Version** Broken: (example: 2.69.7 4b206af, see splash screen) : 2.76 x64 RC2 (and 2.75 x64) Worked: (optional) **Short description of error** I checked the Simplify option in the Scene panel and set the subdivsion level for viewport at 0. I let the Render subdivision at 6. The tail has a subsurf level at 2 and as you can see in the picture, the sticker which is a subdivided plane (no subsurf modifier) with a modifier shrinkwrap (settings in the picture) is no rendered as expected when Simplify option is checked. If I uncheck the Simplify option, the render is ok. http://www.pasteall.org/pic/93476 **Exact steps for others to reproduce the error** Based on a (as simple as possible) attached .blend file with minimum amount of steps

Emmanuel LORANT commented

2015-09-24 23:31:53 +02:00

Changed status to: 'Open'

Emmanuel LORANT commented

2015-09-24 23:31:53 +02:00

Added subscriber: @EmmanuelLORANT

Emmanuel LORANT commented

2015-09-24 23:37:14 +02:00

Here is a simple blend file : http://www.pasteall.org/blend/38231

Just check or uncheck simplify and hit F12.

Here is a simple blend file : http://www.pasteall.org/blend/38231 Just check or uncheck simplify and hit F12.

Bastien Montagne commented

2015-09-25 10:36:28 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-09-25 10:36:28 +02:00

Please always upload files here directly… bug_simplify.blend

Can confirm that results with simplify do not match those without it, not quite sure why, but you are using an insanely small level of offset for your shrinkwrap too, maybe a mere float imprecision issue?

Please always upload files here directly… [bug_simplify.blend](https://archive.blender.org/developer/F238887/bug_simplify.blend) Can confirm that results with simplify do not match those without it, not quite sure why, but you are using an insanely small level of offset for your shrinkwrap too, maybe a mere float imprecision issue?

ronan ducluzeau commented

2015-09-25 11:32:24 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2015-09-25 11:32:24 +02:00

Bug is not relative to simplify option. Same result happens with subdivision surface modifier viewport level set to 0.
Problem is that shrinkwrap only takes into account viewport level of subdivision surface modifier.
It seems that Subsurf levels feature of shrinkwrap modifier does not work.

Bug is not relative to simplify option. Same result happens with subdivision surface modifier viewport level set to 0. Problem is that shrinkwrap only takes into account viewport level of subdivision surface modifier. It seems that Subsurf levels feature of shrinkwrap modifier does not work.

Bastien Montagne commented

2015-09-25 12:16:12 +02:00

Added subscribers: @LukasTonne, @Sergey, @ideasman42

Bastien Montagne commented

2015-09-25 12:16:12 +02:00

Good spot @zeauro, indeed currently we do not have a real way to ensure we get real 'render' DM (tagged as TODO in object_get_derived_final()).

@Sergey @ideasman42 @LukasTonne I think this is a TODO/known limitation more than a bug currently?

Good spot @zeauro, indeed currently we do not have a real way to ensure we get real 'render' DM (tagged as TODO in `object_get_derived_final()`). @Sergey @ideasman42 @LukasTonne I think this is a TODO/known limitation more than a bug currently?

Sergey Sharybin commented

2015-09-25 12:21:04 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-09-25 12:21:04 +02:00

Sergey Sharybin self-assigned this 2015-09-25 12:21:04 +02:00

Sergey Sharybin commented

2015-09-25 12:21:04 +02:00

This is indeed a limitation of current dependency graph. I've tried to solve this during my last GSoC and had system basical working. But then it was disabled because of huge issues in the Blender Internal's duplication code which couldn't really cache single DeivedMesh for render.

While i can see how annoying it is, it's not really a bug. Just a known limitation. So thanks for the report, but sending to archive for until we'll re-work duplication code in BI.

This is indeed a limitation of current dependency graph. I've tried to solve this during my last GSoC and had system basical working. But then it was disabled because of huge issues in the Blender Internal's duplication code which couldn't really cache single DeivedMesh for render. While i can see how annoying it is, it's not really a bug. Just a known limitation. So thanks for the report, but sending to archive for until we'll re-work duplication code in BI.

Lukas Tönne commented

2015-09-25 13:31:34 +02:00

The general problem is that any interaction of 2 or more objects is based on the viewport settings, not render. For example this also applies to collisions in physics sims.

The rationale seems to be that higher subdiv for rendering is supposed to be a visual refinement of the mesh only. That it has consequences for other objects is an unfortunate design limitation that has to be taken into account on the artist side. I'm not sure if solving this for immediate modifiers like shrinkwrap (as opposed to incremental simulations with collision) is feasible in an acceptable way.

The general problem is that **any** interaction of 2 or more objects is based on the viewport settings, not render. For example this also applies to collisions in physics sims. The rationale seems to be that higher subdiv for rendering is supposed to be a visual refinement of the mesh only. That it has consequences for other objects is an unfortunate design limitation that has to be taken into account on the artist side. I'm not sure if solving this for immediate modifiers like shrinkwrap (as opposed to incremental simulations with collision) is feasible in an acceptable way.

Emmanuel LORANT commented

2015-09-25 14:25:54 +02:00

In my opinion, it would be better to back as it was before (if I remember well) : no options for render or at least a warning so no confusion is possible.
Or perhaps, put the Simplify option in Properties -> Render -> Render panel so when you click Render, you see immediatly that Simplify is checked or not.

In my opinion, it would be better to back as it was before (if I remember well) : no options for render or at least a warning so no confusion is possible. Or perhaps, put the Simplify option in Properties -> Render -> Render panel so when you click Render, you see immediatly that Simplify is checked or not.

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

Bug with Simply option when rendering #46255