Optimize movable proxy refresh between frames Tweet

[Jani]

Hi,

We're wondering if there was a way you could optimize the re-fresh of movable proxy's within an animations timeline. Here's the problem:

We have a scene containing some 15000 objects, large part of which is animated across 5200 frames, with certain animations taking place at the start of the timeline, some at the centre and some at the end. In fact, any object animated within the timeline is only animated once (i.e. a transform animation taking place between frames 2200 and 2700).

This animation is a construction sequence and 5 blocks of apartments in total get build in sequence - so basically only up to two concurrent blocks get constructed at the same time. The problem is that when we want to render out a draft animation for a client, the scene translation time is like 6-7 seconds, with rendering actually only taking about a second and a half.

I imagine the problem may lay somewhere with the fact that majority of the objects are set as movable proxy throughout all of the animation, even though octane only needs to have them updated within a specific time-frame. There is no way for me to dynamically set movable proxy on, or off depending on when an object gets animated, and even if I could, it would be incredibly time consuming to attempt to do that on such a vast array of objects.

Do you think there is a way for you to dynamically set objects as movable proxys for the duration of time that they are animated, and switch it off as soon as they become dormant? And perhaps do this at the beginning of rendering the animation so as not to eat any further time each frame to check which objects are going to move in the next one? Or do this concurrently with rendering?

I hope you understand my frustration with the fact that we have a very expensive system which is able to render frames very fast, but have no means of speeding up the scene translation time and have to inform clients that what would be 5 minute changes to the animation would take 8 hours to render out, only because of the time it takes to calculate changes of transforms between frames.

Thank you kindly for taking on this issue with me.

Kind regards,

Jani

[paride4331]

Hi Jani,
specifically, it might be useful to cut the animation of different parts; Using xrefs you could update all the scenes.
In this way you would be able to use movable proxy only when needed; on the other hand a single long-take-shot is never the best solution.
Said that, in my personal experience, I think movable proxy almost always faster than non movable proxy during the transfer process.
There may be some implications causing your issue, you may have PCIe bottlenecks or massive geometries and/or high resolution textures that fill the VRAM and force part of the scene to be moved to the Ram, back and forth a ogni frame that slow down the rendering process.
Regards
Paride

[Jani]

Hi Paride,

thank you for your response.

Since I posted this I did do a little digging. I found the following:

For one reason or another, doing a standard Max render is now consistent across all of the animation frames, with an average frame taking some 10s to render (longest sitting at 12, shortest 7, depending on the number of object set to change on any given frame). I don't know how that happened, but it did, all I did was a little bit of testing:

- first setting all of the objects to non-movable proxy results in camera updating instantaneously in OR viewport or max framebuffer (so essentially no overhead), but in my case I run out of memory due to forest pack instances and some cars scattered around, so I had to change those instances into movable proxy -> OR viewport/Max were still instantaneous at this point

- second, setting all of the objects animated within the whole scene, as well as all the instanced geometry to movable proxy, while everything else as non-movable, results are quite bad -> frame time in max FB increased to 1.5 minutes per frame and octane FB to some 10 secs of calculating per each change of frame, I don't know why octane exhibits this behavior - maybe a bug?

- third, I've exported the whole scene into standalone via ORBX and that seemed to work like charm, except that my animated opacity map started to randomly flicker on/off and ruined the whole animation(a behavior not experienced in MAX), but updating geometry within octane standalone seemed to be very fast, that is, at least until frame 2000, when it seriously started to slow down -> so at the beginning it took about 1 second for scene translation, and towards the end (5000th frame) it was taking 10 seconds for the scene translation. Interestingly, when exported in sections (i.e. frames 2000-3000) it still renders like charm so basically translation time is still sub 1 second - I therefore assume there is some kind of a bug which progressively slows down the scene translation time in between frames

So at the time of writing this thread I thought that the problem lay in the fact my scene contains some 15000 objects, and for octane to run down all of them to check whether there is an animation occurring for that specific frame took a couple of seconds. But now I'm no longer sure where the problem is. I also don't quite understand why does it take such a long time to update anyways - I mean game engines seems to be able to pull it off at much higher rates and still keep the framerate. I'm not going to pretend that octane should mimic game engines in this regard, as geometry and textures are generally a lot heavier in modelling applications, but shouldn't there be some smart caching system that would alleviate scene translation times being so high?

I will also point out that my scene, albeit being 15000 objects, is mostly made up of boxes and rectangles - not heavy geometry, and there are only a handful of 4k textured materials in place. It doesn't go out of core, as all of it fits into and RTX 2080 Ti's 11Gb.

I may be an outlier case, as in, I get to work with whatever I get from the architecture guys and they tend to produce a pile of mess in Revit, but that's not something I can affect. The geometry is simple, and so is the animation so I see no excuse for octane taking 10 seconds to deal with a position update across 500 objects on any given frame. Do you disagree?

Thank you for discussing this with me,

Regards,

Jani

[paride4331]

Hello Jani,
thanks for your reports, there are some interesting information; I will bring this post to the attention of the developers.
Regards
Paride