Optimize Rendering in Mantra: Delayed Load Procedurals or Packed Primitives?

[Jero3d]

I have a question that has been bugging me for some time and I couldn't find much information about it. Which is the best and most efficient way to render many polygons? Using delayed load procedurals or using packed disk primitives? Or, am I confused and are they both doing the same thing and there's no difference between the 2 workflows? As far as I know, they both create instance geometry.

The documentation doesn't help much either, half of the things I read talk bout optimizing a render using delayed load procedurals, and the other half about using packed primitives. I'm wondering if packed primitives is the new workflow and using delayed load procedurals was the old way of doing it as is now obsolete? Here are the 2 workflows I'm talking about:

Packed Disk Primitives

Here I pack all my geometry and write it out to disk. I then load it back and change the load setting to "Packed Disk Primitives". Then I generate my IFDs and they are now referencing the geometry from disk instead of having to write them out (And the IFDs are a few KB or MB big). I then render using those IFDs.

Here is what the documentation says about it:

"Packed Primitives express a procedure to generate geometry at render time."

"Because Packed Disk Primitives by their nature are geometry streamed from a file, similar to Alembic primitives, we don’t have to use a special procedural to get smaller IFDs."

 

Delayed Load Procedurals

Here I write out my geometry (not packed) as bgeo and then make a Delayed Load Procedural shader and select the bgeo files I just wrote to disk. I then go to the Rendering -> Geometry tab of my object and load my Procedural Shader. I then create my IFDs and then render them out.

In the documentation about the delayed load procedurals, it talks about optimizing geometry this way. So I know there are these 2 ways, but are they both equally the same, or is one of them better than the other?

Which workflow do you use? Also, when using the packed disk primitives, if the geometry you want to render is unique and it can't be instanced (or there's just no point in doing it), do you still pack it (so its only 1 packed prim) and save it out? Or do you use the delayed load procedurals? Do you use any other workflow?

 

Any advice on this would be greatly appreciated! Thanks

 

[davpe]

hi,

both workflows are an effort towards processing massive geometries with not so massive computing demands and packed primitives are borrowing some ideas from delayed load procedurals.

packed primitives are somewhat more "modern" thing that has been introduced later than delayed load procedurals. it is more flexible as it can keep different objects as a separate pieces, allows you to manipulate material assignments per primitive and point attributes, while keeping very low memory stamp. also, unlike procedurals, packed primitive can exist inside of the hip file, not only as a file on disk, and can be unpacked and packed again on the fly as needed. in general, this workflow makes more sense in most cases these days and it is the one that's being further developed.

delayed load procedurals on the other hand are kind of archive files, similar to renderman's RIB archive or arnold's ASS file. it doesn't allow you to do much with it (other than rendering) and I'm unaware of any scenarios in which it gives you any notable advantage over packed prims. maybe in some extreme cases procedurals might still give you better performance (as it is simpler) but I haven't tested anything like that.

and by the way - either of these methods is not primarily about instancing. of course, you can use instancing with both of them in the same way as you can instance any other geometry. but mainly this is about accessing geometry more efficiently at cost of some limitations (you can only manipulate objects as a whole, not individual polygons, for instance, and that is why it is so much lightweight compared to fully editable geometry).

 

Edited December 6, 2016 by davpe

[Thomas Helzle]

I recently had a case that I found interesting in relation to this question: I did a bicycle-chain along a differential line growth spline. The individual links and bolts were rather lightweight but subdivided at level 3.

Playing the animation in the viewport was extremely sluggish when I had the subdivide node as one of the last nodes (subdividing all links together).

Then I moved the subdivision to right before the copy sop, so that the three link and bolt-parts were subdivided first individually and then copied. Quite a bit faster.

Then I put a pack-node after each of the subdivisions and playback was faster than realtime...

So yes, it can make sense to even pack individual pieces.

Cheers,

Tom

[loudsubs]

On 12/5/2016 at 5:14 PM, Jero3d said:

I have a question that has been bugging me for some time and I couldn't find much information about it. Which is the best and most efficient way to render many polygons? Using delayed load procedurals or using packed disk primitives? Or, am I confused and are they both doing the same thing and there's no difference between the 2 workflows? As far as I know, they both create instance geometry...

 

I don't think there's a huge difference between using a delayed load shader and using the 'packed disk primitive' option on a file sop.  they are both reading the geometry from disk at render time.  Also, keep in mind that your geo doesn't have to be a 'packed primitive' to be loaded as a 'packed disk primitive'. They are 2 different things.

I don't really use delayed load shaders anymore because they take more steps to setup.  Packed disk primitive seems to work just as well, and you just have to change the drop down menu on the default file sop. easy peazy. 

[Jason]

Yes, stick to Packed Disk/Packed Alembic for delayed loading. They do everything the Delayed Load Procedural did and a LOT more.