Hi;

I have a courtyard set with a variety of vegetation. I'm doing copy-stamping of the Labs TreeGen trees, and varying the seed of each tree to get some variety per copy. This is cool! Except my display gets quite sluggish.

I can "pack geometry before copying" on the Copy stamp node, which gives me the option of viewing the packed geo as a bounding box. This is pretty nice...except I need to do some shader reassignment later down my workflow, which I think isn't possible with packed prim geo. I also realize that packing wholly-different geo doesn't actually buy me any efficiency from a memory standpoint...I'm simply doing this because I like the lighter weight viewport experience.

So I'm stuck at a place where I need to be able to modify the geo (specifically the shaders) downstream of the copy, but would love to lighten the burden on viewport drawing. Do I have any options?

dhemberg
So I'm stuck at a place where I need to be able to modify the geo (specifically the shaders) downstream of the copy, but would love to lighten the burden on viewport drawing. Do I have any options?

Use /Stage and you can modify the draw style of components or use proxy meshes for interactive display while still being able to see the hierarchy and assign materials.

Options in /obj land are limited. Like you said you can pack them, but then you can't assign materials directly anymore without resorting to the dead end stylesheets. You can set the draw mode of the object to bounding box, but that only really helps if each object is separate.

You can also pack them before copying, if you pack per material for example

Then after copying you can have box per each part of your vegetation that has different mat

Also if there are parts you can reuse among copies like leaves or some parts, you can get some instancing instead of having every single element of every single tree completely unique, all can potentially share just a handful of leaf variants with further variation done in the shader using attributes

The "draw mode" approach seems alluring, but I'm stubbing my toe a bit on trying to figure it out.

At the moment, I have some stuff in obj nodes, that I pull into Solaris using Scene Import. When I do this, I see in my Scene Graph Tree a hierarchy that looks like:



I append a ConfigurePrimitive Lop to the Scene Import node, and set Draw Mode to Bounding Box. But...nothing happens. I can toggle other settings like Visibility and such and see things disappear or see changes in the Scene Graph Tree, but I'm not sure what I need to do to get the Draw Mode option to work.

In order for draw modes to work, all ancestor primitives must have valid model kinds. The root prim 'geo' is kindless. Configure it as a 'group' to get the components under it support draw modes. Where is 'geo' coming from? Is that a subnet at obj level?

Hm; this response suggests maybe the default behavior isn't the best for those of us without intimate USD fluency. To answer your question: /geo is, well, a 'geometry' obj node I created at /obj, by hitting tab and typing "geo", hitting enter, and then working as I normally have the past 15 years or so. I wouldn't say I made any intentional decisions when bring it into Lops - I was just trying to bang around and figure out how to do it. Scene Import seemed like the least friction.

Not, of course, that I'm resistant to learning - that's why I'm here, to try to learn how to do this better. I'm realizing that the more-preferred move is likely making a SOPNET in Solaris, doing the exact same work there, then pulling into Lops similarly, maybe via a SOPCreate rather than Scene import.

But either way - it seems like the data I'm situating into Lops isn't quite structured as nicely as it could be, so figuring out what the nice way is is what I'm trying to understand.

dhemberg
Hm; this response suggests maybe the default behavior isn't the best for those of us without intimate USD fluency. To answer your question: /geo is, well, a 'geometry' obj node I created at /obj, by hitting tab and typing "geo", hitting enter, and then working as I normally have the past 15 years or so. I wouldn't say I made any intentional decisions when bring it into Lops - I was just trying to bang around and figure out how to do it. Scene Import seemed like the least friction.

Not, of course, that I'm resistant to learning - that's why I'm here, to try to learn how to do this better. I'm realizing that the more-preferred move is likely making a SOPNET in Solaris, doing the exact same work there, then pulling into Lops similarly, maybe via a SOPCreate rather than Scene import.

But either way - it seems like the data I'm situating into Lops isn't quite structured as nicely as it could be, so figuring out what the nice way is is what I'm trying to understand.

I don't believe you have. A geo node becomes a component model primitive, the one called 'render_gallery_int_KARMA'. Subnets become group Xform prims. The only way I see of getting that prim called 'geo' is to put /geo in the destination path of the scene import node. And yes, I think the default behavior should be for the destination primitive to have 'kind' set appropriately.

jsmack
The only way I see of getting that prim called 'geo' is to put /geo in the destination path of the scene import node.

Oh - yes, that's exactly what I've done. I set this mostly to mimic USD hierarchies we used at a studio I used to work at, so I suppose it was force of habit and a desire to try to keep my Scene Tree tidy (at least, "tidy" as I grew used to seeing it). I didn't realize that doing this also re-classified the incoming geometry.

You're right that my Geometry node in /Obj is named "render_gallery_int_KARMA" (so, /obj/render_gallery_int_KARMA). My Scene Import looks thusly:



Entirely possible I am doing something erroneous here.

For some reason, the ancestor primitives created for the destination path don't get a kind set. I'm submitting a bug.

Oh this is interesting; I thought I was asking a too-simple question but I'm getting to learn more than I bargained for, so thanks for taking the time with me here.

To try to follow what you're saying, I appended my Scene Import with a Configure Primitive LOP, and set /geo's "kind" to be "group". Now I see this:


I can indeed now set the Draw Mode on render_gallery_int_Karma to "Bounding Box", and it turns that entire group into one single box.

What I was hoping to do, however, is change all the, um, 'leaf' primitives (which is to say: "baseboard", "Ceiling", "decoration", etc. into bounding boxes. Or, at least, that's what I think I want (if this was a set of a forest, I would want to see each tree as a bounding box, rather than the entire forest as one big box). Is this possible? Or am I still misunderstanding how to set the hierarchy up here?