It seems like it should be simple. Just put the geo in the scene graph like this: /cameras/myCamera/myGeo. When I do that, the camera's primitive type becomes "Xform" instead of "camera", and it no longer functions as a camera.

Thanks,

Brad T.

To answer my own question, building the geo in it's own layer, then using a "graft" node to attach the sublayer to the camera works. The more I work in solaris/USD, the less patient I become with all it's fiddly landmines and inefficiencies.

BradThompson
To answer my own question, building the geo in it's own layer, then using a "graft" node to attach the sublayer to the camera works. The more I work in solaris/USD, the less patient I become with all it's fiddly landmines and inefficiencies.

The sopcreate is creating Xform prims for all the ancestors of the imported geo. Creating them after the camera is created means it has a stronger opinion. It's like in sops if you perform an operation after the previous one, the later operation has precedence. Creating the camera after the sopcreate or using a sublayer with sopcreate set to 'weakest position' results in the camera taking precedence over the sopcreate.

Alternatively, when the sopcreate is set to "load as reference" the parent primitive type can be left as 'None' so that it won't change the ancestor primitive types.

Perhaps there needs to be a feature added to Sopcreate in sublayer mode so that it can also optionally leave ancestor primitive types unchanged.

SOP Import/Create have a "Define Only Leaf Primitives" toggle, which will only create Gprims with overs on all of the ancestor prims. Alternatively there is an "Other Primitives" toggle to control things as well.

https://www.sidefx.com/docs/houdini/nodes/lop/sopimport.html#prim_def [www.sidefx.com]

Thanks. Jsmack, your explanation of WHY this happens is great. I have to wonder though, is there any scenario where this is a desirable default behavior? Why would I ever want children to change the primitive type of the parents?

BradThompson
Why would I ever want children to change the primitive type of the parents?

There is no child-parent relationship in USD used for composition. Composition rules are always at same level. It may seem illogical from the perspective of this limited example, but stronger layers should always be able to override weaker layers. If the sop create didn't define the type of the parent primitives, then you would end up with undefined parents and the mesh created by the sop layer would not be visible. In cases where you know the parent primitives already exist, then overs can be used rather than defines and the type can be left undefined for the ancestors.

I'm definitely still trying to wrap my head around Solaris, so I appreciate your replies. I just re-read the USD Basics section in the side-fx docs. It makes sense to me that if a prim exists in the scene graph, that a stronger opinion can be authored, changing that primitive. What's confusing me is that, in this case, the prim doesn't exist in the scene graph yet. I'm creating something new and inserting it into the graph below a preexisting prim. Other operations seem to respect the hierarchical structure of the scene graph. If I apply a transform to a prim, it's decedents pick up that transform too, but it's ancestors do not. Why is it different in this case?

Maybe my misunderstanding comes from the "primitive" parameter on lop nodes. I'm assuming that if the path I enter points to a valid prim in the scene graph, I'm editing/overriding some aspect of that prim. Otherwise, I'm adding a new prim. Maybe that's a bad assumption?

BradThompson
Maybe my misunderstanding comes from the "primitive" parameter on lop nodes. I'm assuming that if the path I enter points to a valid prim in the scene graph, I'm editing/overriding some aspect of that prim. Otherwise, I'm adding a new prim. Maybe that's a bad assumption?

Every 'folder' in that path is a primitive. The node could be affecting just the last one, but often it affects all of them. In the case of a 'create' node, they have to create all of them otherwise the leaf primitive would be the children of primitives that don't exist. An edit node usually only affects the last node. The sopcreate node has an option to only create the leaf nodes, with the rest being overlays. However in that mode, if any primitive in the path doesn't exist, then the mesh will be invisible/not resolve.

BradThompson
I'm creating something new and inserting it into the graph below a preexisting prim.

That's what you were wanting to do but not what was actually happening. As the node was configured, it was changing the type of the parent prims as well, taking out the camera along the way. Enabling 'Define Only Leaf Primitives' gets you the parenting behavior.

That said, I think the current settings are a little tricky to use. For example when the incoming geometry name is a path - I tried sopcreating a sphere with name attribute "foo/bar" and then define only leaf primitives wasn't sufficient because while prim bar was defined, foo wasn't.

When defining prims, I wonder if it's necessary for sopcreate to override the type of prims with an existing type? I couldn't see a switch to disable the type authoring. Also, in the case of trying to override a camera as a transform, the camera already inherits from Xformable so I wonder if there could be some extra smarts that turned that into a no-op as well.