Setting variables for Group nodes


Could you please add the possibility to set variables for Group and GeometryGroup nodes?
Currently, this is not possible, but would be a great enhancement.

Suppose I have the following scene graph:

Several GeometryInstances, which belong together are grouped.
I want to set a variable (e.g. an ID) for each Group so I can distinguish between them.

Currently, I have to set this variable for each GeometryInstance.

It would be great if Group nodes (and GeometryGroup nodes) could carry variables to avoid redundancy.

If Scene Object 1 and 2 are separate objects, putting the ID on the GeometryInstance or the attached Material would be the correct and working approach. Variables at group level would only be more convenient while adding cost.

But if Scene Object 1 and 2 are the exact same sub-tree and the Transform 1 and 2 are there for real instancing, an ID on any node inside the dashed lines of the Scene Object won’t help to distinguish them.

The required solution for instancing would need to be able to identify specific Transforms which would also help in your case. There exists a request for enhancement I’ve filed to add support for that

Thanks for your reply.

SceneObject 1 and 2 are not necessarily the same subtree, but they can be.
I need to access the ID e.g. in the closest hit program associated with the underlying geometry and then store it in the ray’s payload.

If I could set that ID variable in the Transform node and its subnodes would inherit that variable, so the value is avalaible in the hit/intersection programs, it would also solve my issue.

Is that what you meant?

Right, something like user defined variables at Transform nodes or some deterministic instance ID mechanism would be helpful.

It might take some time to find the best solution. It won’t be in the upcoming version. This affects variable scoping which is at specific hierarchy levels today.

If you need to uniquely identify the grouped GeometryInstances with a user defined value the way you described, you can’t use instances today.

If you really need to use instances and transforms are always different, a possible workaround would be to identify the GeometryInstance’s transformation, but that’s obviously more involved than a simple ID.

Hm, I am not sure I understood you.

I currently use instances just like I depicted in the images above.
A SceneObject consists of multiple geometries. Each SceneObject might occur multiple times in the scene, so whenever I create an “instance” of a SceneObject, I create the subtree (Group->GeometryGroup->GeometryInstance …) and attach it to the root node using a Transform node, which implements the movement of that SceneObject-“instance”.
In order to find out which SceneObject-“instance” was hit by a ray, I set the ID (1,2, …) variable for every GeometryInstance which belongs to it.

So transforms are always different, SceneObjects are “instantiated” using instances of its multiple underlying geometries and I can identify which SceneObject-“instance” was hit.
The only issue is that I need to set this ID variable multiple times.

It would also be interesting to be able to instantiate whole subtrees. How about that?

What you do is creating a new sub-tree per Transform and that is required if you want to attach individual variables to GeometryInstance or Materials. This is just a big expanded scene.
You might have reused the Geometry nodes, but the acceleration structure is at GeometryGroup level and will be created for each of the Geometries.

That’s not “instancing” in the sense of reusing the whole (identical) sub-tree.
If you only create the Group->GeometryGroup->GeometryInstance(+Material)->Geometry exactly once (for each different sub-tree) and then attach that one top level Group to individual Transform nodes which place that in the world, that would be real instancing.

Simple car example: A wheel group is built of rim and tire. You need four identical wheels. Create the wheel sub-tree once. Put the wheel group under four Transforms which place them on your car.
In your picture, if SceneObejct 1 and 2 are the same, remove SceneObject 2 and let Transform 2 point to Group 1.

That scene would be a lot smaller if the sub-tree is reused often. There would also only be the acceleration structures for the sub-tree once.
BUT(!) that is exactly the case where you can’t identify individual GeometryInstances with variables anymore, because there is only that one sub-tree and Transforms do not hold variables, other than their transform matrix, and that is why I filed that request for enhancement.

You could put yourself into trouble and try to identify the transforms as a workaround, but that would be clumsy and slower than a simple ID. If your scene is not too huge, just keep using your method until there is a better solution.

I don’t know for what purpose you need the ID, maybe there are other ways to solve your requirements.

I try to reuse the acceleration structures wherever possible (across identical SceneObject-“instances”).

Ah, now I got it.
I did not think of a node’s possibility to have multiple parents, so this is how I could instantiate a whole subtree, if I could set a variable per Transform.

Thank you for the clarification.