Blender Quits When Baked Fire is Disabled in Viewport viewmode. #82910

New Issue

Nathaniel Sun · 2020-11-21T22:54:49+01:00

Nathaniel Sun commented

2020-11-21 22:54:49 +01:00

System Information
Operating system: Windows 10 (64-bit)
Graphics card: Nvidia Quadro 4000
CPU: Dual Intel XEON E5-2680 0 (8-core 16-thread 2.7ghz)
RAM: 128GB

Blender Version
Broken: (2.90, mantaflow fire simulation)
Worked: (2.82)

Short description of error
So basically I have found a bug in 2.90 (also in 2.83), which involves Blender quiting under a specific circumstance.
If I disable viewing the baked fire in viewport mode (i.e. viewport render, wireframe, solid view), then when I try to view my modeling in viewport render, Blender immediately crashes. I don't think this is a hardware issue, because when I enable viewport view (on the modifier) with rendered view also enabled for the fire domain, then it does not crash, and I can view the scene in viewport render. This has gotten annoying, however, because when I have larger fire caches, and don't need to see them in viewport mode, then I won't be able to see anything in viewport render without having to enable them again.

Exact steps for others to reproduce the error
If you want to be able to reproduce this glitch, then you must create a mantaflow fire simulation (in 2.90).
It doesn't need to be much, simply a cube, set to inflow fire/smoke/both, a domain set to around 100 resolution, and a principled volume shader for the domain. Bake the fire in your own cache anywhere on your computer. Now, set the render engine to Cycles, disable viewport view for the fluid modifier in the modifiers property for the domain, and try to view it in viewport render. It should crash as soon as you click on the 'rendered-view' sphere. I hope this helps, if I have found a major bug!

**System Information** Operating system: Windows 10 (64-bit) Graphics card: Nvidia Quadro 4000 CPU: Dual Intel XEON E5-2680 0 (8-core 16-thread 2.7ghz) RAM: 128GB **Blender Version** Broken: (2.90, mantaflow fire simulation) Worked: (2.82) **Short description of error** So basically I have found a bug in 2.90 (also in 2.83), which involves Blender quiting under a specific circumstance. If I disable viewing the baked fire in viewport mode (i.e. viewport render, wireframe, solid view), then when I try to view my modeling in viewport render, Blender immediately crashes. I don't think this is a hardware issue, because when I enable viewport view (on the modifier) with rendered view also enabled for the fire domain, then it does not crash, and I can view the scene in viewport render. This has gotten annoying, however, because when I have larger fire caches, and don't need to see them in viewport mode, then I won't be able to see anything in viewport render without having to enable them again. **Exact steps for others to reproduce the error** If you want to be able to reproduce this glitch, then you must create a mantaflow fire simulation (in 2.90). It doesn't need to be much, simply a cube, set to inflow fire/smoke/both, a domain set to around 100 resolution, and a principled volume shader for the domain. Bake the fire in your own cache anywhere on your computer. Now, set the render engine to Cycles, disable viewport view for the fluid modifier in the modifiers property for the domain, and try to view it in viewport render. It should crash as soon as you click on the 'rendered-view' sphere. I hope this helps, if I have found a major bug!

Nathaniel Sun commented

2020-11-21 22:54:49 +01:00

Added subscriber: @Sycro27

Robert Guetzkow commented

2020-11-22 00:30:12 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-11-22 00:30:12 +01:00

2.83.9 works without any issues for me, 2.90.1 crashes, 2.91.0 and 2.92.0 continuously render the first sample and don't progress further when using Cycles. There is definitely something not quite right. Me or somebody else from the triaging team will look into this on Monday.

Slightly simplified steps to reproduce:

Select the default cube and apply Object > Quick Effects > Quick Smoke.
Either play the animation with the cache type set to Replay or bake it to disk, it doesn't make a difference. The frame range of the simulation can be as short as two frames.
Disable the fluid modifier in viewport (screen icon) in the modifier properties tab.
Set viewport shading to Rendered.

Notes:

The render engine doesn't matter for the 2.90.1 crash.
Only Fire and Smoke seem to result in issues, e.g. Quick Liquid works fine.

