Game Development Community

Particle stream jumping back and forth

by Gary Preston · in Torque Game Engine · 07/29/2005 (9:31 am) · 5 replies

When the player fires a projectile the camera tracks it, with the projectile emitting a stream of particles. However the stream seems to be emitting in front of the projectile rather than on it or behind. Also it skips between way ahead of the projectile, slightly ahead and touching the front of the projectile.

I thought it might be something to do with the model we're using for the projectile, so I reverted back to the original orc crossbow bolt projectile. I see the same problem with the emission jumping forwards and backwards. Also the particle is offset above the projectile (although this only occurs with the crossbow bolt model)

The following three images are of a fairly slow projectile in flight, the location the particle stream is emitting from continually jumps between 3 or more positions. Which follows the location of the light blue box.

www.mups.co.uk/downloads/tmp/screenshot_1.jpg
www.mups.co.uk/downloads/tmp/screenshot_2.jpg
www.mups.co.uk/downloads/tmp/screenshot_3.jpg

Anyone know why this may be occuring?

#1
07/29/2005 (2:25 pm)
As I recall it works like this:

A Projectile's particles are emitted on the tick. They are emitted along a line from the previous tick position to the new tick position. This is not interpolated, rather the entire line is created at once.

The Projectile's shape, on the other hand, is drawn at the Projectile's render position (set in interpolateTick), which is interpolated from the previous position, to the new position. As a result, the shape is constantly playing "catch up" with the current tick position.

So, on the tick, particles are emitted up to the new position, while the shape is being drawn at the previous tick position. By the time the shape reaches the current tick position, it's time for another tick. The current position becomes the old position, and the particles are drawn ahead to the new position.

The simplest solution would be to add an ejectionOffset parameter to your ParticleEmitterData. This will offset the particles along the emitter axis, which in this case is directly opposite the Projectile velocity. The particles will still be somewhat jumpy, as they are only added on tick, but you can move them behind the projectile where they should be, and where the jumping should be less noticeable.

...

If the jumping still bothers you, you might consider changing the Projectile class to emit particles in advanceTime instead of processTick. This is also relatively easy to do:

In game/projectile.cc, comment or delete line 866 in processTick:

[b]//[/b]emitParticles(mCurrPosition, newPosition, mCurrVelocity, TickMs);

then add to advanceTime the following (bold) lines:

around line 392:

Projectile::Projectile()
{
   // Todo: ScopeAlways?
   mNetFlags.set(Ghostable);
   [i]...yadda yadda...[/i]
   mFadeValue        = 1.0;
   
   [b]mLastRenderPos.set(0,0,0);[/b]
}

and around line 907:

void Projectile::advanceTime(F32 dt)
{
   Parent::advanceTime(dt);

   if (mHidden == true || dt == 0.0)
      return;

   if (mActivateThread && 
      [i]... yadda yadda...[/i]
   }
   
   [b]Point3F renderPos;
   mRenderObjToWorld.getColumn(3, &renderPos);
   if (mLastRenderPos.isZero()) mLastRenderPos = renderPos;
   emitParticles(mLastRenderPos, renderPos, mCurrVelocity, U32(dt * 1000));
   mLastRenderPos = renderPos;[/b]
   
}

Also, add to the Projectile class in game/projectile.h (I suggest around line 158):

// Rendering related variables
   TSShapeInstance* mProjectileShape;
   TSThread*        mActivateThread;
   TSThread*        mMaintainThread;
   
   [b]Point3F mLastRenderPos;[/b]

The particles should appear smoother now. However, this will require more processing time. How much of a performance hit this will incur depends on many factors, including the number of projectiles in the scene and (obviously) the speed of your computer. I rather doubt you'll notice much of a performance penalty on modern hardware, but it is something you may want to consider.
#2
07/30/2005 (5:01 am)
Thanks for the explanation Scott, I'll have another look into this on Monday morning.

Edit: For anyone else that might have the same problem, the above suggestion works well. Thanks for the pointer.
#3
08/24/2005 (10:53 am)
Things look sooo much better with this fix. It should be a resource for sure.
#5
06/26/2007 (5:18 am)
For some reason this does not help with TGEA...