As the title suggests, I’m working on a blob tracking setup using instancing to render shapes at each detected blob position. Right now, I’m only rendering one shape type, but I’d like to render a mix of shapes (quarter circles, squares, and rectangles).
Here’s what I’m trying to achieve:
Each blob should be represented by one random shape from the set (quarter circle, square, rectangle).
The shapes should not overlap.
The variety should stay stable across frames. Shapes shouldn’t shuffle every frame unless blobs change.
Here’s what I’ve tried:
Create different SOP shapes, merge them with a Merge SOP and then reposition them with a Transform SOP so that they don’t overlap each other. This wasn’t the look I was going for; ideally each blob is a different shape, instead of having them positioned on top of eachother.
Create a different SOP network that each represent a different shape and put each shape into a seperate Geo COMP. Turn off ‘Delete Overlapping Blobs’. This didn’t work, as you can see in the screenshot below; it also stacks them on top of each other.
Is there an efficient way to assign a different shape to each blob and instance them accordingly?
Would using multiple Geo COMPs (one per shape) be the best approach, or is there a smarter way to do this with a Switch SOP or custom instancing logic?
Instancing has an Active parameter where a channel can be specified that indicates which instance will be created and which wont (if using CHOPs a value of 1 will mean an instance is created, a value of 0 no instance created). So with n different Geo COMPs, each for a separate shape, you now would need as many channels that indicate which sample in the channels would be creating a instance.
First you could use the Blob ID as a lookup index into a channel with random values that have the range of 0 to the number of shapes you want to show.
Next, use a Fan CHOP to create n channels with each sample now indicating if the input channel value matches the output channel index essentially returning the Active channel for you.
For something like this I like to break it down into 3 stages: 1) identify and track, 2) representation, and 3) collision avoidance.
You mention shape coherence over time. This is done in step 1: assuming you have a DAT table out of this step, each entry (row) should have an associated seed value. What you don’t want to do is use any point’s position in the list unless you can “deactivate” an entry so that the size of your list only grows, never shrinks.
In step 2 you take either the position in the list (if only ever growing) and use it as the seed for choosing the shape (if a random shape works for you). You can use a single SOP network, convert the DAT to a list of points, and copy/stamp the shape onto the point. Note that a plain copy will get a single shape and put it on all the points, whereas a stamp operation will cook the chain once for each point, whereupon you can make an expression that chooses the corresponding shape.
Onto step 3, collisions: this one’s harder. It can be done with an RBD simulation. But think about it: if you have two tracking points, and they have geometries that overlap, and you then say “well, geo 2 get out of the way”, then won’t it no longer be tracking correctly?