2.83.9 works without any issues for me, 2.90.1 crashes, 2.91.0 and 2.92.0 continuously render the first sample and don't progress further when using Cycles. There is definitely something not quite right. Me or somebody else from the triaging team will look into this on Monday. Slightly simplified steps to reproduce: - Select the default cube and apply *Object > Quick Effects > Quick Smoke*. - Either play the animation with the cache type set to *Replay* or bake it to disk, it doesn't make a difference. The frame range of the simulation can be as short as two frames. - Disable the fluid modifier in viewport (screen icon) in the modifier properties tab. - Set viewport shading to *Rendered*. Notes: - The render engine doesn't matter for the 2.90.1 crash. - Only Fire and Smoke seem to result in issues, e.g. *Quick Liquid* works fine.

Robert Guetzkow commented

2020-11-23 17:17:11 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2020-11-23 17:17:11 +01:00

@Sycro27 Could you please check if you can still reproduce the crash in [2.83.9 ]], [ https:*builder.blender.org/download/ | 2.91.0 or 2.92 ?

If yes, then please open Blender's installation directory and double click on the blender_debug_gpu.cmd. This will start Blender in debug mode and create log files. Try to make Blender crash again. Once it crashes the Windows Explorer should open and show you up to two files, a debug log and the system information. Add them to your bug report by clicking on the upload button as shown in the screenshot below or via drag and drop. Please also upload the crash log located in C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt (or simply type %TEMP% into the path bar of the Windows Explorer).

@Sycro27 Could you please check if you can still reproduce the crash in [2.83.9 ]], [[ https:*builder.blender.org/download/ | 2.91.0 or 2.92 ](https:*download.blender.org/release/Blender2.83/)? If yes, then please open Blender's installation directory and double click on the `blender_debug_gpu.cmd`. This will start Blender in debug mode and create log files. Try to make Blender crash again. Once it crashes the Windows Explorer should open and show you up to two files, a debug log and the system information. Add them to your bug report by clicking on the upload button as shown in the screenshot below or via drag and drop. Please also upload the crash log located in `C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt` (or simply type `%TEMP%` into the path bar of the Windows Explorer). ![2019_12_04_upload_icon_developer_blender_org.png](https://archive.blender.org/developer/F8190038/2019_12_04_upload_icon_developer_blender_org.png)

Nathaniel Sun commented

2020-11-23 18:10:52 +01:00

After testing the Blender versions you asked me to test, I have results.
2.83.9: Created simple fire sim, disabled viewport render for fire and no crashing in either EEVEE or Cycles.
2.90.1: Created simple fire sim, disabled viewport render for fire, and Cycles crashed when trying to render in the viewport. EEVEE had problems though.
2.91.0: Created simple fire sim, disabled viewport render for fire, Cycles (as you said) repeatedly rendered the first sample in the viewport. EEVEE, again, had no problems.
2.92: Exact same as 2.91.0.
Interestingly enough, I discovered that in 2.91 and 2.92, enabling viewport denoising, and setting it to start denoising the viewport at 1 sample would actually render past the first sample when trying to render with fire disabled in the viewport.

I have the Blender log for 2.90 when it crashed in debug mode, and am posting it with this post.

blender_debug_output.txt

blender_system_info.txt

After testing the Blender versions you asked me to test, I have results. 2.83.9: Created simple fire sim, disabled viewport render for fire and no crashing in either EEVEE or Cycles. 2.90.1: Created simple fire sim, disabled viewport render for fire, and Cycles crashed when trying to render in the viewport. EEVEE had problems though. 2.91.0: Created simple fire sim, disabled viewport render for fire, Cycles (as you said) repeatedly rendered the first sample in the viewport. EEVEE, again, had no problems. 2.92: Exact same as 2.91.0. Interestingly enough, I discovered that in 2.91 and 2.92, enabling viewport denoising, and setting it to start denoising the viewport at 1 sample would actually render past the first sample when trying to render with fire disabled in the viewport. I have the Blender log for 2.90 when it crashed in debug mode, and am posting it with this post. [blender_debug_output.txt](https://archive.blender.org/developer/F9360384/blender_debug_output.txt) [blender_system_info.txt](https://archive.blender.org/developer/F9360383/blender_system_info.txt)

Robert Guetzkow commented

2020-11-30 14:07:41 +01:00

@Sycro27 In this case the issue that caused the crash has been fixed in current versions of Blender. Would be so kind and create a new ticket for the stuck rendering of the first sample? This appears to be a separate issue.

Robert Guetzkow commented

2020-11-30 14:08:17 +01:00

Changed status from 'Needs User Info' to: 'Resolved'

Robert Guetzkow closed this issue

2020-11-30 14:08:17 +01:00

Robert Guetzkow self-assigned this 2020-11-30 14:08:17 +01:00

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 Quits When Baked Fire is Disabled in Viewport viewmode. #82910