Collision Events... sort of

I was looking at the NeighborBalls example in the Alpha3 package, and decided to modify it to generate audio visual pulses on collisions.

I really like this example since it’s implementation of collision logic using compute shaders is very minimal yet effective. Since most of my own GLSL work has been in the Vertex/Fragment shader space it’s a good playground for getting folk like me to start thinking in more compute shadery ways.

One minor pain point was getting my ‘Heat’ attribute into the instanced-spheres geo so that my GLSL MAT could use it to affect the emission strength of the material. I wound up resolving it by way of a custom instance attribute and then moving it through the MAT shader stages by way of TDInstanceCustomAttrib0(). While the custom instance attribute seems like an ok way of propagating Attributes from the POP chain into the instanced geo and shader, the need to then load the attribute into the vertex shader just to pass it on to the fragment stage is a little onerous.

When instancing geo using a POP, it would be awesome if there were a simplified interface for embedding attributes from the Instance POP in the instanced geo without having to sort them into vec4 groupings using Custom Attributes. Perhaps something along the lines of the “Input OP” section on the CompositeTOP’s parameter sheet. Alternatively they may just want to be made available by default and the programmer can elect to delete any Attributes they don’t want embedded.

It might also be neat to find a non-GLSL way to drive material properties like emission directly with attributes. Something similar to the “map” approach that lets you specify a map for a given material property, but with an attribute input instead. The most transparent way might be to have the map field accept dropped POPs and have the attribute wrangling widget (>>>>) so that the desired attribute to drive the property can be selected.

2 Likes

Thank you @flowb for the nice demo!

We could make it easier to expose attributes for instancing, but this would be more error prone. Exposed attributes names could be in conflict with internal shader variables. We would have to figure this out.

Drive material properties with POP attributes instead of maps could be really interesting! For POPs, we are starting to explore how we could drive parameters by attributes. This could also be extended for other operator classes.

It seems like one safe way would be to handle these the same way that declared attributes work in the GLSLMAT, by prepending identifiers to the names to avoid collisions… Ie: TDAttrib_attributeName(). There seems to be some emerging precedent for this with the way that ‘i’ is prepended to input Attributes in GLSL POPs.

The Custom Instance parameters on Geometry are generic and also work with SOPs and CHOPs. Perhaps having POP specific parameters would open the door for exposing functions with the attribute names.