New Particle Engine?

#21

Quote:Also another thing I'd like to see is water affecting particles. It always bugged me when a particle from a fireball or something would sink underwater, etc. What would be nice is to be able to set both an underwater particle that the particle itself switches to if it goes underwater (this could be set to just delete the particle too) and a alternate particle for the emitter to spawn if underwater (or tell it not to spawn underwater). Using a combination of these 2 you could get your particles working with the water really nicely.

I've actually submitted a resource to Tim Gift regarding projectile particle emitters and water. Basically what happens is I replace the air emitter, such as smoke, with a water emitter, such as bubbles. This was how Tribes 2 handled particles in water, particularily particles that would make bubbles for instance. I'm still waiting on it being included into the latest HEAD. I believe Tim Gift said he was waiting on some art for it.

#22 Just a little note, recently while bashing my head open trying to get some stupid thing working I got the idea to see what would happen if I threw in a raycast for collision checking on particles.

It is rediculous how easy it is:

I just put this in under the function updateSingleParticle in particleEngine.h . There are 0 problems and it didn't slow down my computer at all that I could notice, and I even did it sloppily here.

Point3F a = particle->acc;
   a -= particle->vel        * particle->dataBlock->dragCoefficient;
   a -= ParticleEngine::windVelocity * particle->dataBlock->windCoefficient;
   a += Point3F(0, 0, -9.81) * particle->dataBlock->gravityCoefficient;

   particle->vel += a * t;

// added part ----------------
	RayInfo rInfo;
	if(gClientContainer.castRay(particle->pos, particle->pos + particle->vel * t, TerrainObjectType | InteriorObjectType | VehicleObjectType, &rInfo))
	{
		particle->vel *= -1;
	}
// end addition ---------------

   particle->pos += particle->vel * t;

Now of course there are better ways of doing this. I was lazy so I decided to make them just reverse instead of deflect, which would probably look better. Does this slow anyone down? I didn't even notice a difference, even with about 20 emitters up at once.

#23 Max: We're using it on Trajectory now, and don't see a bit of slowdown, and we are using HUGE numbers of particle effects. Looks like it works wonderfully!

#24 Never know until you try, huh?

#25 Just to add a little insight into this discussion. I have played a little with the collision detection routines to see how it all hangs together.

It's all fairly simple really with each object eventually being called to determine it's own collisions with the cast ray.

As long as the particle velocities don't get silly here you should be okay. The problems come when the ray-casts project large distances without collisions as you end up doing huge amounts of bin checks.

For anyone playing with this it's interesting to note that you can change the bin sizes themselves e.g. the container boxes that objects get placed in to lump together collisions. Objects that are too big to fit into a box or lay on their boundaries get stuffed into the overflow bin. You should get different performance characteristics dependant upon these settings. Look at the top of the SceneObject.cc file at the constants defining the bin sizes to see what I mean.

Don't go changing this stuff unless you are sure you know what you are doing ... or have a backup or course. ;)

- Melv.

#26 On the 27th I officially begin work with the Torque, and unless Melv beats me to it, I might submit a CVS patch/community resource to increase the already powerful particle engine.

I agree that motion/radial blurring would be a nice touch, collision detection is a must, and easy attachment is very needed.

A LOD algorithm would be helpful for making the particle's resize based on distance so that above stated FPS problem doesn't happen. Honestly I don't recall such a problem in Tribes 2, and I have a PowerVR Kyro2 (supposed to have the most conflicts with the Torque).

#27 Trae,

I'm not working on this at the moment so I'm not going to beat you at the post. ;)

Good luck with it. 8)

- Melv.

#28 Heh, thanks Melv. I don't know what is more fun, working or not working. Although I'm certain by "not working" you are working, just not with the Torque. :)

From the looks of it, you could probably do a better job at it than me, but I think its fair you get a break and that someone else submits something to the community for once. ;)

#29 Blast from the past.

#30 Indeed...

I will be working on this sooner or later (as promised), right now I am doing mostly scripting and scripting-related changes.

Just don't hold your breath, I have my superiors to answer to before I can get to this.

#31 I assume no progress has been made, Ernest? (Since this thread died long ago...)

#32 Yeah has there been any progress here??
what i was thinking for collision is quite simple (don't know if it works)

use ParticleEmitter::updateBBox() so that it does a collision check with the bounding box of say the player for example? I'm not too sure, maybe some further discussion here would be great. But doing a volume collision check like stated above or what I propose (which is basically the same) could make the particle engine better (imagine going into a fog of posinous gas :)

#33 @kuni: Why not just place the partical and a trigger detection box around it for the gas damage efffect?

B--

#34 I know I could do this, but I really wanted that same effect of the trigger built into the particle emitter node. I guess i can even put it in the C code to include a trigger, but really collision detection (even box based) should be built into the node. Any other suggestion?