Hi,

I'm trying to get my head around instancing. What puzzles me is why a primitive loses its material binding when an instancer is created:

My scene is “/geo/sphere” and right after I create a material library with a red material and assign it to the sphere. Rendering shows the red material and in the scene graph tree I can see the material binding working.

Now, if I create an instancer node (doesn't matter which method is used), the /geo/sphere is copied underneath the prototypes prim of the instancer, as expected, however this prototype/geo/sphere primitive now lost the material binding and it has to be reassigned with another assign-material node - how come? And is there a way to avoid this?

The short answer is that USD data inside a “reference” composition arc cannot see outside the root of that reference.

So suppose you have /geo/sphere, which is assigned /materials/spheremat. The instancer LOP, to create the prototype prims, generally creates a reference to the original prim, and puts it under a “Prototypes” folder. So a new prim is created at /instancer/Prototypes/geo which is a reference to /geo. Now /instancer/Prototypes/geo/sphere will have a relationship on it saying that it has a material binding to “/materials/spheremat”. But you only referenced in /geo. /materials does not exist inside the referenced content, and USD can't look outside the reference. So the relatinoship pointing to /materials/spheremat can't find its target prim, so USD just eliminates that relationship, and you lose your material binding.

Now, if /geo/sphere was bound to a material at /geo/mats/spheremat, then the bound material would be _inside_ the reference (at /instancer/Prorotypes/geo/mats/spheremat). So the material assignment would still work. This is the basic solution to your problem. Make sure your bound material prim exists inside the branch of the scene graph that defines the prototype.

Alternatively, if the Instancer LOP were to make /instancer/Prototypes/geo _inherit_ from /geo instead of referencing, your existing setup actually would work, because USD can actually see primitives outside an inherit (or specialize) arc. There are additional implications to this change in composition, but I'm thinking it's probably worth adding this option to the Instancer LOP…

Thanks, this makes sense.

Putting the material underneath the prim that the referencer points to works, yes. However in my scene objects and materials are in separate branches of the tree. Is there then a procedural workflow where there are objects in /obj/xform/ABC and materials in /mat/XYZ. Object ABC has the material XYZ. I want to create instances of ABC, so for that to work I have to put them both underneath the same primitive. I can sort of create a “staging area”-prim if you will where ABC and XYZ are referenced - this is then instanced. Is there now a way - further down in the stream, not before the instancer, to modify /mat/XYZ and have the changes come to all the instances?

In other words, is it possible to have a material library at the root of the tree that all objects in the scene use and at the same time use instances in a way that a procedural workflow is kept. Meaning after the instancer I can modify a material in the material library and instances will be affected.

If you use the instancer in “second input” mode you can get behavior that is basically this. You can connect the same node to both the first and second inputs. This will cause the prototype prims to be _copied_ under the Prototypes folder, rather than creating references to the originals. Because they are copies (fully defined in the sublayer stack, not behind a reference), the material binding should continue to work.

Also, in tomorrow's build I did add the menu to the Instancer LOP that I mentioned, so you'll be able to choose that the Prototype prims be an inherit or specialize of the original prim, rather than a reference. If you use either of these new modes, you won't have to change anything else about your hip file. Inherit composition arcs are a little bit slower than references, but unless you are creating truly massive scenes, I don't think it's anything you need to worry about.

Thanks for all the info, it's a lot to chew through - composition arcs and what happens where exactly still confuse me.

Using the second input kinda works. It almost seems like Houdini is smart to copy all the necessary stuff needed under the prototype prim.

However, it still doesn't work (unless I'm overlooking something) to now modify the original material (in the material library /mat/XYZ) after the instancer. I now need to point the edit-material node to the copied material underneath prototype. Or I edit material XYZ before the instancer, but as all this will eventually be saved into a usd file which is then referenced somewhere else this won't work in the pipeline.