Thanks for the tip on normalizesafe. It will be battle-tested and smashed to pieces!
I removed the custom writes to userdata during the userdata job, which was sad because the blending did a fantastic job of smoothing out spazzy data. But yes that mid-job writing certainly seems unsafe. I want to keep it in BurstDensity because it's a great spot to handle all positions and userdata deltas, plus I'm scared of learning more about batchData and Constraints.
With some hacky help from Copilot, it seems about 90% there. Debug Vectors looks good - Possible to pause and cherrypick bad-direction lines, but oh well.
Obi userDirection vectors - YouTube
But Debug Colors are still SO FLASHY and random. Ideally, the per-particle colors look similar for CenterMass and InputDirection, since idle Input writes userdata near Center Mass.
The good news is that moving around does show that colors are affected by direction of movement.
(Flashing Colors) Obi userDirection colors - YouTube
The hack solution involves checking a Dot Product on previous directions, then perhaps flipping the Direction*Data we are trying to add.
It seems like early interactions my bias later dot products, but I'm not sure.
But anyways - it's ok that 10% of directions are wrong, if I just increase particle input force by another 20%
Attached are the Obi job and hacky helper, plus another job that Inverts a mysterious -1 bias. It also allows filtering InputDirections based on how many particles they interacted with, how much Input userdata is there, etc. In the job to add particle forces, I normalize the InputDirection.
Attachments:
I removed the custom writes to userdata during the userdata job, which was sad because the blending did a fantastic job of smoothing out spazzy data. But yes that mid-job writing certainly seems unsafe. I want to keep it in BurstDensity because it's a great spot to handle all positions and userdata deltas, plus I'm scared of learning more about batchData and Constraints.
With some hacky help from Copilot, it seems about 90% there. Debug Vectors looks good - Possible to pause and cherrypick bad-direction lines, but oh well.
Obi userDirection vectors - YouTube
But Debug Colors are still SO FLASHY and random. Ideally, the per-particle colors look similar for CenterMass and InputDirection, since idle Input writes userdata near Center Mass.
The good news is that moving around does show that colors are affected by direction of movement.
(Flashing Colors) Obi userDirection colors - YouTube
The hack solution involves checking a Dot Product on previous directions, then perhaps flipping the Direction*Data we are trying to add.
It seems like early interactions my bias later dot products, but I'm not sure.
Code:
// Each particle tracks direction of increasing userdata
// This is used to calculate the direction of the player input
// Note: Directions seem to be NEGATIVE. But, Custom +A -B matches Obi +A -B. and changing the Dot product to be negative breaks it
// so do *= -1 elsewhere on inputDirection
void AddDirectionDiff(int solverIndex, float3 diffA2B)
{
// Track interaction count, so that when using Direction, we can ignore particles with few interactions
float numInteractions = userDirection[solverIndex].w + 1;
float3 particleDirection = userDirection[solverIndex].xyz;
// Check if the differentialA2B points towards the higher data
// Dot HACK-iness - Who knows what direction the first AB pair is?
if (Vector3.Dot(diffA2B, particleDirection) < 0)
diffA2B = -diffA2B; // Reverse if necessary
// direction[index] += delta
userDirection[solverIndex] = new float4(particleDirection + diffA2B, numInteractions);
}But anyways - it's ok that 10% of directions are wrong, if I just increase particle input force by another 20%
Attached are the Obi job and hacky helper, plus another job that Inverts a mysterious -1 bias. It also allows filtering InputDirections based on how many particles they interacted with, how much Input userdata is there, etc. In the job to add particle forces, I normalize the InputDirection.
Attachments: