# Demystify the Particle Distance Traveled attribute?

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:

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?

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

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

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.

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.

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

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

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

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

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.

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

Oh, it’s in solve forces and velocity

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:

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

Seems to be some confusing unit conversion going on…

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…
(You’re not doing this, it’s epic)

3 Likes

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

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.