OTOY Forums

Hi guys
I'm rendering a sequence in Maya batch and I have 2 minutes of preparation for the meshes and textures and 2 minutes for actual rendering for each frame. Can you please guide me for reducing the start up time? How can I optimize my scene to start faster? How the size of textures affects the start time? I usually use 2k or 4k tiff textures for each object.
thank you

PS:
Also I attached a text file from rendering a frame in batch if it helps.

To reduce preparation time for animation:

Use the "movable proxy" animation mode in render setting. Don't use the "Global" geometry type for any mesh:
- Every static mesh should have the "Scatter" geometry type.
- Every deformable object should have the "Reshapable proxy" geometry type.
- Every other mesh shoud use the "Movable proxy" geometry type.


--------------------------------

Depending on your scene, preparation time can be shorter if you presubdivide geometry in Maya,
intead of using Octane subdivision.

--------------------------------

Motion blur can add very long preparation time, especially for deformable objects.

-------------------------------

If you export your scene to render in standalone as ORBX with embeded Alembic,
preparation time will be reduced dramatically.

-------------------------------

File textures shouldn't add preparation time wich is mostly the time to extract Maya geometry.
Did you observ significant preparation time difference with or without file textures ?

Thank you calus, you are so kind as always

calus wrote:Don't use the "Global" geometry type for any mesh.
- Every static mesh should have the "Scatter" geometry type.

I think it is a typo. Isn't scatter for particle instanced objects?

calus wrote:- Every other mesh shoud use the "Movable proxy" geometry type.

So you mean statics should be moving proxy and not global. But I read this in docs that global objects only loads on gpu at the start frame, isn't it true?

calus wrote:Don't use Octane subdivision (slow), presubdivide mesh in Maya.

So I should smooth mesh the actual geo? I have alembic caches as characters and I didn't test smooth on alembic yet. I would test it so.

calus wrote:Motion blur can add very long preparation time, especially for deformable objects.

Yes, but can I get motion vector pass as a cheap computation?

calus wrote:If you export your scene to render in standalone as ORBX with embeded Alembic, preparation time will be reduced dramatically.

I didn't do this yet, so could you show me a guide to do this automatically please?

calus wrote:File textures shouldn't add preparation time wich is mostly the time to extract Maya geometry. Did you observ significant preparation time difference with or without file textures ?

No, I converted the huge tiff files to small pngs and no changes.

Thank you again

mosssi wrote:

calus wrote:Don't use the "Global" geometry type for any mesh.
- Every static mesh should have the "Scatter" geometry type.

I think it is a typo. Isn't scatter for particle instanced objects?

No it's not a typo,
the "Scatter" geometry type is a poor word choice in the pluggin,
and t's not the same thing as the scatter node in Octane stadalone,
it has nothing to do with instance,
Scatter geometry in Maya are only exported once at the beginig of the batch render as they are supposed to be STATIC objects.

mosssi wrote:

calus wrote:- Every other mesh shoud use the "Movable proxy" geometry type.

So you mean statics should be moving proxy and not global. But I read this in docs that global objects only loads on gpu at the start frame, isn't it true?

No, I realy mean :

Static objects = Scatter
Animated transform = Movable proxy
Deformable objects = Reshapable proxy



The "Gobal" geometry type is something competetely different, every "Gobal" geometry is merged into one big mesh before render.
Generally it's only useful for people rendering still image with not too much geometry, it's very unstable and slow with lots of polygons.
It can reduce render time, but preparation time is much longer and obviously it doesn't support instance, instancer, and passes.

Documentation about this is very confusing and incomplete (not explaining "Animation Modes").

mosssi wrote:

calus wrote:Motion blur can add very long preparation time, especially for deformable objects.

Yes, but can I get motion vector pass as a cheap computation?

Well, not realy, the same preparation time is needed for motion vector pass.
Octane is not really efficient for defomable geometry motion blur,
the only choice I can see is to reduce Camera Shutter or use another renderer for the vector pass.

mosssi wrote:

calus wrote:If you export your scene to render in standalone as ORBX with embeded Alembic, preparation time will be reduced dramatically.

I didn't do this yet, so could you show me a guide to do this automatically please?

This is realy easy just export as "OctaneRender animated scene" with embed alembic enabled. It will export an ORBX file contaning all assets,
open the ORBX in standalone and select renderTarget2 node to render,
or go in menu Script>batch render, to render the animation.

Wow, you add another level to my knowledge about octane. Thank you so much.
So as conclusion I should change these settings and try it again:

- Change global mode to scatter for static meshes.
- Turn off motion vector and maybe use automatic motion blur in nuke or render with another renderer.
- Optimize the props to look smooth enough in render

Standalone rendering seems convincing. I will test exporting to standalone soon enough.

extra question:
But I tested the alembic cache smoothing and it didn't work directly. So do you have an alternative for smoothing characters? Or maybe I should cache after smoothing.

mosssi wrote: extra question:
But I tested the alembic cache smoothing and it didn't work directly. So do you have an alternative for smoothing characters? Or maybe I should cache after smoothing.

well, smoothing optimization is about:
extraction time for pre-subdivided geometry compared to Octane opensubdiv conversion time.

For characters If you don't need more than 2 levels of subdivision, I wouldn't bother with pre-smoothing and would use Octane subdiv.
Better to keep the character pipeline as lightweight as possible...

calus wrote:For characters If you don't need more than 2 levels of subdivision, I wouldn't bother with pre-smoothing and would use Octane subdiv.
Better to keep the character pipeline as lightweight as possible...

You are right. Caching smoothed characters wastes lots of space on disk. I think it won't bother using 2 level for chars too.
Thank you man