Link to cached geo in ifd files

[mupapabear]

Hi there,

 

 

I am working on a few pyro shots which get quite heavy geo wise (around 6+gb per frame).

We are using "Royal Render" (comparable to Deadline) to deploy to our farm. RR needs ifd files.

My question is, if there is a possibilty to just link to the already cached bgeo files in the ifd?

All machines have network access and could just grab the bgeo files.

 

As it stands right now, I spend hours caching the bgeo files, then generate the needed ifd files via the rop,

which again takes hours and produces quite big files aswell (comparable in size to the geo files).

 

So to me it seems, that the ifd files not just link to, but contain the actual geo - which seems a bit odd to me. Am I missing an option to check?

Do I somehow need to declare the geo?

So far I only found the option to compress the ifd file.

 

I am working on H14.

 

Help is apprecieated.

 

Alex 

 

 

 

 

[jujoje]

One thing you should check is that you are loading the sim's caches back in as a packed object. That way the ifd generation should be super fast as it's just pointing to the file on disk rather loading the actual geometry.  

[mupapabear]

How would I go about doing that? Instead importing it in the DOP Importfiled , read back with a file node and then use a pack node? 

[fathom]

use a delayload geometry procedural.

 

create a delayload procedural shader in shops (or even in a shopnet for your object).  that shader is then given the filename of your on-disk geo.

you apply that shader to the "geometry shader" property on your object and you TOGGLE OFF force geometry output (so your geo does not feed your procedural since the procedural is just reading from disk).

Edited November 26, 2015 by fathom

[mupapabear]

Hey, thanks for that. Unfortunatley it does not seem to decrease the ifd filesize. I created an empty geo sop to test it out and it still seems to cache the geo to the ifd.

[fathom]

you sure you're not including the original geo in your rop?  it will most definitely not write the geo to your ifd.  instead it will write a single line that tells mantra to load it from disk.

[mupapabear]

Yep, I´m positive. Could you take a look? I might be missing sth stupid.

The "render_pyro" sop is empty and the procedural shader setup. I can render it, so the referencing seems to work.

But the generated ifd files are still roughly the size of the geo.

 

Thanks a lot

DB_PROD_070_v005_out.hip

[pezetko]

There is * In Candidate Objects Parameter on the Mantra ROP by default that will add every object with visibility flag on into the ifd (if it's not explicitly excluded by Exclude Objects Parameter).

You can debug what is in the IFD file by turning off Save Binary Geometry and displaying content of the ifd in text editor.

 

Be sure you are not including objects you don't want to render by explicitly setting rendered objects using Force Object Parameter and keep Candidate Objects Parameter empty.

Same workflow could be used for lights.

 

For smaller ifd use Delay Loading (Alembic/Packed Primitives loaded from the disk or Delayed Load shader) - it's explained more in depth in the help documentation.

[mupapabear]

Hey, I removed the candidate Parameter and forced the geo node. But even with a delayed load shader the size of the ifd files doesn´t change. Il´look into the alembic delayed load worklfow, thanks for the hint. 

[fathom]

okay, so looking at your file, you have a geo light using the "import_pyro_build" object to emit from.  that'll force it to include into your ifd as well.  change that to the "render_pyro" object.

[mupapabear]

thank you very much, that did the trick

. Now I am a bit angry for overlooking that, a real "head meets table" moment...

[fathom]

you should verify that you volume light is still being applied.  it looks like you can't use delayloaded geo with volume lights, for some reason.  seems to want to use the SOP geo only.  of course, you could probably preprocess it to reduce rez for a volume light, but it seems kind of bogus.