Export AOV to custom planes, from instances

[JoshJ]

I am instancing branches of flowers onto a tree. I have all the shaders and everything working with no problem, but I can't seem to export AOV's from the instances into custom planes. The actual geometry in the scene can export to custom planes, and when I test the flower branch itself (uninstanced), it can export the AOV.

Has anyone successfully done this? If so I can check my file to see if there's anything I'm doing wrong... Just wanted to make sure this is supposed to work.

[Mario Marengo]

I am instancing branches of flowers onto a tree. I have all the shaders and everything working with no problem, but I can't seem to export AOV's from the instances into custom planes. The actual geometry in the scene can export to custom planes, and when I test the flower branch itself (uninstanced), it can export the AOV.

I noticed this went unanswered, so I did a quick test and it seems to be working fine.

Any chance you can post a simple scene file to show the problem?

[JoshJ]

Hi Mario,

Here is an attached test. There are two renderers set up here. While making this simple sample file, I discovered what may be part of the problem. I guess you could call it "Lazy Evaluation". While the petals shader is being called by an object actually in the scene, the procedural correctly uses the shader. When the delayed load procedural is the only thing that calls the petal shader, then it seems to fail to evaluate or send info to the extra planes.

In the two renderers, take a look at the color plane, petalcolor plane, and also the normal plane, where the "petal"objects aren't evaluating the same way. Then take a look at the candidate objects, this is the only difference between the two renderers.

instance_test.zip

[Mario Marengo]

Sorry, I'm rushing outta here, so not much time, but I made some changes and rendered... and it seems OK.

Just render the "Mario" rop when you open it, and you'll see the AOVs: petalColor, tree, and N.

Look at the single_flower object and the instance object (not a normal object) to see what I've done. Oh, also changed the delayed load shader a bit. Anyway; gotta run. Hope this helps.

instance_test2.tar.gz

Cheers.

[JoshJ]

Thanks for the file, it does work in your example. Perhaps I simplified my file a bit too much though, in my actual setup I'm copy stamping the file override in the material name, choosing from six different geometry sequences (being driven by an attribute transferred to it, etc etc) . So I won't be able to hard code the instance object name at the object level.

If necessary, I can remake another more complicated setup that more closely resembles the production situation.

[Mario Marengo]

If necessary, I can remake another more complicated setup that more closely resembles the production situation.

That's probably a good idea.

Here's an example which varies the base geometry (among 4 bgeo files), scale, orientation, and shading parameters of each delay-load instance (the leaves), and outputs the expected AOVs.

delayloadaov.tar.gz

I think the problem is that you're trying to set materials at the primitive level, yet instancing, AFAIK, works at the object level. Unless I'm mistaken, you won't be able to override material parameters once they're baked into the bgeo files as primitive shaders (as opposed to object shaders, which is what instancing works with). But maybe I'm missing something.

Cheers.

[JoshJ]

Hi Mario,

Thanks so much for the latest example file, the problem was exactly as you mentioned. I didn't realize that instancing was so "object based", and I was trying to override the material in the sop level, which worked to a certain extent, but didn't quite hook everything up properly for the renderer. Thanks again!

Edited October 28, 2008 by joshjordan

[Mario Marengo]

Great! Glad it helped.

Cheers.