Cycles Smoke/Fire render procudes NAN pixels #48383

New Issue

Thomas Dinges · 2016-05-09T01:48:39+02:00

Thomas Dinges commented

2016-05-09 01:48:39 +02:00

System Information
Ubuntu Linux 16.04
Geforce 730
Core i5 3570 (so it's the AVX kernel).

Blender Version
Broken: current Master

Short description of error

Switch to Cycles, execute "Quick Smoke" (Smoke + Fire).
Alt+A to bake some frames
Render with F12 (CPU render)

I can see a lot of NAN pixels there. This does not happen when rendering with GPU.

smoke.blend

**System Information** Ubuntu Linux 16.04 Geforce 730 Core i5 3570 (so it's the AVX kernel). **Blender Version** Broken: current Master **Short description of error** * Switch to Cycles, execute "Quick Smoke" (Smoke + Fire). * Alt+A to bake some frames * Render with F12 (CPU render) I can see a lot of NAN pixels there. This does not happen when rendering with GPU. [smoke.blend](https://archive.blender.org/developer/F309830/smoke.blend) ![smoke.png](https://archive.blender.org/developer/F309831/smoke.png)

Thomas Dinges commented

2016-05-09 01:48:39 +02:00

Changed status to: 'Open'

Sergey Sharybin was assigned by Thomas Dinges

2016-05-09 01:48:39 +02:00

Thomas Dinges commented

2016-05-09 01:48:39 +02:00

Added subscriber: @ThomasDinges

Thomas Dinges commented

2016-05-09 09:35:08 +02:00

The builds from Buildbot are fine, only happens with my self compiled build.

I did a full clean build, did not fix it. Attaching my system-info here, no idea whats wrong. system-info.txt

The builds from Buildbot are fine, only happens with my self compiled build. I did a full clean build, did not fix it. Attaching my system-info here, no idea whats wrong. [system-info.txt](https://archive.blender.org/developer/F309867/system-info.txt)

Sergey Sharybin commented

2016-05-09 09:58:10 +02:00

Check if it's a regression since some previous release (checkout to a previous releases, compile them and see). If so you can bisect what revision caused the issue.

I'm on very similar setup to the buildbot and release environment and can't reproduce the issue, so unlikely to help here.

Check if it's a regression since some previous release (checkout to a previous releases, compile them and see). If so you can bisect what revision caused the issue. I'm on very similar setup to the buildbot and release environment and can't reproduce the issue, so unlikely to help here.

Lukas Tönne commented

2016-05-09 10:28:16 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2016-05-09 10:28:16 +02:00

I get kernel_assert failures relating to the emission part of the L_sum here:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/kernel_accumulate.h$450

@Sergey: It only happens after enough time into the simulation, presumably when the smoke starts intersecting the domain box.

I get `kernel_assert` failures relating to the emission part of the `L_sum` here: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/kernel_accumulate.h$450 @Sergey: It only happens after enough time into the simulation, presumably when the smoke starts intersecting the domain box.

Sergey Sharybin commented

2016-05-09 10:40:03 +02:00

@LukasTonne, any particular frame number i am to render to see that? What frame you rendered anyway? :)

Lukas Tönne commented

2016-05-09 10:46:31 +02:00

Frame 26 for example (after rerunning the sim from the start).

Lukas Stockner commented

2016-05-09 22:51:05 +02:00

Added subscriber: @LukasStockner

Lukas Stockner commented

2016-05-09 22:51:05 +02:00

I get the non-finite assert as well, but it happens way less often than in @ThomasDinges's screenshot, so the NaNs I get might actually be unrelated to the bug here.
Anyways, by enabling floating point exceptions (P356), I already found two areas that might cause trouble:

intern/cycles/kernel/kernel_volume.h:294 may divide by zero if full_transmittance is one (which I guess is quite common) - mathematically, that makes sense since distance-based sampling is impossible in fully transparent volumes. However, I guess detecting that case and not using MIS in that case would be the more stable solution.
intern/cycles/kernel/kernel_volume.h:629 may overflow when ray->t is FLT_MAX and the step size is lower than 1 - generally, the conversion to an integer might overflow here. The more stable approach would be to compare ray->t to global_max_steps*step_size and set max_steps to global_max_steps if it's larger, only doing the divide and cast otherwise.

I can just go ahead and handle these two points, but maybe they're known and actually fine?

I get the non-finite assert as well, but it happens way less often than in @ThomasDinges's screenshot, so the NaNs I get might actually be unrelated to the bug here. Anyways, by enabling floating point exceptions ([P356](https://archive.blender.org/developer/P356.txt)), I already found two areas that might cause trouble: - intern/cycles/kernel/kernel_volume.h:294 may divide by zero if full_transmittance is one (which I guess is quite common) - mathematically, that makes sense since distance-based sampling is impossible in fully transparent volumes. However, I guess detecting that case and not using MIS in that case would be the more stable solution. - intern/cycles/kernel/kernel_volume.h:629 may overflow when ray->t is FLT_MAX and the step size is lower than 1 - generally, the conversion to an integer might overflow here. The more stable approach would be to compare ray->t to global_max_steps*step_size and set max_steps to global_max_steps if it's larger, only doing the divide and cast otherwise. I can just go ahead and handle these two points, but maybe they're known and actually fine?

Sergey Sharybin commented

2016-05-09 23:13:07 +02:00

@LukasStockner, think those two would be safer to address those two points. Please go ahead.

Sergey Sharybin removed their assignment 2016-05-10 13:34:29 +02:00

Lukas Stockner was assigned by Sergey Sharybin

2016-05-10 13:34:29 +02:00

Sergey Sharybin commented

2016-05-10 13:34:29 +02:00

Added subscriber: @Sergey