Bug Moving Rigidbodies anf VFX particle spawns

I am generating particles according to the position of quickly moving rigid-bodies (things like exhaust particles on rockets, or dust particles from tires).

But there's a problem: since the VFX graph "updates" asynchronously (or possibly something deeper), the position that it is spawning the particle in are inconsistent in cases where early or late frames occur. EG:

https://imgur.com/7kS2lgb

As far as i understand, there's just nothing I can do about this because how the graphs handle positions are all internal engine code. Is there any way to overcome this issue? I have tried all the basic stuff like using world/local positions for generating particles (including having the graph be stationary or itself moving with the player). The only case where particles will spawn perfectly is when using a local-space simulated graph, feeding local spawn coordinates, and allowing the graph to itself follow the player (which is not acceptable because i need the particles to behave in world-space)

Any help or insight into this would be greatly appreciated

 

The space ship probably just moves too fast, but it feels like the system was running out of capacity.
Just to be clear, are we talking about spaces between each spawned particles? I mean faster it moves the larger space between particles? or random "bursts" of particles? or something else?

 

No not talking about the spaces; if you look closely, eventually you will see hiccups where particles get spawned in what appears to be next-frames (or last frames) position. Here's another one that has some unrelated jiggle, but also shows the issue occasionally.

https://imgur.com/9J0PYOW

It can be a bit difficult to see what's happening /w the particles at a glance because they're going so fast (at this setting it looks as if particles are static because they're being replaced by the next moving particle.

It can seem like all the particles are being moved suddenly when the glitch occurs, but it's just a single particle spawned wrongly that then travels away at fast speeds (and also creates a gap where the particle should have been)

 

I see the problem, but I am not sure what causes this. I mean this is probably caused by the fact that some frames might have more than one physics update or none, but still I am not sure at what point it happens.
VFX does not update in any magic asynchronous way.

First of all check graph asset settings, you can set what kind of update you want - this might actually solve the problem.
Another candidate you are using probably spawn over distance or time in Spawn context. I am not sure, but possibly this is might be the cause of the problem (somehow?), try constant spawner and see if the problem persists.
Or distribution of particles along the line. If update options does not help, try to locate what exactly causes the problem. Also you might find useful one of these links:
https://forum.unity.com/threads/how...ystem-spawning-behavior.1166027/#post-7476496
https://forum.unity.com/threads/spawn-over-distance-is-causing-gc-spikes.1104196/

 

I managed to find a fix for this, (described at end for anyone interested), but still responding here for clarity

These were recorded with manual physics simulation stepping (to force one physics tick per update/render frame, which is a measure done to ensure smooth frames in a physics-VR context ). Just to clarify a bit, the spacing of the particles is not the issue, it's the anomalous incorrect spawning of a given particle's position that occurs on an early or late frame. I'm just spawning one exhaust particle at the given position, velocity, etc, each frame, using custom attributes and one shot VFX events that are passed to the graph. The issue also exists in automatic physics simulation mode as opposed to manual stepping, with different spawn contexts (eg: a dedicated continuous emitter local to the rigidbody), and whether FixedDelta, Exact Delta or any other setting is used. Stepping the graph itself manually with AdvanceByOneFrame() also doesn't fix the problem.

I am very confident that the VFX graph maintains it's own update loop somehow, but I cant find where, or how it hooks into the player loop.

I tried every setting and configuration imaginable, and then some hehe...

Not using spawn-over-distance or anything (although I should to address the sparsity of them at high speeds), but I did try constant spawners: they have the same issue. The only way I could eliminate the issue (but break the effect i needed) was using a constant spawner on a local graph, with local spawn coordinates, while it was a child of the rigidbody in question. As I needed worldspace simulation it was a no-go.


THE SOLUTION:
I cant explain why this works, but I'm 100% sure it does: The key is to manually step the VFX graph using Simulate(fixedDeltaTime) instead of AdvanceByOneFrame(). Simulate is supposed to be used for fast-forwarding the graph (it has an optional step count command that defaults to 1), but for whatever reason, using Simulate() to manually step works where AdvanceByOneFrame() does not (AdvanceByOneFrame() is the intended function for manual stepping). To learn more I would need to crack open the files that contain these functions (both of which are external to the core library ('extern'))...

At first when i tried manual stepping to solve the issue I was using AdvanceByOneFrame(). I got lucky by through the docs and seeing the Simulate() command used for fast forwarding, and in desperation gave it a shot.

 

If I understood correctly you use customized game update. I am not sure how exactly your stuff is implemented, but AdvanceByOneFrame uses current frame delta time, while Simulate allows you to progress system sim with your own delta and any number of times, what kind of make sense why it worked.

I am just curious, does your system introduce irregular unstable physics step or it just allows only single update at once, so your whole simulation slows down when fps drops?

 

I expected AdvanceByOneFrame() to respect the DeltaTime settings of the graph, but if that's the only difference between the funcs then yea, would be the root of the problem.

Allowing irregular physics steps to match deltaTime is possible, but I decided to just hard-code the delta to keep things more deterministic (especially for my physics based ml-agents). It does cause the simulation to slow down when frame rate drops, but this much smaller of a problem than random and unpreventable frame timing problems caused by not using Simualte().

 

Int this video you provided can I know how you made it curved when turning I am trying to do similar things but with car drift smoke but vfx smoke just goes in a straight line and also it randomly acccelerates when car mokes fast.