Demystify the Particle Distance Traveled attribute?

Technical & Engine Help Unreal Engine Help
#1

Hi, first time poster here:

I just realize Niagara’s particle.distancetraveled attribute isn’t at all what I expect: I expect it to be a sum of total position change, but it runs consistently lower than even the raw distance offset length from initial position.

Here is a screenshot of their comparison in spreadsheet:

Screenshot 2023-01-05 113402
Screenshot 2023-01-05 113402976×574 41.9 KB

It is accumulating something, the value is consistent across CPU Sim and GPU Sim, at 24 fps or 240 fps; but what is it accumulating? I have no idea.

If you do some calculation, their value appears to converge towards distance offset / 10 * 3, can anyone offer an explanation to this?

#2

I thought it was sum of velocity*invDeltaTime but I’m not sure

#3

I was trying to kill particles based on total distance traveled, any idea on what to use?

#4

They use this for spawn per unit and ribbons, so I think it should be stable enough to animate or kill based on as well.

#5

image
image1369×610 102 KB

I think this is it, sum of total Velocity*DeltaTime (my gut said invDeltaTime, but I was wrong).
This then gets copied down into on spawn into things like ribbon uv to get the traintrack tiling to work.

It just occurred to me that you’re probably trying to kill based on distance the particle traveled rather than the distance the emitter traveled. Which might be why this isn’t doing what you want.

#6

Can you elaborate? Because I do want to kill each particle based on how much it traveled, why is that intuition wrong?

#7

Because the distance traveled parameter is for the distance the emitter (entire effect) traveled, not how far that individual particle traveled.

#8

Oh, nope scratch that, I thought you were referring to Emitter.DistanceTraveled

Particles.DistanceTraveled is the sum of Length(Position-PreviousPosition) * (.333)
It says it’s multiplying by .333 for legacy scale support

image
image1337×602 115 KB

#9

Just multiply by 3 when using it in your module and you’ll be good to use unreal units for comparison.

image
image1028×309 18.2 KB

#10

If you look at my OP, the Math is closer to d * 10 / 3, I know the math but was wondering about the reasoning behind this math. :grinning:

#11

Thx for showing this, where can I find it by the way?

#12

Oh, it’s in solve forces and velocity

#13

Which version are you taking the screenshot from?

Interestingly, in Unreal 4.27.2 at least, it doesn’t do the .3333 multiply directly, but instead use invDeltaTime:

Screenshot 2023-01-05 134734
Screenshot 2023-01-05 1347341130×393 85.6 KB

Why does it give the same result as multiplying by .3333?

Seems to be some confusing unit conversion going on…

#14

Oh…
Someone must have forgot that they wanted per frame instead of per second data so they accidentally multiplied by invDeltaTime.
Then when testing divided by 100 cause those values ended up larger then they though.

When changing to UE5 perhaps they tried fixing it, but didn’t want to completely break existing data. By dividing by 3 after removing invDeltatime and divide by 100, you get the same result as long as you’re running at 30 fps. so close enough…

tldr.
You’re getting weird values because you’re getting the per second movement divided by 100 but adding it every frame… :unamused:
(You’re not doing this, it’s epic)

3 Likes
#15

I think this might be the reason! perhaps niagara is designed to have 30 fps games in mind haha

So a legacy bug in the end, glad we both ran through it to see the truth, it was my goal anyway :slight_smile:

#16

Yeah, mine looked weird because they were supporting a legacy bug.
You’re looks weird because you’re working in the engine version with that legacy bug.