Plan for Melv May
by Melv May · 06/18/2004 (12:01 pm) · 6 comments
Plans coming thick and fast!
The Torque Retro collision system is finished ... let's get on with the tech-demo!
The collision system maintains debug metrics that are extremely useful in tuning the performance of the system. For hundreds of objects it's not a problem but if you intend to have thousands of collidable 'things' then you'll need to configure the collision system appropriately which is really easy and again, done from the scripts.
The system tracks potentials/actuals/hit-percentage of lots of stuff. You can turn on individual debug metrics with a command sent to any of the windows that are displaying a scene. I've limited it here to objects, renders and collisions for brevity.
In the following scene I added 4 background images (no collisions setup) and 500 spinning ships that are red when colliding and green when not. The first image shows them without b/box & aabb and the second with them on. All ships are set to potentially collide with anything else so there's a potentially *huge* collision check. Also, the worst thing is happening in that all the objects are constantly in motion so there are 500 collision system updates per frame. Let's stress this sucker!
The thing to note here is that out of 504 objects in the scene, the system has decided that 439 are potentially in the view and the actual was 439 which is a %100 hit. At the moment, I'm having difficulty getting this below 93%. The other thing to note and more impressive is that there are a potential of 2908 collisions of which 2350 resulted in a positive collision via the aabb. This obviously depends on the positions and varies accordingly but average is 89% running this demo over 5 minutes. This can be increased (or degraded) by tuning of the collision system. There's actually a way to calculate it dynamically using statistics but changing the collision bin system dynamically is another matter, an interesting problem for another time perhaps.
Note that some objects are red e.g. colliding but appear to be on their own. This is not a bug but simply shows the weak random number generator used in controlling the motions. These are several objects overlaid, some completely.
Anyway, enough talk, here are the images .... more on their way ...
- Melv.
The Torque Retro collision system is finished ... let's get on with the tech-demo!
The collision system maintains debug metrics that are extremely useful in tuning the performance of the system. For hundreds of objects it's not a problem but if you intend to have thousands of collidable 'things' then you'll need to configure the collision system appropriately which is really easy and again, done from the scripts.
The system tracks potentials/actuals/hit-percentage of lots of stuff. You can turn on individual debug metrics with a command sent to any of the windows that are displaying a scene. I've limited it here to objects, renders and collisions for brevity.
In the following scene I added 4 background images (no collisions setup) and 500 spinning ships that are red when colliding and green when not. The first image shows them without b/box & aabb and the second with them on. All ships are set to potentially collide with anything else so there's a potentially *huge* collision check. Also, the worst thing is happening in that all the objects are constantly in motion so there are 500 collision system updates per frame. Let's stress this sucker!
The thing to note here is that out of 504 objects in the scene, the system has decided that 439 are potentially in the view and the actual was 439 which is a %100 hit. At the moment, I'm having difficulty getting this below 93%. The other thing to note and more impressive is that there are a potential of 2908 collisions of which 2350 resulted in a positive collision via the aabb. This obviously depends on the positions and varies accordingly but average is 89% running this demo over 5 minutes. This can be increased (or degraded) by tuning of the collision system. There's actually a way to calculate it dynamically using statistics but changing the collision bin system dynamically is another matter, an interesting problem for another time perhaps.
Note that some objects are red e.g. colliding but appear to be on their own. This is not a bug but simply shows the weak random number generator used in controlling the motions. These are several objects overlaid, some completely.
Anyway, enough talk, here are the images .... more on their way ...
- Melv.
About the author
#2
I forgot to mention something here that someone may pick up on. To speed things up further, the system only checks objects that have been updated or have updated themselves. This may sound problematic for objects which haven't moved and another object has collided with them but not so. Because, in this much simplified system, the collision-events are symmetric; we can take the opportunity to check the backwards collisions even if the forward collisions don't take place based upon collision/layer masking rejections. In english, it means that if I even trivially collide with you, then you'll also get to check if you collide with me. This is made faster by tagging each object with a serialisation id which stops duplicating collision checks (even trivial ones) dead in their tracks. Doing this adds a *massive* boost in performance alone and is worth all the code bulk and internal complexity that comes with it.
There are other complexities such as objects having velocity vectors to check but that's another story.
Hey, all this has been done before at some point but I'm just hyped that it works so well and stable. :)
This probably doesn't make too much sense at this juncture but it will all become clear in time.
- Melv.
06/18/2004 (1:00 pm)
Tech Demo work will begin in the morning. :)I forgot to mention something here that someone may pick up on. To speed things up further, the system only checks objects that have been updated or have updated themselves. This may sound problematic for objects which haven't moved and another object has collided with them but not so. Because, in this much simplified system, the collision-events are symmetric; we can take the opportunity to check the backwards collisions even if the forward collisions don't take place based upon collision/layer masking rejections. In english, it means that if I even trivially collide with you, then you'll also get to check if you collide with me. This is made faster by tagging each object with a serialisation id which stops duplicating collision checks (even trivial ones) dead in their tracks. Doing this adds a *massive* boost in performance alone and is worth all the code bulk and internal complexity that comes with it.
There are other complexities such as objects having velocity vectors to check but that's another story.
Hey, all this has been done before at some point but I'm just hyped that it works so well and stable. :)
This probably doesn't make too much sense at this juncture but it will all become clear in time.
- Melv.
#3
06/18/2004 (3:17 pm)
I'm really looking forward to getting my hot little hands on this, Melv! :)
#4
No clue what I'll do with it.. but I consider it to be like a Pokemon... gotta get em all
06/18/2004 (4:00 pm)
Oh yes... It will be mine.. Torque Retro will be mine.....No clue what I'll do with it.. but I consider it to be like a Pokemon... gotta get em all
#5
06/18/2004 (6:07 pm)
yeah, i'm another expecting, drooling fan of this one :)
#6
06/18/2004 (7:56 pm)
LabRat - that's a lot of sprites, might be hard to catch! 
Associate Ron Yacketta