I've been trying to render a animation the past few days and can't get it done.
Specs: 2 * RTX 2070, 64 GB Ram (Configured 32 GB as OOC), Plugin-version: 2020.2.17.61 Studio, Nvidea-Treiber: 497.29, Win 10
I can render each frame, one by one, after another, without problems. If I render it as animation, the plugin crash's after , or while, finishing the first frame.
- Code: Select all
2022-01-02 18:52:28.474 15592 b2020.2.17.61 CUDA error 2 on device 0: out of memory
2022-01-02 18:52:28.476 15592 b2020.2.17.61 -> failed to allocate device memory
2022-01-02 18:52:28.488 15592 b2020.2.17.61 OptiX error for device 0: [ERROR] "sbt->raygenRecord" is null
2022-01-02 18:52:28.494 15592 b2020.2.17.61 OptiX API error for device 0: Invalid value
2022-01-02 18:52:28.500 15592 b2020.2.17.61 device 0: path tracing kernel failed
2022-01-02 18:52:28.505 10808 b2020.2.17.61 Render engine failure occured! (WARNING)
2022-01-02 18:52:31.582 15592 b2020.2.17.61 OptiX error for device 0: [ERROR] "sbt->raygenRecord" is null
2022-01-02 18:52:31.583 15592 b2020.2.17.61 OptiX API error for device 0: Invalid value
2022-01-02 18:52:31.589 15592 b2020.2.17.61 device 0: path tracing kernel failed
2022-01-02 18:52:31.594 10808 b2020.2.17.61 Render engine failure occured! (WARNING)
2022-01-02 19:00:36.192 10808 b2020.2.17.61 ON_dzMainWindow_aboutToClose
However, the normal render of the first frame is saved, but never any other passes, for example the denoised pass isn't saved. It sometimes even started the second frame but stopped immediately at 1 or 2 samples, because of the memory crash.
I don't understand why the second frame starts rendering when the post processing of the first isn't finished.
I've made a screenshot of the system-tab after rendering a single image in the normal viewport and I made a screenshot of the system-tab after the animation crashed. It looks like octane tries to put geometry and textures in the memory again which leads to the crash, even though there should be more than enough ooc memory.
After rendering a single image:
After one frame of animation rendering and memory crash:
Is it possible there is an issue in the order of execution between rendering frames?
Pretty annoying too: The memory crash while rendering animations is silent. It doesn't pop up. The progress in the animation rendering window just stops. It doesn't freeze, you can close the window. In fact, you have too stop the animation rendering or open the debug log too see the memory crash. And after the crash you can't even restart the rendering. You have to close the Daz3D and restart again. Whole Process needs around 10 minutes for me -> Quite frustrating when testing what the issue might be.
So it would be nice if either the crash pops up directly or we are able to move to another view / tab inside daz3d too see the system tab.
I tried various headroom setups from 100mb to 1024mb. Didn't seem to make a difference.
Frustrated I tried to export the animation as alembic too try render it in the standalone. The app manages to export 1 -5 frames and than crash's the DAZ app completly. No entries in the octane debug log. I saved the crash-log of DAZ, the first few lines of the xml:
- Code: Select all
<report version="1">
<platform>Win64-x64</platform>
<application>DAZ Studio</application>
<version></version>
<computer>xxx</computer>
<ips>
<ip>xxx</ip>
</ips>
<user>xxx</user>
<timestamp>132856254681970000</timestamp>
<error>
<what>ACCESS_VIOLATION</what>
<process>
<name>DAZStudio.exe</name>
<id>11564</id>
</process>
<module>C:\Program Files\DAZ 3D\DAZStudio4\octane.dll</module>
<address>xxx</address>
<function>
<name>Octane::isGreyscalePass</name>
<offset>15770512</offset>
</function>
<file></file>
<line>
<number></number>
<offset></offset>
</line>
</error>
<usermsg></usermsg>
<syserror>
<code></code>
<description></description>
</syserror>
<comerror>
<description></description>
<helpfile></helpfile>
<source></source>
<guid></guid>
</comerror>
<registers>
...
I'm not sure what else I could do, other than buying overpriced RTX 3090 cards, which even only might work.
