Artifacts after exporting C4D as ORBX Tweet

[Cromo]

Hello!

first-time forum poster, please let me know if any of this is not conform the forum rules.

I am working on a project that I intend to render on the render network, however, some shots had weird artifacts, that only appeared after the ORBX export in standalone, but not in C4D LV or PV renders.
It's strange because earlier ORBX exports caused some ray epsilon-related issues that couldn't be completely resolved, as changing this parameter does influence it, but doesn't resolve no matter what value I try.
The similarity to that issue and this one is that they only show up in Octane Standalone after the ORBX export, but are gone if I were to render in C4D octane

The most interesting part is that exporting a single frame of the entire animation does not result in this artifact, and this works for up to a max of 10 frames, at 11 frames ORBX export to standalone the artifact would kick in, and rendering batches of 10 frames isn't ideal realistic for the length of the animation..

I haven't found a workaround let alone a solution so far, and narrowing down the troubleshooting process is slow due to having to export entire animations and render it in Octane standalone, additionally, my scene has quite a lot of very large textures, so exporting scenes to render also takes time, and leaving out the materials for the troubleshooting phase doesn't seem rational either, as the issue is isolated to a certain material/polygon selection.
So having run out of options, and out of hope for troubleshooting a bit, I turn to the forum as a last resort to proper help having tried Discord and Reddit to no avail.

my conclusions so far:
- feels ray epsilon related, not sure
- only shows up after exporting ORBX from cinema 4D and opening in Octane standalone
-


Specs
Cinema 4D 2023.1.3
Octane 2022.1.1-[R2]
OS Windows 10 Version 22H2
GPU 2x GTX 1080ti
Processor 13th Gen Intel(R) Core(TM) i7-13700K 3.40 GHz
Installed RAM 64.0 GB

[skientia]

Ray Epsilon is scale related and dependent. The proper way is a scene with plausible scene scale. R.E. comes into play in atypical cases (larger than usual scenes, and vice versa... smaller).

It could be R.E. related but caused by an "alpha" texture file / node setup.
Is it the case?

Could you share the Octane Kernel settings?
It would be complementary information, as well as versions of Standalone, C4D Plugin, OS and GPU Driver.

PS: the appropriate forum would be Standalone or the C4D Plugin one, for the next times.

[Cromo]

My bad for getting the wrong forum for this, I'm still navigating myself with the ways of the forum.
the objects in the scene are about 15x80x30 so I would say too close to your primitive cube size to be considered exceptionally large or small, so maybe we can rule out R.E.

What would you mean with an alpha texture file / node setup?
I wouldn't know what kind of setup could cause this, and any theory I might have is out the window because it only happens in the standalone.

But according to the images of how it looks I'm gonna assume the issue looks associated with a certain material indeed, but I'm clueless about what I could have done wrong.
Would you mind elaborating as to how a material/node setup could cause this? as I have somewhat of an elaborate composite material set up, with quiet a few 8K textures, including normals and black and white maps/masks

my Octane version is 2022.1.1-[R2]
GPU driver is Version 556.12 - Release date: 06/27/2024
Cinema 4D version 2023.1.3
Windows 10 version 22H2

thank you

[skientia]

the objects in the scene are about 15x80x30

Fair to assume the unit is centimeters?

What would you mean with an alpha texture file / node setup?

Transparency happening at shading level, mix/layered such as a label on a bottle (typical scenario).

https://render.otoy.com/forum/download/file.php?id=93952&t=1

Judging by the provided screen capture of the kernel settings, the parameters haven't been setup appropriately according to the scene.

Some pointers ("red flags"):
* high (default) ray depth values (unnecessary for most cases)
* Caustic Blur default instead of maxed out (for actual caustics, Photon Tracing Kernel is the way to go)
* Keep Environment is rarely a necessity and likely not here, based on the provided renders and likelihood of the post-compositing absence
* Parallel Samples at default (VRAM headroom allows to push it to 32, the max)
* Adaptive Sampling is questionable, and hardly properly set without the Noise AOV to judge the sampling noise distribution

Render-time can be reduced as well as optimized sampling (fireflies and whatnot) by following this guide.

