Optimizing Carrara-OR4C Performance for Animation Tweet

[Mythmaker]

My interest is animation so I'm biased to speed over hyper photo-realism.

After some research, it seems to keep things lean, it's best practice to (in order of savings)
- cut down total map numbers
- cut down map size
- better larger fewer mesh than lots of meshes (and presumably Octane reads mesh = single OBJ file and nothing to do with welded vertices)
- use Octane shader if and when possible instead of Carrara's
- reduce unnecessary multiple shaders per scene object

What I'm less clear about is resource management on the Carrara/ DS content front, specifcially frequent use of heavy geometries like Genesis (20K to 80K).

I'm not sure if Carrara reads all Genesis in the scene as an geometry instance so only fetches/ compiles the mesh once. And even if that's true, that efficiency is translated across to OR4C.

The above is probably a no, as I've also noticed, Octane seems to compile character mesh every keyframe, so it probably considers every morph state as a "new" geometry in the scene. Correct?

Then again, OR4C is smart enough to know - if I have 3 Genesis characters sharing the same texture map, there is only 1 texture map. So I remain hopeful.

Appreciate input from more experienced Carrarists... Thanks.

[Sighman]

My interest is animation so I'm biased to speed over hyper photo-realism.

After some research, it seems to keep things lean, it's best practice to (in order of savings)
- cut down total map numbers
- cut down map size

map size and quantity really only affect memory usage. The size and number of mats does not affect render time significantly.

- better larger fewer mesh than lots of meshes (and presumably Octane reads mesh = single OBJ file and nothing to do with welded vertices)

Depends. The plugin takes advantage of the instancing capabilities of Carrara and so it can be cheaper to duplicate/replicate meshes than to load a giant single mesh. Also, you should separate 'static' mesh from 'animated' mesh. Static mesh won't need to be reloaded.

- use Octane shader if and when possible instead of Carrara's

Does not make a lot of difference. Octane shaders are generated from the Carrara shaders and loaded once (unless they are animated).

- reduce unnecessary multiple shaders per scene object

Again not a big factor to render times. It is the type of shaders you create rather that the quantity that affect render times. For example, using SSS and other caustics would force you to use the path tracing or PMC kernels which will really slow things down.

What I'm less clear about is resource management on the Carrara/ DS content front, specifcially frequent use of heavy geometries like Genesis (20K to 80K).

I'm not sure if Carrara reads all Genesis in the scene as an geometry instance so only fetches/ compiles the mesh once. And even if that's true, that efficiency is translated across to OR4C.

The above is probably a no, as I've also noticed, Octane seems to compile character mesh every keyframe, so it probably considers every morph state as a "new" geometry in the scene. Correct?

Then again, OR4C is smart enough to know - if I have 3 Genesis characters sharing the same texture map, there is only 1 texture map. So I remain hopeful.

Genesis and genesis 2 have a base mesh that is fairly light until you increase the mesh detail level. The default rendering level for these models is set to 2 (or 3) which is why they consume a lot of memory and take a while to load into Octane. If you are not doing extreme close-ups then you can reduce the detail level and save yourself some memory and loading times.
Also, Octane does not know anything about bones or IK, it only knows mesh. If the mesh of an object changes in any way then it needs to be reloaded. So moving a finger or an eye on Genesis will require the figure's entire mesh to be reloaded.

Appreciate input from more experienced Carrarists... Thanks.

Enjoy.

[EddyMI3D]

What really drives up the render time is the number of light sources.
The more you have , the longer it takes.

Eddy

[Mythmaker]

Thanks for the thorough response Sighman. Good to know Octane/ OR4C is far less fussy than I thought (most of my render speed notions come from working with game engines)

So memory limit doesn't impact speed, good news. But I only have one GPU though. So last few days of texture atlasing work for Genesis still relevant for economising my workflow I guess.

It is the type of shaders you create rather that the quantity that affect render times. For example, using SSS and other caustics would force you to use the path tracing or PMC kernels which will really slow things down.

I've noted that in my OR4C exercises last two days. Turning on Octane Displacement ground things to a halt/ near crash/ coffee break.

One 'reflection' related trait - again could be my noobness - it seems for a mirror reflection treatment, Octane material reflection (via Speculariy) is more "expensive" than Carrara reflection (default with only a 1-100% value added)...

