Distance based Particle Reduction

For Trajectory Zone, we use particles for just about everything. Heck, I keep expecting to start making the terrain out of particles one o' these days ;-)

One of the major disadvantages I ran into when it comes to using particles so heavily is Torque really reacts badly to having too many particles up close and personal. That's a major issue, since the goal in Trajectory Zone is to bomb the heck outta your opponent with really big explosives!

I submitted a client-side reduction code earlier, but, that wasn't enough. Talking with someone over at the TEP forums, we were discussing strategies for particle reduction (he's planning on replacing the entire particle engine). I realized a bit o' the strategy we discussed would work for the existing engine.

--- updated: added "$pref"s to make it client side tweakable, and added performance enhancement, thanks to two posts below :-)

open /fps/client/prefs.cs, and add the following 4 lines:

$pref::particles::LoD1 = 64;
$pref::particles::LoD2 = 128;
$pref::particles::LoD3 = 256;
$pref::particles::LoD4 = 1024;

Those are the LoD ranges - anything that falls below the first number means no particles at this distance, minimal between LoD1 and LoD2, etc.

Here's what it does: 1) It give particles one more entry (all work is in particleEngine.cc):

struct Particle
{
   Point3F  pos;     // current instantaneous position
   Point3F  vel;     //   "         "         velocity
   Point3F  acc;     // Constant acceleration
   Point3F  orientDir;  // direction particle should go if using oriented particles
   [b]S32      LoD;     // used for LoD particle reduction for extreme closeup. [/b]

(When you see lines in bold, that's the part ya' need to add, of course).

2) When a particle is created, it is assigned a random number from 1 - 4. (in ParticleEmitter::addParticle)

F32 initialVel = mDataBlock->ejectionVelocity;
   initialVel    += (mDataBlock->velocityVariance * 2.0f * sgRandom.randF()) - mDataBlock->velocityVariance;
   [b]pNew->LoD = (S32)(sgRandom.randF(1, 4));[/b]
   pNew->pos = pos + (ejectionAxis * mDataBlock->ejectionOffset);
   pNew->vel = ejectionAxis * initialVel;
   pNew->orientDir = ejectionAxis;

3) Then, in ParticleEmitter::renderObject, we check for the distance from the camera, and start reducing appropriate particles:

[b]   bool showParticle;
   S32 levelLoD1 = Con::getIntVariable("$pref::particles::LoD1", 32000);
   S32 levelLoD2 = Con::getIntVariable("$pref::particles::LoD2", 32000);
   S32 levelLoD3 = Con::getIntVariable("$pref::particles::LoD3", 32000);
   S32 levelLoD4 = Con::getIntVariable("$pref::particles::LoD4", 32000);[/b]
   Point3F cameraPos = state->getCameraPosition();[/b]
   for (U32 i = 0; i < orderedVector.size(); i++) {
      Particle* particle = orderedVector[i].p;
	  [b]S32 distFromCam = mPow(particle->pos.x - cameraPos.x,2) + mPow(particle->pos.y - cameraPos.y,2) + mPow(particle->pos.z - cameraPos.z,2);
	 // Point3F distFromCam = particle->pos - cameraPos;
	  showParticle = true;
	  if(distFromCam < levelLoD4 && particle->LoD > 1)
	        showParticle = false;
	  else if(distFromCam < levelLoD3 && particle->LoD > 2)
		showParticle = false;
	  else if(distFromCam < levelLoD2 && particle->LoD > 3)
		showParticle = false;
	  else if(distFromCam < levelLoD1)
		showParticle = false;
	  if(showParticle)
	  {[/b]

		  if( particle->dataBlock->animateTexture )
		  {
			 U32 texNum = particle->currentAge * (1.0/1000.0) * particle->dataBlock->framesPerSec;
			 texNum %= particle->dataBlock->numFrames;
			 glBindTexture(GL_TEXTURE_2D, particle->dataBlock->textureList[texNum].getGLName());
		  }
		  else
		  {
			 glBindTexture(GL_TEXTURE_2D, particle->dataBlock->textureList[0].getGLName());
		  }

		  if( mDataBlock->orientParticles )
		  {
			 renderOrientedParticle( *particle, state->getCameraPosition() );
		  }
		  else
		  {
			 renderBillboardParticle( *particle, basePoints, camView, spinFactor );
		  }

	[b]  }[/b]
   }

Now, one problem with this - obviously we're performing more operations per loop now. It doesn't seem for affect things too much, but, YMMV. If someone sees how to speed this up a bit more (as mentioned in another thread, I am not an Uber-hacker. I just get by ;-) post it :-) (Ask, and ye shall recieve - thanks guys! Now uses considerably less operations per loop :-)

Right now, it's basically got 5 levels of detail, ranging from viewing all (anything greater than 1024) to none (at less than 64). Depending on how many particles are on-screen you may or may not notice the 'popping' of particles as you cross the boundries.

I assigned random numbers for a reason - I figured out that any incremental way of doing it (ie, just i++ from 1 to 4) can produce some really funky results that look bad - the more particles there are, the less likely it is to happen. The randomness also gives a little more character to stuff that falls in the range of the LoD system - not all explosions look identical, etc.

Hope this turns out to be of help for someone else :-)

(PS: if someone happens to know an easy way to snag the profile information, I'll add a reduction based off of fps to this, and see how much impact it has, and throw a $pref in there so clients can control it.)