OctaneX PR5 issues Tweet

[Weezer]

I was trying to render an openVDB explosion sequence, but the new PR5 plugin is struggling, It renders in the Live Viewer, although occasionally it just stops and I have to stop and restart the render. However when it comes to Picture Viewer render output, it does the first frame but then nothing happens; the second frame is apparently rendering (striped progress bar is moving) but it's not doing anything (six minutes and counting). tried a few times and same behaviour.

It's not the size of the openVDBs or a memory issue as these are low-res and pretty small at this stage of the simulation. I'm running the plugin on C4D R23 and macOS11, both latest builds. Mac Pro, 64GB RAM, dual RX5700XTs.

Octane X seems to work fine on everything else.

EDIT: I've just tried it again with a Forester tree (not a terribly complicated scene) and it simply stops rendering. I can restart the render, but quite soon after it stops rendering again. I can rotate the camera view in C4D, but the Live Viewer does not update. Seems to be a fairly fundamental problem.

EDIT 2: This release is just buggy as hell. It doesn't crash the app (which is nice), but stops working and locks up. Sigh. How long do we have to wait for some stability with Octane? Just paid for another month's subscription, but the app is unusable. Again. I wish Otoy would just feature lock it and work on making it super reliable – or just plain old reliable, come to that.

[bepeg4d]

Hi,
please, open the scene, then go to c4doctane Settings/Other tab, and, at the bottom of the panel, enable all the Log option checkboxes:

Then, load the scene in Live View, then in Picture Viewer, or until crash, and share the c4doctanelog.txt file that you find in c4doctane directory, or in the path specified in Settings/Other panel, thanks.

ciao Beppe

[Weezer]

Okay, did a simple scene with a plane and a Forester tree. It only takes short while before the LV becomes unresponsive. In the pic you can see the main viewport has changed, but the LV is not updating. The render has stalled and it says it's updating, when it clearly isn't.

I've included the log but it doesn't look very helpful.

c4doctanelog.txt

(1.66 KiB) Downloaded 171 times

[Weezer]

Tried a different scene, with some fairly complex objects, but again nothing really that bad (the Catalina version wold cope no problem). Kept getting out-of-memory errors, even though it I have Out of Core enabled with 48GB RAM, and a low 128MB GPU overhead. The preferences diagram showed spare memory on both GPUs. Eventually C4D locked up and I had to restart.

Log enclosed…

c4doctanelog.txt

(650.6 KiB) Downloaded 156 times

[Weezer]

Here's that scene. You can see there's plenty of GPU memory available, but the render has just stalled.

[bepeg4d]

Hi,
the first log is almost empty, while the second log shows that you have finished the memory:

In the second screenshot, VRAM is not finished, but Out-of-core is already active, and this is strange.
Probably you have reduced too much the GPU Headroom, please, bring it back to 300/512MB.

To keep the polygons count low, it is very important to enable in c4d the Render Instance, or Multi Instance (R20/R21) option for all the objects that support it, like MoGraph Clonerrs, Instance Objects, or Particle Emitter.

To keep the polygons count low, another trick is to disable all the Subdivision Surface objects in the scene, and apply to them an Octane Object tag, with the same subdivision settings in the proper tab.


In this way, the subdivision will be applied only at render time, and the scene will be much easy to export and handle.

About KitBush 3D scenes, unfortunately default KiBash 3D elements are wasting a lot of VRAM for textures, and must be optimized.

The first thing to do is to go to Live View , menu Materials/Octane Texture Manager, and select all Roughness and Metallic textures, and change their type from Normal (full RGBA) to Float (one Grayscale channel).
In this way, those textures will consume only 1/4 of VRAM, compared with the Normal mode.

To save more memory, you can also completely remove all the Black Metallic 4k textures, and set the Metallic value at 0.

Please check also the Emitter materials, the Texture Emission color is defined by a Texture, instead of a RGB Spectrum node.
Also these textures are useless, and can be replaced by a simple RGB Spectrum node that does not consume VRAM.

Another way to save a lot of memory is to convert all the textures from PNG 16bit, to JPG 8bit, in this way, you can save more than 3x memory.

Finally you can reduce the resolution of the textures from 4k to 2k, but this could have an impact in quality, if you need to see the textures very closely.

ciao Beppe

[Weezer]

Yes, I noticed those scenes were consuming a lot of VRAM and do need optimising. But the renderer is still stalling on scenes with very little going on. I’ll try and do some videos to show what I mean. I don’t think it’s entirely a memory issue, as with the openVDBs, which actually contain very small amounts of data. As with the original problem, the openVDB sequence failed to render after the second or third frame. This build still has unresolved issues which were not present on Catalina.

EDIT: Okay Beppe, I've PMed you with a link to a video – simple scene, definitely no VRAM memory issues. This clearly shows the awful behaviour I'm getting from this build.

EDIT2: There could be some conflict with another plugin – tried running a clean copy of C4D and so far it appears to be behaving itself. However things still aren't right, especially with the openVDB sequences I mentioned.

[Weezer]

There seems to be an issue with OctaneX just giving up after rendering a few frames. No idea what's going on: it happily does one or two frames but then simply stops. The fans on the GPUs spin down, and even though the timer keeps counting up, Octane isn't rendering. It happens repeatedly with the one scene I have, and has happened with others, which are otherwise fine in the Live Viewer.

I've just tried it with a sphere and a disc – same thing; stops after frame one. Then when you try to stop the render it freezes C4D. So OctaneX is currently unusable for me. Great.

It's a Mac Pro with dual RX 5700XTs, – nothing out of the ordinary. Like I say, I had none of these issues with Catalina.

[plasmapeppers]

I haven't tried VDBs, but going out of core and rendering image sequences work fine for me. I think the key difference between us is either that I am only using 1 GPU or what I think is more likely is that I am using a VII eGPU, which is based on the Vega 2 architecture and you're using 5700XTs, which are based on the Navi architecture - basically I suspect this has something to do with the Navi drivers on Big Sur. For example, here is a quick turnable render of another KB3D set: https://streamable.com/txo5xb

Hardware Specifics:
Mac mini 2018 i7-8700B + 32GB RAM
Radeon VII eGPU with Razer Core X enclosure
macOS Big Sur 11.0.1
Cinema 4D S22 (but R23 has been fine as well - using S22 because my X-P License ran out on S22)

[Weezer]

Both GPUs were working fine under Catalina. I thought Big Sur was supposed to have improved drivers! I mean they're both in the machine, I'm not even using an eGPU connection.

Just tried the same scene in R21 and got the same behaviour: stops rendering after first few frames. Back in R23, I can see that using the Live Viewer, both GPUs are up around 95% use in Activit Monitor. Then in the Picture Viewer render Octane managed three frames, then one GPU drops to 37% (the one driving the monitor) while the other is zero.

I tried rendering with just one GPU, but the same thing happens. Three frames is the record. Yay.

I really don't think this is the fault of my system, given nothing has changed physically since Catalina.