Heya folks,
Doing some cloud tests on a new show and I'm using a library of houdini vdb files. We're doing a falling from space type of shot so I'm looking at the scripting of volume grid creation. Doing a simple maxscript creation of a grid and setting it's rendinput parameter to a file path of a vdb doesn't load a preview or set the grid to the dimensions of it's input so I'm wondering what's the process of getting it to update? On a manual load we get a prompt to ask us how to set values depending on where the vdb file came from which I'm sure is playing a big part. If I have a manually created grid I can swap the rendinput property and it'll update fine but if I wanted to load in a few hundred caches it'd be great to script it.
On a second note, we're testing this against another app which is very low in overheads for vdbs but not as nice looking but it'd require a second pass. Due to the amount visible in the shot I'd say we'll have some large memory overheads and we'll potentially be going from far away to close up - any hints besides things like step size that could keep the overheads down with thousands of vdbs?
Cheers!
John
Doing some cloud tests on a new show and I'm using a library of houdini vdb files. We're doing a falling from space type of shot so I'm looking at the scripting of volume grid creation. Doing a simple maxscript creation of a grid and setting it's rendinput parameter to a file path of a vdb doesn't load a preview or set the grid to the dimensions of it's input so I'm wondering what's the process of getting it to update? On a manual load we get a prompt to ask us how to set values depending on where the vdb file came from which I'm sure is playing a big part. If I have a manually created grid I can swap the rendinput property and it'll update fine but if I wanted to load in a few hundred caches it'd be great to script it.
On a second note, we're testing this against another app which is very low in overheads for vdbs but not as nice looking but it'd require a second pass. Due to the amount visible in the shot I'd say we'll have some large memory overheads and we'll potentially be going from far away to close up - any hints besides things like step size that could keep the overheads down with thousands of vdbs?
Cheers!
John
Comment