LOS Collision, what is it used for ??
by Jorgen Ewelonn · in Torque Game Engine · 03/18/2004 (2:05 pm) · 8 replies
Ok, I asked this question in the general modelling forum and didn't get anything real out of it so please don't shoot me for posting in several areas.
The question:
Why (and where) do I want to add LOS Collision ?
As far as searching the Documentation and forums/resources I've gathered that it is only used when modelling projectiles, is this correct?
If not, what is the difference between Col and LOS col ?? and where do I apply LOScol ... ?
thx
The question:
Why (and where) do I want to add LOS Collision ?
As far as searching the Documentation and forums/resources I've gathered that it is only used when modelling projectiles, is this correct?
If not, what is the difference between Col and LOS col ?? and where do I apply LOScol ... ?
thx
#2
LOScol meshes should be included for any object that needs to react to projectile fire. It sounds like you have alredy done good searching on the subject, but if you haven't yet, I would check out some of the DTS docos, and some of Matthew Fairfax's work on collision stuff too.
Sorry that I can't offer more specific details, but I hope this bit helps a little bit.
03/23/2004 (2:13 pm)
Well, to be honest, I'm not an expert with this stuff. Haven't yet had time to research it extensively. However, it is my understanding that, yes, LOScol is used for projectile collisions.LOScol meshes should be included for any object that needs to react to projectile fire. It sounds like you have alredy done good searching on the subject, but if you haven't yet, I would check out some of the DTS docos, and some of Matthew Fairfax's work on collision stuff too.
Sorry that I can't offer more specific details, but I hope this bit helps a little bit.
#3
I was under the impression that the actual projectile was the thingy needing a LOScol mesh, now I understand that it is the object that is supposed to be hit that needs it..
Altough, this raises the question, why do you have to brake this apart from the regular collision?
Could it be that the regular collision isn't checked as often (or in a different way)??
I will continue my search along the direction you've pointed..
thanks Josh
03/23/2004 (3:03 pm)
Well actually Josh this helps alot.Quote:LOScol meshes should be included for any object that needs to react to projectile fire.
I was under the impression that the actual projectile was the thingy needing a LOScol mesh, now I understand that it is the object that is supposed to be hit that needs it..
Altough, this raises the question, why do you have to brake this apart from the regular collision?
Could it be that the regular collision isn't checked as often (or in a different way)??
I will continue my search along the direction you've pointed..
thanks Josh
#4
As far as the reasoning behind the design with separate collision meshes...
Collision detection is a very computationally expensive process. Because of that, the less collision detection you have to do, the better your game may run.
Torque is designed to handle all kinds of different games, and that means it has to be very flexible. Part of that means being able to handle games where the designers want to have many, many projectiles flying around.
Projectiles generally move around very swiftly, so that means that projectile collisions have to be detected very quickly.
Now, if you have a situation where you have lots of projectiles flying around, and all those projectiles need to have expensive collision detects done very quickly... you can see things can get pretty hairy.
So, Torque says "hey, sometimes we don't need to check for projectile collisions against every single object in the world." For example, if your game is set outdoors and there are lots of tiny rocks on the terrain.. you may not need to check for projectile collision with all the rocks... you could just let the collision happen against the terrain.
So, by only providing a projectile collision mesh for a subset of all the objects in the world, a game can run faster. Really, the most important thing to check for projectile collision are the players, and then the terrain and structures on the level. Anything else, we can sometimes think about fudging a bit to save on processor power.
Of course, there's nothing that says we can't check every single object for projectile collision, if that's what the game design calls for. The LOScol mesh attachment process is pretty painless and as long as you generate convex sub-meshes where appropriate, everything will work fine. Torque just gives you the option to optimize your game, should you need or want to.
Anyway, don't know if you wanted a long-winded explanation like that, but maybe someone will find it interesting at some point. :)
Please Note: I am not, by any means, an expert on how Torque handles all this stuff yet. I haven't had time to make a thorough study of the collision system at this point (I think only a few people ever have). The above represents my current knowledge about how the system works, but I could be completely off-base. :) Anyone who knows better should feel free to correct me if I've made a mistake.
03/24/2004 (2:27 am)
No prob. Good luck and chime in if you have any more q's.As far as the reasoning behind the design with separate collision meshes...
Collision detection is a very computationally expensive process. Because of that, the less collision detection you have to do, the better your game may run.
Torque is designed to handle all kinds of different games, and that means it has to be very flexible. Part of that means being able to handle games where the designers want to have many, many projectiles flying around.
Projectiles generally move around very swiftly, so that means that projectile collisions have to be detected very quickly.
Now, if you have a situation where you have lots of projectiles flying around, and all those projectiles need to have expensive collision detects done very quickly... you can see things can get pretty hairy.
So, Torque says "hey, sometimes we don't need to check for projectile collisions against every single object in the world." For example, if your game is set outdoors and there are lots of tiny rocks on the terrain.. you may not need to check for projectile collision with all the rocks... you could just let the collision happen against the terrain.
So, by only providing a projectile collision mesh for a subset of all the objects in the world, a game can run faster. Really, the most important thing to check for projectile collision are the players, and then the terrain and structures on the level. Anything else, we can sometimes think about fudging a bit to save on processor power.
Of course, there's nothing that says we can't check every single object for projectile collision, if that's what the game design calls for. The LOScol mesh attachment process is pretty painless and as long as you generate convex sub-meshes where appropriate, everything will work fine. Torque just gives you the option to optimize your game, should you need or want to.
Anyway, don't know if you wanted a long-winded explanation like that, but maybe someone will find it interesting at some point. :)
Please Note: I am not, by any means, an expert on how Torque handles all this stuff yet. I haven't had time to make a thorough study of the collision system at this point (I think only a few people ever have). The above represents my current knowledge about how the system works, but I could be completely off-base. :) Anyone who knows better should feel free to correct me if I've made a mistake.
#5
Your long winded description helped me out.
I see the logic of oject detected as opposed to projectile detected collisons now.
05/13/2006 (2:07 pm)
Josh, Your long winded description helped me out.
I see the logic of oject detected as opposed to projectile detected collisons now.
#6
05/13/2006 (5:41 pm)
I still don't understand LOSCollision at all, because projectiles collide with normal collision data just fine. Is it for making collision data that _only_ projectiles check then, so you can have more complex collision for projectiles? The explanation seems to say that it creates collision just for colliding with projectiles, but that's backwards to the reasoning it provides (having a bunch of rocks that _don't_ check for projectile collision). 
#7
The LOS-n collision details are used for determining ray cast collisions against ShapeBase and TSStatic classes and anything that derives from them (with the noteable exception of the Player class which uses its own method of determining collisions based on its bounding box).
If you don't have at least one LOS-n collision detail on your object, it will always return false from any ray cast made against it -- effectively meaning that it acts like it has "no collision" in many circumstances.
Projectiles, because they rely on ray casts to determine their movement and what they're able to hit, are just the most obvious game entity to act "buggy" when you don't have any LOS-n collision. They simply ignore the object and travel right on through it.
Aside from projectiles, you'll also get problems with precipitation, pretty much all the replicators, fxsunlight, lightning, and even some parts of the editor.
Note however, that even without any LOS-n collision details, an object with regular collision details may still act as if it has collision against other classes. For example, a Player might still have its movement blocked by a static object that has only regular collision details -- because it does not rely on raycasts to determine collisions made during its movement.
05/13/2006 (5:45 pm)
I don't know where everyone is getting the idea that the LOS-n collision details solely related to projectiles. Though they are indirectly related to the way they function, they are otherwise unrelated.The LOS-n collision details are used for determining ray cast collisions against ShapeBase and TSStatic classes and anything that derives from them (with the noteable exception of the Player class which uses its own method of determining collisions based on its bounding box).
If you don't have at least one LOS-n collision detail on your object, it will always return false from any ray cast made against it -- effectively meaning that it acts like it has "no collision" in many circumstances.
Projectiles, because they rely on ray casts to determine their movement and what they're able to hit, are just the most obvious game entity to act "buggy" when you don't have any LOS-n collision. They simply ignore the object and travel right on through it.
Aside from projectiles, you'll also get problems with precipitation, pretty much all the replicators, fxsunlight, lightning, and even some parts of the editor.
Note however, that even without any LOS-n collision details, an object with regular collision details may still act as if it has collision against other classes. For example, a Player might still have its movement blocked by a static object that has only regular collision details -- because it does not rely on raycasts to determine collisions made during its movement.
#8
As for the rock example provided 2 years ago by Josh.. he was saying that it is not worth the overhead if you have many static (enviroment) items to have them doing LOS checks when you could just let the projectile pass through and record its impact on the ground mesh.. if you have THAT many prjectiles flying and THAT many terrain objects that you need the decrease in cpu process.
05/14/2006 (9:18 am)
From my understanding LOS collisions are primarilly used for projectiles because they allow an object to determine a direction or specific area a collision occurrs.. cetain objects can only have one collision box but are allowed numerous LOS collision. As for the rock example provided 2 years ago by Josh.. he was saying that it is not worth the overhead if you have many static (enviroment) items to have them doing LOS checks when you could just let the projectile pass through and record its impact on the ground mesh.. if you have THAT many prjectiles flying and THAT many terrain objects that you need the decrease in cpu process.
Torque Owner Jorgen Ewelonn
so:
*bump*