Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Getting Direction of Increasing Userdata per-particle
#1
I'm trying to store Vector3 "directions" in Userdata to do per-particle pathfinding. This direction is calculated from userdata "Input", so together they fit into one Vec4. Custom code also allows multiple Vec4s per Particle.
I'm stuck and have debug vectors pointing in unexpected directions, and would like some advice before I go trying more things  Ángel
(PS: I may use Direction/Differential/etc to mean the same thing, pardon me)

In this video, userdata "Input" receives value of 1 at the particle nearest the Blue Cursor.
With target in the center, I expect all the Green Lines to point Inwards, and some sort of do but not quite....
At 0:10 I move the Cursor around in a Circle, and the expected radial symmetry is just not there...
Differential of Center Mass vs Input (Vectors) - YouTube

In this video I change between color debug for "Center of Mass" and "PlayerInputDifferential" (Particle colors are normalized vectors)
Note that: CenterMass has unique regions of Purple and Pink, and is very Stable.
But: PlayerInputDiff has Pink in both the Upper Left and Lower Right, and there's some Flickering.
Differential of Center Mass vs Input (Colors) - YouTube


Here's the important formula in the script below, where dataDelta is a float difference in Userdata PlayerInput between two particles.
It seems correct, but invovled guesswork and AI so who knows.
Code:
float4 oneDeltaA2B = dataDelta * distA2B / math.length(distA2B);

The custom multiple userdata per particle doesn't seem to be the problem, because all channels seem to dilute/diffuse fine.

Maybe the problem is having one Burst Job use the same userdata for two purposes at once: Regular Diffusion of "Direction" as Userdata AND +/- "Direction" based on another?

I've Tried:
- Considering the above dual-write, only diffuse one Vec4 per-particle and do not diffuse the Vec4 with this Direction in it. This resulted in all particles having Vector3.zero, with some randomish color near where Input userdata was being written. (However, may need to revisit this, because I errantly stopped "Input" channel from diffusing, so obviously "Direction" has no data to derive from elsewhere....)
- Instead of storing Vector3 in Userdata, create new Solver array Vector3[]. In debug color mode, they all seemed randomized (indexing error?). And where previously the +Y half of slime had some purple/blue shades, it seemed half of all directions were now missing. (I have no clue how batching works in Constraints, or why this change of indexing into Userdata Vector4[2*n] V.S. Solver Vector4[n] was off.)

(snip)

Modified UpdateDensitiesJob:
[Image: VszZAiQDHqpY.png?o=1]
Helpers
[Image: 6SSDgEfcwRCL.png?o=1]
[Image: uMLrqKG02hII.png?o=1]

PS: Automod makes pasting code very difficult. Maybe all the {} () [].
Pasting images directly in looks like it works, but Errors because the message is too long, and raw view shows raw data in there.
External image host works once I ctrl-click to copy image link instead of the link they gave me!
Reply


Messages In This Thread
Getting Direction of Increasing Userdata per-particle - by slimedev - 19-11-2023, 06:37 AM