Split Instance Into Subtypes

[progschj]

The main function of instance objects is to associate a group with a transform. However extensions in the specification (motion blur) specify alternative parameters to set the transform and change the behavior of the instance. This also creates a precedent that extensions for further transform types (skeletal animation, array instancing, etc.) would have to follow. The result is a "fat object" type whose behavior is governed by a precedence hierarchy of parameters with overlapping or even conflicting meaning.

Instances should be explicitly subtyped instead of having an implicit subtype based on parameter precedence. This would also be consistent with similar design decisions we made for geometries.

The changes to the spec would be:

ANARIInstance anariNewInstance(ANARIDevice device); changes to ANARIInstance anariNewInstance(ANARIDevice device, const char* type);

New instance subtypes are introduced:

• "matrix" the current default type repackaged in an extension KHR_INSTANCE_MATRIX
• "motionMatrix" encapsulating motion.transform in KHR_INSTANCE_MOTION_MATRIX (split from KHR_MOTION_BLUR_TRANSFORMATION_INSTANCE)
• "motionSRT" encapsulating motion.scale/rotation/translation in KHR_INSTANCE_MOTION_SRT (split from KHR_MOTION_BLUR_TRANSFORMATION_INSTANCE)

[johguenther]

What about cameras then? They share the orientation capabilities with instances (because we said that cameras should not explicitly be instanced). We consequently would have many more combinations there: perspective_matrix, perspective_matrixSRT, orthogonal_motionSRT, ...

Furthermore, at other places we also have the case that alternative parameters are allowed (and one parameter takes precedence over others):

• per-vertex attributes have precedence over per-primitive attributes
• brightness of light sources can be set as power, radiance or intensity

[progschj]

I guess the difference to me is that the transform type is really the defining characteristic of the instance object. While we have parameters with precedence to figure out details of other objects they don't fundamentally change the nature of a light source or triangle mesh. At one point there was implicit switching between triangles and quads depending on vec3/vec4 which we abandoned in favor of separate triangle/quad geometries. I see this as an extension of that concept to the last holdout that are instances.

The same "primary characteristic" concept makes the cameras ok as is I think. The transform type doesn't change the primary characteristic of the camera object which makes parameters more sensible there. Also cameras are less affected by additional instance concepts like the mentioned skeletal animation or array instancing.

[jeffamstutz]

Furthermore, at other places we also have the case that alternative parameters are allowed (and one parameter takes precedence over others):

per-vertex attributes have precedence over per-primitive attributes

This is one we cannot split out because a single geometry can mix per-vertex and per-primitive attributes. It is very much the hard exceptional case.

[johguenther]

From discussion one more idea:

• introduce Transform object (and remove the Instance)
• add it to Cameras and Groups

[progschj]

I tried to prototype hypothetical array instance and skeletal transform extensions as a discussion aid here: https://gist.github.com/progschj/e658ffb22439a444864a9109ff4d372c

[progschj]

About the transform objects. I think they are an interesting thought experiment at least. Lets say there was such a thing then the instance being a tuple of (group, transform) would make sense for similar reason that the surface (geometry, material) tuple makes sense. They are basically container objects connecting other objects that contain "actual state".

If that split existed transform objects being subtyped would be a very natural thing to do. However having an entire object type that most of the time just wraps a single MAT4 seems a bit over the top. Which is why merging the transform into the instance makes sense. Interestingly that is also what justifies the group object since you do want to use the same transform with multiple things.

Of course a big upside of the current design is that with the MAT4 transform parameter always being present there is a clean fallback. A hybrid solution could be to have instance have both a "matrix" and a "transform" parameter where transform objects are only used for nontrivial subtyped transforms while the most common case and fallback are still served by the plain matrix.

[jeffamstutz]

Summary from 12/7/22 WG meeting:

• Transforms as an object type seems to be too heavyweight for their purpose
• Most important things to keep consistent between instances and cameras are the parameter definitions + behavior
• Biggest tradeoff between subtyped and monolithic instances are parameter fall backs vs. clarity of intent
• Cameras + instances don't need to pre-multiply instance transforms with a base transform: applications should do this if it matters to them
• Cameras only really need motion blur parameters, the idea of a pre-multiplied base transform isn't beneficial enough for the reduction in clarity of use
• Instance subtyping would/should have a base transform parameter that is always the fallback to be used if the instance subtype isn't known or doesn't have its extra parameters set
• Instance subtyping isn't an issue between devices because handles aren't shared between them, thus they will have unique ANARI handle hierarchies
• Instance subtyping seems to be in a favorable state, will confirm this in next week's meeting to make sure we didnt' miss anything

[jeffamstutz]

Additional items from 12/14/22:

• Multi-level instancing needs to be accounted for (in a future extension, but should be doable)
• USD point instancer as inspiration for a subtype