Redshift Render - Translation

[diparun]

Hey Yeah,

We've begun testing on a scene of 100 Agents on MiarmyExpress 7 0 0 7. Our preferred renderer would be Redshift. Now, when we render the agents, after AgentCache & Redshift>SetupRenderSequence, every frame gets translated at render time and is taking the same render time for every frame..

From our experience with RedShift, the translation stage occurs on frame 1, when textures are cached, and the rest of the frames directly start generating images i.e for example, a 3min first frame render, followed by 10secs per frame for the rest.. Whereas in Miarmy all frames go through the translation every frame, and every frame takes 3 min per frame..

So, 2 questions;

1. Can we skip the per-frame-translation and limit it to frame 01 only?

2. or Any way to export this translation map from Frame 01 and use it for the other frames ?

Please help, it's urgent, and a huge factor in deciding if Miarmy would be our preferred Crowd tool, as Render time optimisation is high priority.

Thanks in advance,

Arun

[Yeah YANG]

Hello Arun,

As our experience, redshift translates (or caches) both geometries and textures,
Based on our previous tests, the geometreies cannot be cached due to it will be constantly changed every frame.

But I think the textures are acutally cached indeed.
We have a film project which it will take 30 mins to cache the textures at the 1st frame and it will be much faster when render 2nd frame.


Since your scene can be rendered only in 3 mins (very short time) I guess the time cost is mainly on the geometry and other scene elements.

Cheers,
Yeah

May 31, 2019 0:33:10 GMT -5 diparun said:

Hey Yeah,

We've begun testing on a scene of 100 Agents on MiarmyExpress 7 0 0 7. Our preferred renderer would be Redshift. Now, when we render the agents, after AgentCache & Redshift>SetupRenderSequence, every frame gets translated at render time and is taking the same render time for every frame..

From our experience with RedShift, the translation stage occurs on frame 1, when textures are cached, and the rest of the frames directly start generating images i.e for example, a 3min first frame render, followed by 10secs per frame for the rest.. Whereas in Miarmy all frames go through the translation every frame, and every frame takes 3 min per frame..

So, 2 questions;

1. Can we skip the per-frame-translation and limit it to frame 01 only?

2. or Any way to export this translation map from Frame 01 and use it for the other frames ?

Please help, it's urgent, and a huge factor in deciding if Miarmy would be our preferred Crowd tool, as Render time optimisation is high priority.

Thanks in advance,

Arun

[diparun]

Thanks for the quick reply, Yeah

But in my test render, every frame takes the same time in sequence i.e 3 mins every frame.. Also, there is a progress bar "Preparing Scene" that starts in Maya when rendering a frame, which could be the Translation stage[about2mins] & followed by a second stage of GI Irradiance Cache & rendering[1min]

Our past workflow of instancing RSProxies of anim-cycles on Maya particles resulted in 3min renders for the first frame & <1min for the rest. So why isnt that difference happening in Miarmy Redshift workflow? Basically, I'm expecting smaller render times after the first frame is done. Also, I was told that Redshift can generate a translation map on Frame01, which can be used by the other frames. Any ways to do that in Miarmy too?

[Yeah YANG]

Hello Arun,

I think the time cost of 2 conditions are different.

1.
In your scene (RSProxies of anim-cycles) the cost maybe mainly on geometry generation and instance allocation, and this can be optimized by redshift itself.
I don't think the cost was come from texture translation in your scene.

2.
In Miarmy scene, the cost maybe mainly in geometry generation (which is procedural and will redo and run each frame), and the time cannot be shortend every frame.
If you have very large and a lot of very large texture map in Miarmy scene, you will see Miarmy can save the texture generation time.

We'll do more tests on this. But I think everything is smooth at the moment.

Cheers,
Yeah