Precipitation collision
by Daniel Buckmaster · in Torque Game Engine · 12/13/2008 (6:50 am) · 5 replies
Is it me, or is the precipitation collision code pretty hefty? Running starter.fps environment mission 1 (the rainforest) under a debug build, one precipitation object's raycasts were taking up 80% of processing time. When doCollision was unchecked, this dropped to about 0.15%. Under a release build, the values were 6.1% and 0.095%.
Is there a better way to do collision checks for precipitation?
If the objective were to make sure raindrops didn't enter buildings, wouldn't it be simpler to do a check to see whether the point of the precipitation was inside? If we want raindrops appearing on the ground, there should be some way to do this without having raindrops cast rays.
Bear in mind that I made a few assertations in the last paragraph I'm not sure about. I haven't looked into precipitation at all, I'm just going from the profiler output. And the fact that in the mision under a debug build, I get 2fps :P.
Is there a better way to do collision checks for precipitation?
If the objective were to make sure raindrops didn't enter buildings, wouldn't it be simpler to do a check to see whether the point of the precipitation was inside? If we want raindrops appearing on the ground, there should be some way to do this without having raindrops cast rays.
Bear in mind that I made a few assertations in the last paragraph I'm not sure about. I haven't looked into precipitation at all, I'm just going from the profiler output. And the fact that in the mision under a debug build, I get 2fps :P.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
- Only do collision for a fraction of the drops... you still get the same density of falling drops, but less splashes.
- Don't fully randomize the falling drops... generate a list of particle start and hit positions once and replay those. This would mean that you only have to recalculate hits when the camera is in motion and only for a fixed amount of particles.
- Don't try to match the falling particles to the splash particles... just randomly play splash particles. This could be used in combination with the first two ideas to further reduce the cost.
12/13/2008 (4:19 pm)
Performance under debug builds is never very useful... but your right that precip collision can be CPU intensive. A few ideas i had when working with it on TGEA...- Only do collision for a fraction of the drops... you still get the same density of falling drops, but less splashes.
- Don't fully randomize the falling drops... generate a list of particle start and hit positions once and replay those. This would mean that you only have to recalculate hits when the camera is in motion and only for a fixed amount of particles.
- Don't try to match the falling particles to the splash particles... just randomly play splash particles. This could be used in combination with the first two ideas to further reduce the cost.
#3
You're right about the debug guild... it was just there that I noticed the problem when I was playing around wih the profiler, and I was quite surprised at how large the load was. But even in a release version, am I right in thinking that 6% is quite a bit too large for the collisions of just one precipitation object?
Limiting the typemask could be a good idea... I'll have a look at what it currently does include.
Speaking of the typemask... it could be feasible to create a special sort of trigger for raindrop collision, and only have this type in the mask. That way buildings can be waterproofed, but raindrops only need test collision against a few simple objects.
12/14/2008 (2:20 am)
Quote:- Don't try to match the falling particles to the splash particles... just randomly play splash particles.That would be my solution... though niether this nor the first idea account for raindrops disappearing underneath objects.
You're right about the debug guild... it was just there that I noticed the problem when I was playing around wih the profiler, and I was quite surprised at how large the load was. But even in a release version, am I right in thinking that 6% is quite a bit too large for the collisions of just one precipitation object?
Limiting the typemask could be a good idea... I'll have a look at what it currently does include.
Speaking of the typemask... it could be feasible to create a special sort of trigger for raindrop collision, and only have this type in the mask. That way buildings can be waterproofed, but raindrops only need test collision against a few simple objects.
#4
6% may be acceptable depending on your game... rain isn't a simple thing to simulate and a fast general solution that solves everyones needs hasn't been found.
If i were concerned about collision performance using particle rain and need the raindrops to disapear under an object... like a bridge... i would consider using a special collision object just in that space to stop them from falling thru.
The problem with Torque typemasks is it currently works via a U32 and there are already too many of them. If you could find a bit to spare or expaned it to a U64 then having one just to identify objects which do collision with rain drops is not an entirely bad solution.
IMO... unless your planning to make a game where you spend all your time in the rain or have finished your game and have a performance problem... then i wouldn't worry about 6%. Keep focused on the importaint stuff.
12/14/2008 (3:13 am)
First off... if i were to approch doing rain specifically i would write a new screen based effect starting with Tatarchuk slides. There are also other good papers out there easily found via a google search.6% may be acceptable depending on your game... rain isn't a simple thing to simulate and a fast general solution that solves everyones needs hasn't been found.
If i were concerned about collision performance using particle rain and need the raindrops to disapear under an object... like a bridge... i would consider using a special collision object just in that space to stop them from falling thru.
The problem with Torque typemasks is it currently works via a U32 and there are already too many of them. If you could find a bit to spare or expaned it to a U64 then having one just to identify objects which do collision with rain drops is not an entirely bad solution.
IMO... unless your planning to make a game where you spend all your time in the rain or have finished your game and have a performance problem... then i wouldn't worry about 6%. Keep focused on the importaint stuff.
#5
This method saves some processing time as each drop only casts a single ray once during its lifetime rather than once per tick. The drawback is that it doesn't handle dynamic scenes as well as the standard code, although this may not be an issue depending on your game. As an example, players/vehicles/moving objects will, in most cases, not "collide" with raindrops as their position changes often enough that the raindrop's raycast will miss them entirely. Or, worse, the raindrop's raycast will hit a player only to have the player move out of the way before the drop reaches them leaving you with raindrops that reset seemingly in mid-air. This isn't an issue in my game as the raycast only checks for Interiors, Terrain, Water and Static DTS shapes but it's something worth noting.
12/14/2008 (4:22 pm)
I made some modifications to combat this very issue. Essentially each raindrop casts a single ray along the movement vector once at creation time. When the ray hits something, that point becomes the hitPos. Then, each time processTick is called, it's a simple comparison between the drop's current position and its hitPos. If the position/height is greater than the hitPos, the drop hasn't hit anything yet. If it's less than the hitPos, the raindrop has collided and should have its position reset. This method saves some processing time as each drop only casts a single ray once during its lifetime rather than once per tick. The drawback is that it doesn't handle dynamic scenes as well as the standard code, although this may not be an issue depending on your game. As an example, players/vehicles/moving objects will, in most cases, not "collide" with raindrops as their position changes often enough that the raindrop's raycast will miss them entirely. Or, worse, the raindrop's raycast will hit a player only to have the player move out of the way before the drop reaches them leaving you with raindrops that reset seemingly in mid-air. This isn't an issue in my game as the raycast only checks for Interiors, Terrain, Water and Static DTS shapes but it's something worth noting.
Torque Owner Stefan Lundmark