Cycles doesn't render smoke properly with adjusted clipping distances #53472

New Issue

BlenderSpot · 2017-12-05T11:21:21+01:00

BlenderSpot commented

2017-12-05 11:21:21 +01:00

Windows 10 / AMD Radeon 6800 Series
Broken: 2.79.1 1802d14

I need to render a cross section of a smoke simulation. I set up the simulation and adjust the start/end clipping distances of the active camera to the desired values and in OpenGL viewport it works fine, renders exactly the cross section I want.
However, when I go into cycles and render it out, I get nothing: [The second camera next to the active one is just for the convenience sake, mimicking the clipping values. Cycles behaves the same without it.]
I know that the materials are working fine because I can render it outside the camera's view:
If it helps, here's something else that I've found. When the end clipping distance goes beyond the Flow mesh (emitter) I get this weird result:
And when it (end clipping distance) goes even outside the adaptive domain box, then it renders the smoke:
smoke.blend

Windows 10 / AMD Radeon 6800 Series Broken: 2.79.1 1802d14 I need to render a cross section of a smoke simulation. I set up the simulation and adjust the start/end clipping distances of the active camera to the desired values and in OpenGL viewport it works fine, renders exactly the cross section I want. ![screeCap.gif](https://archive.blender.org/developer/F1306781/screeCap.gif) However, when I go into cycles and render it out, I get nothing: [*The second camera next to the active one is just for the convenience sake, mimicking the clipping values. Cycles behaves the same without it.*] ![cycles_camera_empty_render.png](https://archive.blender.org/developer/F1306804/cycles_camera_empty_render.png) I know that the materials are working fine because I can render it outside the camera's view: ![cycles_outside_camera_render.png](https://archive.blender.org/developer/F1306960/cycles_outside_camera_render.png) If it helps, here's something else that I've found. When the end clipping distance goes beyond the Flow mesh (emitter) I get this weird result: ![cycles_clippingEnd_beneath_emitter.png](https://archive.blender.org/developer/F1307076/cycles_clippingEnd_beneath_emitter.png) And when it (end clipping distance) goes even outside the adaptive domain box, then it renders the smoke: ![cycles_clippingEnd_beneath_adaptiveDomain.png](https://archive.blender.org/developer/F1307132/cycles_clippingEnd_beneath_adaptiveDomain.png) [smoke.blend](https://archive.blender.org/developer/F1307217/smoke.blend)

BlenderSpot commented

2017-12-05 11:21:21 +01:00

Changed status to: 'Open'

BlenderSpot commented

2017-12-05 11:21:21 +01:00

Added subscriber: @unimbox

ronan ducluzeau commented

2017-12-06 16:19:47 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2017-12-06 16:19:47 +01:00

I think it is a known limitation that Camera Clipping is not working with smokes at rendering.

Since beginning of Cycles, there was the intention to propose a simpler workflow for smokes than the one used for Blender Internal.
There was the idea to add and substract volume objects and don't do complicated materials.
There was a proposal of OpenVDB primitive dedicated to this task. But nobody had time to realize it, yet.

But you can reach desired goal to render a slice of simulation by using a gradient texture + a colorramp as factor of a Mix Shader mixing smoke material nodetree and a transparent shader.

In 2.79, OpenGL render of smoke in viewport have been improved. You can see a specific slice of smoke simulation by using Axis method for slicing under Smoke Display Settings panel.
Maybe it could be used by Cycles, too by adding a slice attribute to smoke attributes.
Maybe it is too specific to Blender tools to be added to Cycles.

I think it is a known limitation that Camera Clipping is not working with smokes at rendering. Since beginning of Cycles, there was the intention to propose a simpler workflow for smokes than the one used for Blender Internal. There was the idea to add and substract volume objects and don't do complicated materials. There was a proposal of OpenVDB primitive dedicated to this task. But nobody had time to realize it, yet. But you can reach desired goal to render a slice of simulation by using a gradient texture + a colorramp as factor of a Mix Shader mixing smoke material nodetree and a transparent shader. In 2.79, OpenGL render of smoke in viewport have been improved. You can see a specific slice of smoke simulation by using Axis method for slicing under Smoke Display Settings panel. Maybe it could be used by Cycles, too by adding a slice attribute to smoke attributes. Maybe it is too specific to Blender tools to be added to Cycles.

BlenderSpot commented

2017-12-07 10:31:15 +01:00

@zeauro
Thanks for the workaround but the thing is that I need to render like 20 slices along Z and 10 on X and Y each, so 40 slices in total. And then I need to do the same thing with another smoke sim, maybe bigger, so even more slices.

Do you know if that's gonna be fixed for 2.8 release?

@zeauro Thanks for the workaround but the thing is that I need to render like 20 slices along Z and 10 on X and Y each, so 40 slices in total. And then I need to do the same thing with another smoke sim, maybe bigger, so even more slices. Do you know if that's gonna be fixed for 2.8 release?

ronan ducluzeau commented

2017-12-07 12:34:31 +01:00

There is no plan that goes into details for refactoring of smokes or a developer currently working on it for first 2.8. A refactoring of modifiers is expected for the end of 2.8 series but to convert modifiers's stack into modifiers nodes. Addition of an OpenVDB primitive can be done next year or more years later.

When it comes to render, simulation steps are sampled according to high resolution steps and sampling settings and re-interpreted as Volume Steps according to Cycles settings.
So, a multiple slices render option will probably never be done.

I repeat your problem is easy to solve. Just use a colorband of 3 Stops (white|black|white or black|white|black) as factor of a mix node per axis.
To modify slices or number of slices rendered, you just have to modify interval of the middle of the colorband by changing stops posisitions.
You can repeat the process for each axis. 3 axis = 3 mixing with a colorband.
Or you can use an image of a black square on a white background as factor for XY plane.

I did not instantly close the report because I don't know how Cycles developers will consider exposed issue as an UI inconsistency or a feature request or a ToDo.
But it was never supported , so technically, it is not a bug or a regression. It is a lack.
And there is a workaround. If OpenVDB primitive is done one day, another one will be available. Cycles developers could simply choose to ignore it.

There is no plan that goes into details for refactoring of smokes or a developer currently working on it for first 2.8. A refactoring of modifiers is expected for the end of 2.8 series but to convert modifiers's stack into modifiers nodes. Addition of an OpenVDB primitive can be done next year or more years later. When it comes to render, simulation steps are sampled according to high resolution steps and sampling settings and re-interpreted as Volume Steps according to Cycles settings. So, a multiple slices render option will probably never be done. I repeat your problem is easy to solve. Just use a colorband of 3 Stops (white|black|white or black|white|black) as factor of a mix node per axis. To modify slices or number of slices rendered, you just have to modify interval of the middle of the colorband by changing stops posisitions. You can repeat the process for each axis. 3 axis = 3 mixing with a colorband. Or you can use an image of a black square on a white background as factor for XY plane. I did not instantly close the report because I don't know how Cycles developers will consider exposed issue as an UI inconsistency or a feature request or a ToDo. But it was never supported , so technically, it is not a bug or a regression. It is a lack. And there is a workaround. If OpenVDB primitive is done one day, another one will be available. Cycles developers could simply choose to ignore it.

Brecht Van Lommel commented

2017-12-24 16:10:12 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-12-24 16:10:12 +01:00

This is a limitation of how we render volumes at the moment, with a volume stack to detect when we enter/exit volumes. With clipping that fails since we never hit the surface to enter/exit the volume. I'll consider this a to do item but not a bug, since it requires quite deep changes in how we handle either clipping or volumes.

Solution could be to either handle volume intersections in a special way to always find the entry/exit intersections, or probably more practical to change clipping to still handle volume enter/exit for the parts that are clipped away.

This is a limitation of how we render volumes at the moment, with a volume stack to detect when we enter/exit volumes. With clipping that fails since we never hit the surface to enter/exit the volume. I'll consider this a to do item but not a bug, since it requires quite deep changes in how we handle either clipping or volumes. Solution could be to either handle volume intersections in a special way to always find the entry/exit intersections, or probably more practical to change clipping to still handle volume enter/exit for the parts that are clipped away.

Brecht Van Lommel added this to the Render & Cycles project 2023-02-07 19:07:34 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles doesn't render smoke properly with adjusted clipping distances #53472