Particles and collisions?
by Christopher Gu · in Torque Game Builder · 12/07/2005 (1:22 pm) · 9 replies
Is it possible for particles to cast collisions in T2D? I have an object that periodically shoots out a stream of fire, in the form of a particle system. Is it possible to make my player take damage from this? Or do I have to create a new fxSceneObject2D and mount it behind the particles for my collisions to work?
#2
Making individual particles deal with collision can be very expensive, especially if they were against a tile-layer, but it's not that hard to add. I've avoided it so far because I can see the problems people will have with it. I really wanted to add this in but there were more pressing things to develop. I'm not saying I won't ever do it, hell, I might do it just for kicks if I get a chance.
In the end though, you don't really want your player having 300 collisions because he's just been hit by 300 particles from your "stream of fire", you want it to collide once or at only a few times. The particle-effect itself can collide with other objects but it may be better to have the effect mounted to an object that has a specific collision-shape that you want.
For instance, say it's a fireball effect that has the characteristic fireball shape, you're probably using the bounding-box to control the emission-space of the particles but because the particles move outside of the bounding-box, you probably want the collision-shape to be different. In this case, it's actually easier to have a t2dSceneObject with the collision-shape setup and then just mount the effect(s) to it.
In the alpha#1 though, the t2dParticleEffect can response to collisions as shown in some of my plans. It's still the circle/polygon collision though.
12/07/2005 (11:47 pm)
Christopher,Making individual particles deal with collision can be very expensive, especially if they were against a tile-layer, but it's not that hard to add. I've avoided it so far because I can see the problems people will have with it. I really wanted to add this in but there were more pressing things to develop. I'm not saying I won't ever do it, hell, I might do it just for kicks if I get a chance.
In the end though, you don't really want your player having 300 collisions because he's just been hit by 300 particles from your "stream of fire", you want it to collide once or at only a few times. The particle-effect itself can collide with other objects but it may be better to have the effect mounted to an object that has a specific collision-shape that you want.
For instance, say it's a fireball effect that has the characteristic fireball shape, you're probably using the bounding-box to control the emission-space of the particles but because the particles move outside of the bounding-box, you probably want the collision-shape to be different. In this case, it's actually easier to have a t2dSceneObject with the collision-shape setup and then just mount the effect(s) to it.
In the alpha#1 though, the t2dParticleEffect can response to collisions as shown in some of my plans. It's still the circle/polygon collision though.
#3
The request for particles colliding has come up before and this post kinda' raised it again so I decided to look at this thing just for fun and I had an hour or two to play (hey, this stuff is what I call fun at the moment).
The end result is quite suprising; looking at implementing particle collisions, I needed to determine how much per-particle collision-detection you can get away with and if it was enough to be useful then I'd think about implementing it.
The crazy thing was that just looking at this highlighted a few minor adjustments that, if made, would make the particles, picking and general collision-detection slightly faster. I made those adjustments and also a few others that were on my list such as converting the now quite old scene-container so that it used the t2dVector class rather than the TGE Point2F one.
I then simply did an override on the core "checkCollisionSend()" virtual functionality and implemented an iteration of all the particle-emitters in the effect and called a new "t2dParticleEmitter::actionParticleCollisions()" function which iterates the active particles. This took about 40-minutes and by golly if it didn't work very well and fast. I used the stock "steam.eff" which had approximately 200 particles active at any one time and adjusted so that it pumped out five-times that (1000 particles) and set it to collide with an object on the screen. This knocked down the FPS by about 18fps which really suprised me; that's very efficient considering that the collision-detection used is swept on an object with 24 edges. I got slightly less loss when using a circle for the target collision-frame.
Well, it looks like particles with collisions are definately on. The only thing I'll have to do, apart from organise the 3-4 hours work inbetween more important T2D stuff, is to consider how to specify the collision details. At the moment, I've got a flag which specifies whether to use the particle-effects collision details as the specifier meaning that you can switch between particle-effect-object collisions or particle-effect-particle collisions. The good thing about this approach is that there's simply a single extra function to switch between the two and I could default it either way.
Anyway, I took the time to take some snaps from my playing. Note that the juddering in the movie is because of the capturing, not anything T2D is doing; I bumped-up the capture to 60-fps so I could portray the fluid nature of the "smoke" particles.
Particles "Bounce" Mode Movie
Particles "Clamp" Mode Movie
- Melv.
12/15/2005 (8:46 am)
Okay, so I admit it, last weekend I was too tired to do what I normally do and spend all weekend working on T2D. What I did do was look through my list of "interesting stuff" to try. This is basically a list of things that I've thought-up or has been suggested/asked by the community.The request for particles colliding has come up before and this post kinda' raised it again so I decided to look at this thing just for fun and I had an hour or two to play (hey, this stuff is what I call fun at the moment).
The end result is quite suprising; looking at implementing particle collisions, I needed to determine how much per-particle collision-detection you can get away with and if it was enough to be useful then I'd think about implementing it.
The crazy thing was that just looking at this highlighted a few minor adjustments that, if made, would make the particles, picking and general collision-detection slightly faster. I made those adjustments and also a few others that were on my list such as converting the now quite old scene-container so that it used the t2dVector class rather than the TGE Point2F one.
I then simply did an override on the core "checkCollisionSend()" virtual functionality and implemented an iteration of all the particle-emitters in the effect and called a new "t2dParticleEmitter::actionParticleCollisions()" function which iterates the active particles. This took about 40-minutes and by golly if it didn't work very well and fast. I used the stock "steam.eff" which had approximately 200 particles active at any one time and adjusted so that it pumped out five-times that (1000 particles) and set it to collide with an object on the screen. This knocked down the FPS by about 18fps which really suprised me; that's very efficient considering that the collision-detection used is swept on an object with 24 edges. I got slightly less loss when using a circle for the target collision-frame.
Well, it looks like particles with collisions are definately on. The only thing I'll have to do, apart from organise the 3-4 hours work inbetween more important T2D stuff, is to consider how to specify the collision details. At the moment, I've got a flag which specifies whether to use the particle-effects collision details as the specifier meaning that you can switch between particle-effect-object collisions or particle-effect-particle collisions. The good thing about this approach is that there's simply a single extra function to switch between the two and I could default it either way.
Anyway, I took the time to take some snaps from my playing. Note that the juddering in the movie is because of the capturing, not anything T2D is doing; I bumped-up the capture to 60-fps so I could portray the fluid nature of the "smoke" particles.
Particles "Bounce" Mode Movie
Particles "Clamp" Mode Movie
- Melv.
#4
That's great work Melv. Can't wait for the next release of T2D that will have that stuff in it :)
12/15/2005 (8:53 am)
Just watched those vids, and that's awesome!That's great work Melv. Can't wait for the next release of T2D that will have that stuff in it :)
#5
Particles are just so much damn fun to play with and collisions can make them much more interactive rather than just layered over the scene.
- Melv.
12/15/2005 (9:01 am)
I accidentally uploaded the wrong "bounce" video but the correct one should be up there now.Particles are just so much damn fun to play with and collisions can make them much more interactive rather than just layered over the scene.
- Melv.
#7
By the way, Melv, you said it knocked the framerate down 17fps. What was the total framerate, so I can get a general idea of how much the performance was actually hit?
12/15/2005 (5:44 pm)
This is wonderful! T2D is such a kickass 2D engine. I'm impressed and quite happy that it ended up not taking too much of a hit to put in collision. Thank you Melv!By the way, Melv, you said it knocked the framerate down 17fps. What was the total framerate, so I can get a general idea of how much the performance was actually hit?
#8
-Dave C.
12/15/2005 (6:09 pm)
Excellent work, Melv. This is a very exciting addition to an already wonderful game engine!-Dave C.
#9
I wouldn't take these figures too seriously as they've come from my very quick testing regime and don't take into account how many actual collisions were taking place and stuff like that. I think the point is that it's probably going to be fast enough to have at least moderate particle effects with collisions and crazy ones on the higher-end machines.
My current list of responses are STICKY, CLAMP, BOUNCE & KILL. Also, before anyone asks, the collisions are using a line-sweep, not a polygon/circle sweep although I'm sure it'll get asked for eventually. ;)
ADDED: All BOUNCE modes now use restitution so you can control the energy of the bounce and this is the same for particles.
- Melv.
12/15/2005 (11:37 pm)
@DaveF: It's shown in the image above; I get an average of 298fps typically as there's a ceiling of 300fps using TGE v1.3 but this changes when you merge with TGE v1.4.I wouldn't take these figures too seriously as they've come from my very quick testing regime and don't take into account how many actual collisions were taking place and stuff like that. I think the point is that it's probably going to be fast enough to have at least moderate particle effects with collisions and crazy ones on the higher-end machines.
My current list of responses are STICKY, CLAMP, BOUNCE & KILL. Also, before anyone asks, the collisions are using a line-sweep, not a polygon/circle sweep although I'm sure it'll get asked for eventually. ;)
ADDED: All BOUNCE modes now use restitution so you can control the energy of the bounce and this is the same for particles.
- Melv.
Torque 3D Owner Matthew Langley
Torque