Is there a way to write .ifd's that, when rendered, will create images for multiple /out nodes in one mantra invocation?

We have some scenes that generate fairly expensive intermediate geometry. For each animation frame, we need to create multiple several /out images that depend on those same intermediates.

Ideally we'd invoke mantra once per frame, and feed it an .ifd that tells it to make the intermediate stuff internally and render all the associated outputs.

But we've been generating .ifd files by setting up an /out node to create ifd's and then invoking ropnode.render(). It creates a self-contained ifd which renders just that frame.

Can we make a single ROP node (merge??) that depends on several other ROPs, such that <overall_rop>.render() creates a single .ifd that does the whole job?

Or: is there a safe text-processing way to merge multiple, separately-created .ifd files into a single one that creates the multiple related images? I might be able to parse the generated .ifd's well enough, but would prefer a less hack-y way.

I tried tying multiple ifd-output nodes as input to a Merge ROP. Rendering that Merge ROP just triggers each of the dependent ROPs to write its own, separate ifd file.

stuartnlevy
I tried tying multiple ifd-output nodes as input to a Merge ROP. Rendering that Merge ROP just triggers each of the dependent ROPs to write its own, separate ifd file.

Yeah, that's what that does. Merge is flow-control of the render nodes.

There's no way to use one ifd for multiple renders, except for the stereo camera hack. You can render multiple views from the same ifd, but they will be rendered one-by-one in the same process–I'm not sure if it's possible to specify which view to render.

Why don't you save the ‘heavy’ geometry to disk and read it back as a packed disk primitive or use a delayed load procedural. There's rarely any reason to save large geometry caches to ifd files anymore. They should only consist of materials, camera, image planes/render settings and references to geometry on disk.

Hmm, thanks. In our case, the ifd's themselves are small - we do already use packed primitives for large static geometry. The costly intermediates are surfaces with procedural displacement, constructed on the fly in a shader derived from on-disk texture images.


On a lark, I tried gluing two separate .ifd's together with a text editor:

the header of one of them,
then all the “Retained geometry” entries from both files,
then the “Main” section from one of them down to the ray_raytrace,
then the “Main” from the other one,
and another ray_raytrace.

Result: No error reports. It created both images, and they were different! The first of them might have been correct… the second was clearly wrong. So at least some settings from the first image were being inherited by the second when I didn't want them to be.

The .ifd file format description has some discussion of scope of settings, so maybe the undesired inheritance could be fixed, but I'm kinda shooting in the dark.