Why is animation slower than viewport

[Rik]

Struggling to work out what's taking all the time when saving an animation.
There's no animated geometry, just an octane camera moving through the scene.

Doing a preview animation and the actual rendering takes 1 second or less.
But there's a big gap of around 10 seconds between finishing a frame and starting the next.
Tried autoupdate movable proxy and update static geometry, still massive gaps between rendering. Everything is set as movable proxy.

Weird thing is, when using the octane viewport, once the scene is loaded, advancing 1 frame it starts to render again very quickly (well, once I'd turned parallel samples down to 2 and max tile samples to 4 anyway)
So in the Octane viewport there is no massive pause before starting to render again if camera moves.

Why is it almost instant in the viewport but has massive pause between rendering frames when saving as sequence of jpegs?

[paride4331]

Hi Rik,
it makes sense.
Rendering animation, every frame is like a new scene and Octane send info to GPU every time, then you would consider "movable proxy" option has an important role.
Consider all no movable proxy objects are packed in a single big pack (Octane gets much time to pack and transfer it)
Every frame Octane sends changed object info (material, moving, deformation etc etc) to VRAM.
A simple example to better undestand.
your animation is composed of two elements:
house - static
car - moving
total animation frame = 3 frames

case (A)
everything is set no movable proxy
frame 1: time to pack (house+car) + time to send (house+car) to VRAM = 30 secs
render time 10 secs
frame 2: time to pack (house+car) + time to send (house+car) to VRAM = 30 secs
render time 10 secs
frame 3: time to pack (house+car) + time to send (house+car) to VRAM = 30 secs
render time 10 secs
Total time to render: 120 secs

case (B)
everything is set movable proxy
frame 1: time to pack (house+car) + time to send (house+car) to VRAM = 30 secs
render time 10 secs
frame 2: time to pack (car) + time to send (car) to VRAM = 10 secs
render time 10 secs
frame 3: time to pack (car) + time to send (car) to VRAM = 10 sec
render time 10 secs
Total time to render: 80 secs

[Rik]

Thanks Paride.

Not sure I understand though. Sorry.

In the octane viewport there is only packing car and house to vram at the start. I see the scene preparation/scene building malarkey ONLY once but after that it's sweet fluid instant updated rendering. Not quite realtime but I guess dependant on hardware.

So why is there a difference between movements in viewport and in and animation?

[paride4331]

Hi Rik,
are you talking about the black screen between the frames during the render?
Regards
Paride

[Rik]

Not really.

Just don't understand why I can open octane render viewport, wait for the black screen/scene evaluation/building scene bit, then move camera around and the viewport starts rendering samples instanly.

There is NO pause.. At all. Which is great.

BUT...

moving the same camera by sliding the frame slider or even moving forwards/backwards 1 frame causes a delay before starting to render samples.

moving the (not animated) target of same camera is fine - NO pause, instant updates. All still good.

So why, just because it's animated does it have a delay?

Yikes - Except it's now stopped doing it.
Earlier, 1 second render, 9 second wait, and repeat.
Now for some reason, 1 second render, 2 second delay, repeat.

Sorry, don't know what's changed. It's still not as quick as whizzing round in the octane viewport but it'll do.

[tcheng00]

I think it makes sense if you consider the viewport doesn't update if you change your geometry and then you have to manually refresh or rebuild the cache. If you are simply applying a transform on the object, it doesn't need to rebuild the cache. My guess is that it just needs to rebuild the cache when it triggers a frame change as a catch-all solution. The same happens with other GPU render engines as well.