The default rendering level for these models is set to 2 (or 3) which is why they consume a lot of memory and take a while to load into Octane. If you are not doing extreme close-ups then you can reduce the detail level and save yourself some memory and loading times.

I've come to this conclusion yesterday too. Now I settle for SubD 0 for most, and closer-ups at 1. Good to get official confirmation...

And btw really liking the on-screen larger graphical report on number of geometry / textures in the scene. I accidentally activated that clicking on the progress bar.

Also, Octane does not know anything about bones or IK, it only knows mesh. If the mesh of an object changes in any way then it needs to be reloaded. So moving a finger or an eye on Genesis will require the figure's entire mesh to be reloaded.

How about simple transforms? Does OR4C consider a replicated mesh with local non-joint motion a reload candidate? Say an instanced group of floating plastic ducks with randomised colour shader?

Overall I'm getting the hang of Octane-Carrara shader translation. Beginning to have fun!

Thanks again.

[Mythmaker]

What really drives up the render time is the number of light sources.
The more you have , the longer it takes.

Make sense... I haven't played with Octane lights yet, just using Octane background to test Genesis texture and custom shaders.

Going from LDR to HDR background makes a great deal of qualitative difference to specular reflection, and not so noticeable render speed change too.

Loving the plugin's implementation of background too, savings in clicks and workflow speed is as valuable as saving in render speed.

[Sighman]

With only one GPU you will need to share your graphics memory with your operating system. So when I say the size of a texture map does not matter from a rendering speed point of view, the number of texture maps you can load will definitely be affected by your available GPU memory. You can also turn on Out Of Core texture maps but this will have an impact on render speeds.

Blurry reflections will also take longer to converge.

Displacement is actually adding more geometry detail to the scene so there will be more surfaces and reflections to calculate and so forth. It is better to use bump or normal maps unless you are doing close-ups or focusing on details.

Transforms are cheep. If you are just moving/rotating/scaling a mesh then the mesh does not need to be reloaded.

When playing with light sources it is better to use an emitter with high power values and very small texture color values. I don't know why but convergence is much faster when you do it that way.

[Mythmaker]

With only one GPU you will need to share your graphics memory with your operating system. So when I say the size of a texture map does not matter from a rendering speed point of view, the number of texture maps you can load will definitely be affected by your available GPU memory. You can also turn on Out Of Core texture maps but this will have an impact on render speeds.

Does 'out of core' mean 'external'? I tend to load texture maps from a centralized image folder on a content SSD.

I haven't had OR4C blacking out on me so far, did have a case of out-of-memory black out with a luxuscore test with standard V5 material set involving multiple 4K textures.

Even then I still prefer to keep it lean, allowing maximum 1 x 4K texture per main character/ per clothing item. HDR only for background, probably also need to slim those sIBL freebies down.

Displacement is actually adding more geometry detail to the scene so there will be more surfaces and reflections to calculate and so forth. It is better to use bump or normal maps unless you are doing close-ups or focusing on details.

Am a ZBrusher/ game editor user so am familiar with displacement/ normal/ bump difference.
However...
Something I've not been able to conclude after much scouting around is:
- is there a performance difference loading displacement map under Carrara shader VS Octane Material?
- Procedural displacement: is the performance cost the same with Carrara shader, VS Octane patterns/ LiveDB displacement?

When playing with light sources it is better to use an emitter with high power values and very small texture color values. I don't know why but convergence is much faster when you do it that way.

This is a good tip. I guess color saturation is just consistently expensive. This will be relevant when it comes to HDRI use... Like, Carrara loaded HDRI is more expensive than typical 2-color blend Octane Sky...

[Sighman]

Out of core means textures are loaded into system memory if you run out of GPU memory. This is obviously slower to render but you are no longer restricted by what you can load onto the GPU.

Carrara displacement modifies the mesh before it is sent to Octane. Octane displacement is applied on the GPU.

Octane does not support procedural displacement (yet).

[Mythmaker]

Okay so 'out of core' allows me to make Octane use a bit of CPU help... Good to know this option exists.

Octane displacement is applied on the GPU.

So in practice this translates to faster render, correct?

I need to read up more on Octane displacement - tessellation relationship...

Thanks again for the pointers.