1
$\begingroup$

I am brand new to Blender. I'm running Blender 2.8 on Ubuntu 20.04. I've been working through an explosion tutorial. I have a simple-but-glorious explosion using only a single emitter and I've been able to successfully render it at 20% of its original size (original size is 1920x1080). This takes about an hour to render 45 frames.

Blender has crashed twice now trying to render it at 40% of its original size -- this takes about 4-5 minutes per frame on average. The second time I babysat it as it worked, watching the amount of memory used in the Blender Render window and in the bottom right of the main Blender window. Blender does not appear to be using all that much memory. The machine has 12GB RAM, about 8GB of which stays free during the render process. Blender's bottom right status says Blender is using about 95MB of RAM. The Blender Render window says the max memory is around 55MB. The computer seems to have plenty of memory that is not being utilized.

Blender happily rendered from frame 5 to about frame 39 before I stepped away from the computer. When I came back, Blender had crashed and disappeared. There is no blender.crash.txt or test.crash.txt that I can find anywhere on my file system. I am only trying to render frame 5 through 50 -- but I'd like to make sure I can render this at its full 1920x1080 size.

I know there are ways to work around such a crash but I'd very much like to know what the problem is. It takes so long to run the render before the crash happens so reproducing the problem to see if I've fixed it is going to be prohibitively time-consuming.

I don't think the issue is related to the graphics card because, AFAIK, my old GeForce GTX 470 doesn't speak CUDA:

$ nvidia-smi
Mon Apr 12 10:15:04 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.141                Driver Version: 390.141                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 470     Off  | 00000000:02:00.0 N/A |                  N/A |
| 40%   58C    P0    N/A /  N/A |    506MiB /  1216MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
+-----------------------------------------------------------------------------+

I have a GTX 1050 Ti on the way.

At any rate, is this a memory problem? A bug in Blender? A graphics card issue? I think the Blender bug seems most likely because blender doesn't seem to use much RAM and the graphics card doesn't seem to come into play.

**EDIT: ** I saw this note in the docs:

More logs can be obtained by running Blender from Command Line and using --factory-startup --debug-all flags. See Launching from the Command Line and Command Line Arguments.

and decided to try:

# launch blender from terminal
blender --factory-startup --debug-all > ~/trash/blender/debug-output.txt 2>&1 &

I ran the render gain and it looked mostly normal but crashed again. Most of the output looks normal, but the last line seems important:

blender: /build/blender-RL3axj/blender-2.82.a+dfsg/intern/cycles/kernel/../kernel/kernel_accumulate.h:690: ccl::float3 ccl::path_radiance_clamp_and_sum(ccl::KernelGlobals*, ccl::PathRadiance*, float*): Assertion `!"Non-finite final sum in path_radiance_clamp_and_sum!"' failed.

EDIT 2: I attempted the workaround I linked in my post (rendering one frame at a time as PNG file) and apparently there's something in my blender file that is causing the problem. This looks like a bug or a corrupt file or something. Rendering this one frame:

blender -b "/path/to/explosion3.blend" -f 37

Triggers the fatal error. These are the last few lines of output:

Fra:37 Mem:68.17M (0.00M, Peak 68.43M) | Time:01:16.95 | Remaining:01:41.59 | Mem:54.20M, Peak:54.32M | Scene, View Layer | Rendered 31/84 Tiles
Fra:37 Mem:68.17M (0.00M, Peak 68.43M) | Time:01:20.55 | Remaining:01:39.83 | Mem:54.20M, Peak:54.32M | Scene, View Layer | Rendered 32/84 Tiles
blender: /build/blender-RL3axj/blender-2.82.a+dfsg/intern/cycles/kernel/../kernel/kernel_accumulate.h:690: ccl::float3 ccl::path_radiance_clamp_and_sum(ccl::KernelGlobals*, ccl::PathRadiance*, float*): Assertion `!"Non-finite final sum in path_radiance_clamp_and_sum!"' failed.
Aborted (core dumped)
$\endgroup$
2
  • 1
    $\begingroup$ I don't know anything material about the offending part of the cycles path-tracing engine, so am not sure what calculation is running into (I assume) precision issues internally to yield non-finite values, but a quick google turned up this post with a similar stacktrace: developer.blender.org/T76238 It suggests you might be able to avoid the crash by increasing the relevant number of light bounces. $\endgroup$ Commented Apr 13, 2021 at 22:00
  • 1
    $\begingroup$ @NeverConvex I ran across a bug report here which was apparently resolved by using a different version of blender than the version installed using the Ubuntu Software installer (i.e. sudo apt install blender). The Ubuntu 20.04 default is Blender 2.82 (sub 7). I tried that same one-frame render command with Blender 2.92.0 downloaded from the Blender website and it rendered the problematic frame without complaint. I'm trying to render every frame now with the workaround and am optimistic. $\endgroup$
    – S. Imp
    Commented Apr 13, 2021 at 22:08

0

You must log in to answer this question.