In the ("Camera") Imager, is partial alpha disabled (default)?


The linked guide also shows double-checking pointers such as mesh intersecting, etc. Worth going through them all and ensuring everything is properly set.

Questions and important sections in bold for readability sake.

[Cromo]

Yes sorry, those units are in centimeters indeed.

There is some subtle specularity happening, and a 3-layer composite material that I can share as well.

Thank you for addressing the pointers in my kernel, I corrected those, but didn't fix unfortunately though

partial alpha is disabled in the camera imager yes.

Also this will be taken through post, there's a bunch of AOV's set up, but I wouldn't need the keep environment,

[skientia]

A common trouble-solving process is to disable step-by-step each elements and test out to potentially pin-point the culprit.
Here, the shading (by large groups as shown on the screen capture, such as disabling the displacement entirely)

Another suggestion would be to download the latest Standalone 2024 Alpha and test in it.

[Cromo]

Shouldn't the standalone be corresponding to the Octane plugin version? which then again should correspond with the cinema 4D version.
I am using Cinema 4D 2023 because the latest 2024 was unusable frequent amount of crashes, and I had to downgrade to a 2022 version of octane render plugin, as the newest one wouldn't be recognised by cinema 4D.

However, if I can have the newest standalone, I will try that now, thanks! as the problem has appeared exclusively in standalone.

[frankmci]

Node setup for 10 products each its own color variant on the same model, all nodes are connected cross-material, so 1 transform drives all the sticker decals for all color variation materials for easy changes, I don't know if this could be problematic potentially though

I remember having issues with linking nodes across materials in C4D years ago until Ahmet set me straight: Because of the way C4D works internally, each Octane node technically "belongs" to a specific material and no other. Because of that, there can be odd glitches as a node tries to pass info to nodes other than what C4D considers its owner. As such, there's a bit of a behind the scenes juggling going on during render time that's a little different when rendering to Octane in the host app vs. after the scene has been exported/recompiled as an ORBX.

I wouldn't be surprised if your texture Displacement is especially sensitive to this issue.

If it turns out to be the multi-parented Transform node causing it, you might try linking attributes of multiple materials through an Xpresso node instead of trying to share one Octane node. I'm not sure how that gets translated into ORBX on export, but I've had luck with it.

[Cromo]

Oh wow Frankmci, I think you nailed it on the head.

I did some tests turning off the displacement and it did remove the problem of the streaks.
However unfortunately ORBX export introduced some other glitches, which likely had to do with the cross-material connected nodes, this is something I did in an attempt to optimize as I thought more nodes or image texture consume more Vram.
Then the consideration to untangle this cross-material connected node system that involved 30 different materials just to make the ORBX export work (which wouldn't be guaranteed success) didn't seem a justified time investment being on a deadline.

Considering these issues were solely related to the export of ORBX, I went in search for an alternative renderfarm, which solved everything instantly.
RNDR is working on implementing the possibility of uploading .c4d files, so this probably won't be an issue in the future.

Thank you for clearing that out though and providing this very insightful snippet of wisdom from Ahmet Aoktar, I know he always watches over us
I think this thread can be considered resolved for now, as my recommended workaround is to find a way to render locally when faced with ORBX adversities, if local renders are too heavy for your system, find a render farm that lets you use a virtual desktop, that's what I did.

Thanks again!

[frankmci]

I'm glad that helped! But you might not want to give up too easily on shared material controls via XPresso. Since XPresso sits "outside" the normal material node structure, I think it avoids the problem of the single parenthood limitation while still allowing for a simplified scene diagram and more centralized control. My problem was back in Octane 2x or 3x, so the innards of both Octane and C4D may have changed quite a lot since then.

Still, XPresso is a very useful toolset to have in your toolbox, even if you don't get down into the weeds. Sometimes it's as simple as setting up a convenient null with a bunch of User defined attributes that drive the corresponding attributes on a whole slew of different object and object types by setting driven keys. It does take some more time during setup, but can make the animation process itself go very quickly.

And yes, we are very fortunate to have Ahmet cranking away at this stuff for so many years, and for both his direct availability and his remarkable responsiveness as a developer. I hope Jules treats him very, very well!