OTOY Forums

I was wondering if there was any detailed documentation on instancing and movable proxies in Octane, especially with regard to optimisation and also the loading of a scene at every frame when it comes to render time. I've found some info online, but all very broken bits of advice, I'm not actually sure what's happening under the hood. Main points to raise from my finding are:

If I have a lot of instances of the same object it is slow as hell to load the scene, and it uses a lot of vram.

If I select all of those objects and check their movable proxy checkbox then they load quickly, use next to no vram and I can move them about in the viewport.
If this is true why isn't this 'magic' checkbox always off? There must be some tradeoff surely.

When it comes to actually rendering the final sequence / not using the Octane preview window, Max reloads the geometry for every single frame. This seems crazy as I can scrub through the timeline with the Octane frame buffer open and it doesn't need to update which is awesome. And with movable proxy checked the objects that are moving also update. So why when I need to render the final sequence does it need to reload all of the geometry every time?

Also, there's the Autoupdate Movable Proxy checkbox in the render settings, what does this do? It seems movable proxies by their very nature automatically update with or without that checkbox.

after a bit more testing I've also discovered that rather than having for example 10,000 instanced spheres, it seems more efficient to attach 10,000 spheres as one mesh. Seriously what is the deal with instancing and loading time in Octane for Max?

movable proxy is helpful when you need to scatter say hundreds of trees with leaves in a scene - which would not fit in your 2, 4 or 6 gigs of vram. if your scene fits without movable proxies it renders a little faster than with the option checked.
I personally try not to use movable proxies as long as it fits.
when you have animated objects (movement or deforming) you need to check the option. the auto update option has to be turned on for final animation and as I understand it's just an option to DISABLE for faster previewing the camera animation without loading the moving/deforming geometry.
(edit: the following part is nonsense
of course if you combine those two scenarios (1000 static trees - 10 different flavors + some ball rolling around) you have a problem:
the lightweight ball animation will load nearly immediately on the next frame, but the 10 different flavors of trees will take you the 2 gb to reload into your cards every frame - even if they do not move - and THAT IS A WEAKNESS of the movable proxy approach.
A solution would be an object based "auto update movable proxy", where you could control which proxies actually get reloaded, in my example just the rolling ball.
hope this helps a bit. and yeah, THIS IS A REQUEST ALSO.
cheers
boris

EDIT: I just tested and actually OCTANE is SMART enough NOT TO RELOAD movable proxies that are not deforming/moving
sorry octane team for my to fast conclusions.
would be nice to have a "struck through" option in the options to edit a post like this..

Rico_uk wrote: When it comes to actually rendering the final sequence / not using the Octane preview window, Max reloads the geometry for every single frame. This seems crazy as I can scrub through the timeline with the Octane frame buffer open and it doesn't need to update which is awesome. And with movable proxy checked the objects that are moving also update. So why when I need to render the final sequence does it need to reload all of the geometry every time?

Also, there's the Autoupdate Movable Proxy checkbox in the render settings, what does this do? It seems movable proxies by their very nature automatically update with or without that checkbox.

hmm, I wasn't aware of that. haven't tried that lately but on our last animation project the behavior was like I explained in my last post. are you sure about that? maybe there is some caching involved which is not implemented in the actual render process.

Rico_uk wrote:after a bit more testing I've also discovered that rather than having for example 10,000 instanced spheres, it seems more efficient to attach 10,000 spheres as one mesh. Seriously what is the deal with instancing and loading time in Octane for Max?

with such a high number of instances i always get in trouble even in 3ds max. I guess that's not only an octane problem. octane has to convert these 10000 spheres in one mesh (renumbering vertices) if not movable proxies. if they are MP, octane has to store the position, rotation, scale 10000 times. so the previously attached spheres (one mesh) will perform better (no renumbering).
I am not sure about all that but that are my explanations from my experiences with huge scenes.
I also think that plugins like forest or multiscatter do a better job feeding octane with movable proxies than the 10000 instances hanging around in the scene if you understand what I mean.
cheers
boris

Thanks Boris, that's a really useful explanation. I have indeed found that Multiscatter and Forest Pro load much faster, hopefully one day Octane will be able to load all instances / geometry this fast.

I'm still a bit unclear as to the best workflow for Movable Proxies, but I'm hoping in version 2 for Max there will be some better documentation and more options. I love the idea of having only moving and deforming geometry being reloaded with every new frame, it's just strange that this seems to be how the Octane preview works. Maybe they could automate the Octane preview frame buffer to be able to save sequences.

I must say though that I've been doing some pretty extensive testing with Octane on a current job, I've got huge (and I mean huge!) textures, lots of textures, millions of polys, multiscatter trees, etc. all in one scene, and once loaded I'm getting some pretty insanely low render times. It does seem that once the first frame has loaded then subsequent frames take less time to load, so I guess more is happening under the hood to store static geometry. I'm doing all of that on 2 x 780ti cards with only 3gb of ram and Octane is absolutely destroying these test scenes, just takes about 40 seconds to load everything.

If I get a chance I'll do a screencast video to highlight these things.

Weak point of movable proxy is lower render speed.

Rico_uk wrote:I'm doing all of that on 2 x 780ti cards with only 3gb of ram and Octane is absolutely destroying these test scenes, just takes about 40 seconds to load everything.

I had similar experiences with a scene with animated forest ground geometry and some huge wind animated red wood trees.
I don't think you can blame octane to much on that. One thing to consider is probably the capability of your motherboard especially your processor to move those huge amounts of data between your main memory banks and the PCI slots.
a couple of factors will limit your throughput there:

- dual processor boards probably will perform better, having separate access to their according memory banks
- main bus controller speed/layout
- number of pci lanes
- pci bus number/layout
- memory speed
etc...

I stumbled over a couple of threads with performance considering those things. Would be nice to see some benchmarks on different hardware setups (consumer board vs. server grade stuff).

Karba wrote:Weak point of movable proxy is lower render speed.

Aha, so it's not just my imagination.

I've been setting up mega scenes with a lot of Proxy trees. The scene takes forever to load, but renders very quickly.

Unfortunately, when sending to Backburner, the scene loading time is added to the render time. I was wondering why my render times would increase dramatically when sending to Backburner. Now I know why. Very good to know.

Very helpful thread!

best,
O

Olitech wrote:

Karba wrote:Weak point of movable proxy is lower render speed.

Aha, so it's not just my imagination.

I've been setting up mega scenes with a lot of Proxy trees. The scene takes forever to load, but renders very quickly.

Unfortunately, when sending to Backburner, the scene loading time is added to the render time. I was wondering why my render times would increase dramatically when sending to Backburner. Now I know why. Very good to know.

Very helpful thread!

best,
O

With movable proxies scenes take less time to load and consume less memory(in case if you use instancing) but after loading render slower.