Collision Geometry - requirements and usage?
by Richard Wilson · in Torque Game Engine · 09/07/2005 (5:09 pm) · 6 replies
This post is a result of my recent work on swept sphere collision. For a pair of resources and brief commentary see: www.garagegames.com/mg/forums/result.thread.php?qt=34073
From that thread, Ben Garney directed me towards convexes and getPolyList(..) from them. Which is quite an acceptable solution for many things, though not mine I believe.
One of the simplest examples of what we are doing would be to collide against a static shape (TSStatic). Now collision meshes in Torque are SUPPOSED to be convex. For simple things it isn't all that hard to break your concave object/mesh into a number of convex meshes. AND, any fresh install of Torque is set up already for 8 collision meshes allowing for just this thing. So whenever you do a object->buildPolyList(...) on the static it will send all of the collision meshes into your poly list. The only real difference with Ben's approach is there is some extra management going on with the collision working set and such.. as well as that each convex is associated with a single collision detail. ( which makes sense because you were supposed to have only convex collision meshes -- which MIGHT define the pieces of a concave mesh ). I've not dug in and verified it, but it appears as though you may be able to save a bit of processing this route since your collision mesh, concave or not, is in smaller chunks which you can check bounds on separately -- please correct me if I'm wrong here.
Ok that's great, but lets say you want your static shape to be a high poly count torus. (yes...high poly, at least in the sense that at some point we really want polygon accurate to rendering) So much so that it's impossible to decompose into 8 convex meshes ( if you don't trust the torus being hard, use a block of Swiss cheese instead ). Well here's roughly where I sit with my work. I would like to use a mesh that is concave, and even if I tried to break it up I'd need far more than 8 meshes. There those who have simply modified Torque to allow more collision meshes. This might be reasonable, but for our case it's a bit of overkill I think. In particular, I don't care if it's convex or concave. I will use the collision mesh as a poly-soup sent to some swept sphere collision code. So a single mesh is acceptable, but to get the actual polys back outside of the object is the trouble.
Assuming you [can] export a mesh, whose collision mesh detail is a duplicate of the object mesh then the normal object->builPolyList(...) OR even the ->getPolyList(...) on the convexes obtained from the object would give you back the duplicated polys matching your objects rendered poly set. However, everywhere I've found notes that say "YOUR COLLISION MESH MUST BE CONVEX", allusions to errors and hints of crashing exporters. If anyone has a definitive answer at the moment I'd greatly appreciate the answer, as it would save me time digging through the max exporters and more object loading code.
In some simple tests, we tried a 622 poly irregular torus as a single collision mesh. It exported and worked in ShowTool and Torque flawlessly. At the moment I don't have the exact information on exporter version etc, though it was a max2dts exporter. The only trouble is that even members of my team seem to recall crashes loosely associated with concave collision meshes. If it's a mater of working with Torques collision system and gjk algorithms, it does not mater. So long as it's guaranteed to load and operate (and fail to work when used with Torque's collision system is fine) in the sense that I can pull polys back, then such a solution would be acceptable; wasteful, but acceptable non the less.
Comments, questions and such highly encouraged and appreciated.
From that thread, Ben Garney directed me towards convexes and getPolyList(..) from them. Which is quite an acceptable solution for many things, though not mine I believe.
One of the simplest examples of what we are doing would be to collide against a static shape (TSStatic). Now collision meshes in Torque are SUPPOSED to be convex. For simple things it isn't all that hard to break your concave object/mesh into a number of convex meshes. AND, any fresh install of Torque is set up already for 8 collision meshes allowing for just this thing. So whenever you do a object->buildPolyList(...) on the static it will send all of the collision meshes into your poly list. The only real difference with Ben's approach is there is some extra management going on with the collision working set and such.. as well as that each convex is associated with a single collision detail. ( which makes sense because you were supposed to have only convex collision meshes -- which MIGHT define the pieces of a concave mesh ). I've not dug in and verified it, but it appears as though you may be able to save a bit of processing this route since your collision mesh, concave or not, is in smaller chunks which you can check bounds on separately -- please correct me if I'm wrong here.
Ok that's great, but lets say you want your static shape to be a high poly count torus. (yes...high poly, at least in the sense that at some point we really want polygon accurate to rendering) So much so that it's impossible to decompose into 8 convex meshes ( if you don't trust the torus being hard, use a block of Swiss cheese instead ). Well here's roughly where I sit with my work. I would like to use a mesh that is concave, and even if I tried to break it up I'd need far more than 8 meshes. There those who have simply modified Torque to allow more collision meshes. This might be reasonable, but for our case it's a bit of overkill I think. In particular, I don't care if it's convex or concave. I will use the collision mesh as a poly-soup sent to some swept sphere collision code. So a single mesh is acceptable, but to get the actual polys back outside of the object is the trouble.
Assuming you [can] export a mesh, whose collision mesh detail is a duplicate of the object mesh then the normal object->builPolyList(...) OR even the ->getPolyList(...) on the convexes obtained from the object would give you back the duplicated polys matching your objects rendered poly set. However, everywhere I've found notes that say "YOUR COLLISION MESH MUST BE CONVEX", allusions to errors and hints of crashing exporters. If anyone has a definitive answer at the moment I'd greatly appreciate the answer, as it would save me time digging through the max exporters and more object loading code.
In some simple tests, we tried a 622 poly irregular torus as a single collision mesh. It exported and worked in ShowTool and Torque flawlessly. At the moment I don't have the exact information on exporter version etc, though it was a max2dts exporter. The only trouble is that even members of my team seem to recall crashes loosely associated with concave collision meshes. If it's a mater of working with Torques collision system and gjk algorithms, it does not mater. So long as it's guaranteed to load and operate (and fail to work when used with Torque's collision system is fine) in the sense that I can pull polys back, then such a solution would be acceptable; wasteful, but acceptable non the less.
Comments, questions and such highly encouraged and appreciated.
#2
Things like castRay as Stephen mentioned can be significantly faster if you assume you're working with a convex hull. GJK, similarly, makes that assumption. But if you're tossing the collision system then you're fine anyway.
TGE 1.4 supports infinite numbers of convexes in your meshes, though things will slow down if you've got lots of 'em.
It's worth noting that Marble Blast uses swept sphere collision, the player uses swept box collision, and both do just fine against the existing interfaces. Not to say that that's the best way, but it does work.
Why not try it and see? If I was to analyze this issue for you any further, I'd have to start experimenting, and there's no source more authoritative than "this is how it works; I've tested it." :)
09/07/2005 (10:22 pm)
Not sure what you're asking. Yes, the collision system occasionally assumes things should be convex. No, nothing else does that I know. No, we haven't tested this explicitly. Whenever I've implemented polysoup systems, I simply do it by making sure that what it emits as convexes _is_ convex, which is easily done (single triangles work great).Things like castRay as Stephen mentioned can be significantly faster if you assume you're working with a convex hull. GJK, similarly, makes that assumption. But if you're tossing the collision system then you're fine anyway.
TGE 1.4 supports infinite numbers of convexes in your meshes, though things will slow down if you've got lots of 'em.
It's worth noting that Marble Blast uses swept sphere collision, the player uses swept box collision, and both do just fine against the existing interfaces. Not to say that that's the best way, but it does work.
Why not try it and see? If I was to analyze this issue for you any further, I'd have to start experimenting, and there's no source more authoritative than "this is how it works; I've tested it." :)
#3
I'm aware of the reasons for convexity. Ben pretty much got the underlying point I was really looking for. In that, for the work I'm doing we are basically 'tossing' all existing collision notions. Yet, I'll make use of any piece which will cooperate with me. Such as putting in a single concave collision mesh and retrieving polys from it much they way Ben described in the originating thread I linked to earlier.
Marble Blast, or as I recall one of it's creators suggested swept sphere to my team. I was not privy to further detail, but presumed that most solutions would opt to go the route Ben mentioned ( pull back convexes and get polys from them ). This is fine, but if you need to have concave meshes most of your art pipeline for churning out convex collision hulls could get a bit upset. Imagine you wanted to play marble blast on the inside of a teapot. I know it's possible to create remarkably complex and curvatious objects as interiors (.diff). Though, my team has gone that route before me and found it both difficult and packed with it's own issues ( numerous threads speak of collision issues upon brush boundaries, one by a fellow team member ). In many regards this would be the more appropriate route to take much like Marble Blast did. However, I may be hamstrung by existing processes, skills and biases.
To date I have successfully had 2 concave meshes exported and working flawlessly within the engine (in poly soup terms. I've neither tested, nor intend to test standard Torque collision system with them as I'd assume they fail, or would be erratic). A third also works, though due to it's higher poly count and shape required a minor change to the convex hull accelerator code. There is an assumption that a convex hull will require no more than 256 face, edges, or vertices. Simply increasing the limit allows my complex mesh to pass through, yet it pays an exorbitant penalty upon mission load.
Thus far, I've all but concluded for my case that it is about time to derive my own object (possibly from TSStatic or it's convex class perhaps) such that I need not have a collision mesh at all. Instead pulling directly (or indirectly via the OBB / AABB trees mentioned earlier) the geometry from the primary model. If a few more coarse culls are insufficient and something such as AABB trees are to be used I beleive I'll then turn to something such as OPCODE.
Thanks again Stephen and Ben for your comments. If you or anyone else has more thoughts, comments or questions I'd be glad to hear them.
09/08/2005 (9:24 am)
Thanks for your comments Stephen and Ben!I'm aware of the reasons for convexity. Ben pretty much got the underlying point I was really looking for. In that, for the work I'm doing we are basically 'tossing' all existing collision notions. Yet, I'll make use of any piece which will cooperate with me. Such as putting in a single concave collision mesh and retrieving polys from it much they way Ben described in the originating thread I linked to earlier.
Marble Blast, or as I recall one of it's creators suggested swept sphere to my team. I was not privy to further detail, but presumed that most solutions would opt to go the route Ben mentioned ( pull back convexes and get polys from them ). This is fine, but if you need to have concave meshes most of your art pipeline for churning out convex collision hulls could get a bit upset. Imagine you wanted to play marble blast on the inside of a teapot. I know it's possible to create remarkably complex and curvatious objects as interiors (.diff). Though, my team has gone that route before me and found it both difficult and packed with it's own issues ( numerous threads speak of collision issues upon brush boundaries, one by a fellow team member ). In many regards this would be the more appropriate route to take much like Marble Blast did. However, I may be hamstrung by existing processes, skills and biases.
To date I have successfully had 2 concave meshes exported and working flawlessly within the engine (in poly soup terms. I've neither tested, nor intend to test standard Torque collision system with them as I'd assume they fail, or would be erratic). A third also works, though due to it's higher poly count and shape required a minor change to the convex hull accelerator code. There is an assumption that a convex hull will require no more than 256 face, edges, or vertices. Simply increasing the limit allows my complex mesh to pass through, yet it pays an exorbitant penalty upon mission load.
Thus far, I've all but concluded for my case that it is about time to derive my own object (possibly from TSStatic or it's convex class perhaps) such that I need not have a collision mesh at all. Instead pulling directly (or indirectly via the OBB / AABB trees mentioned earlier) the geometry from the primary model. If a few more coarse culls are insufficient and something such as AABB trees are to be used I beleive I'll then turn to something such as OPCODE.
Thanks again Stephen and Ben for your comments. If you or anyone else has more thoughts, comments or questions I'd be glad to hear them.
#4
09/08/2005 (3:43 pm)
Both the Marble and the Player code collide just fine against concave collision meshes. The only implication to having a non-convex collision mesh is that raycasts won't work against them (the dts raycast code assumes the mesh is convex). This is fairly trivial to fix. It is important to note that the vehicle collision is gjk-based and *does* require you to have convex collision meshes.
#5
09/08/2005 (6:16 pm)
Why not register triangles as seperate convexes in your collision code? This works perfectly in all the situations I've tried it in. It's a little heavy, sure, but its compatible and reliable. It seems like you're trying to cram "concave" into a "convex" slot when it would be easier to just work with what's there...
#6
Are you speaking directly towards the collision meshes of .dts's or more towards rolling your own convex subclass?
For clarity, I am dealing with things as an active collider only, never needing to deal much, if at all, with Torque's collisions.
My main focus would be to use what's available as much as possible, even if I'm bending it a little. And from my recent finding, bending the collision mesh requirments a bit for something like this works fine, so long as you don't get very complex (pretty much anything that breaks stock Torque, i.e. 256 faces on the convex hull of your otherwise concave mesh, or has a very high number of polys regardless).
As for the 'cramming'.
Yes: I've pushed a concave mesh into .dts convex mesh detail slot.
No: Within limits, the concave mesh as a collision mesh works fine since we don't ever use Torque's collision.
My situation is :
1. I've been told no .dif's so I'm stuck with .dts.
2. I have large complex objects
3. The objects will have concavities which must be interacted upon
4. The collision detail needs to be polygon perfect, or practically there, with respect to what the player sees.
5. Decomposition of the mesh to sub-convexes partially eludes us at the moment
(I say partially because we have a means, yet it complicates other points)
From what I've learned thus far, I think the only route to go in this situation is to either modify my shape class (say TSStatic); or derive as the case may be. And, in doing so deal with the greater polygon complexity in some manner (the afore mentioned AABB / OBB trees, or if you want to do a lot of work, incorporate unlimited collision meshes along with decomposition of the mesh to an efficient number of sub convexes)
If it weren't for #1, I'd use dif's and I'd be done with this task.
I'd appreciate your clarification Ben, and thanks again for your time and attention. I hardly expected to receive such interest and quality comments such as these [and the related thread] have received. My thanks to Matt and Stephen as well.
09/08/2005 (7:47 pm)
I'm not certain I follow you Ben.Are you speaking directly towards the collision meshes of .dts's or more towards rolling your own convex subclass?
For clarity, I am dealing with things as an active collider only, never needing to deal much, if at all, with Torque's collisions.
My main focus would be to use what's available as much as possible, even if I'm bending it a little. And from my recent finding, bending the collision mesh requirments a bit for something like this works fine, so long as you don't get very complex (pretty much anything that breaks stock Torque, i.e. 256 faces on the convex hull of your otherwise concave mesh, or has a very high number of polys regardless).
As for the 'cramming'.
Yes: I've pushed a concave mesh into .dts convex mesh detail slot.
No: Within limits, the concave mesh as a collision mesh works fine since we don't ever use Torque's collision.
My situation is :
1. I've been told no .dif's so I'm stuck with .dts.
2. I have large complex objects
3. The objects will have concavities which must be interacted upon
4. The collision detail needs to be polygon perfect, or practically there, with respect to what the player sees.
5. Decomposition of the mesh to sub-convexes partially eludes us at the moment
(I say partially because we have a means, yet it complicates other points)
From what I've learned thus far, I think the only route to go in this situation is to either modify my shape class (say TSStatic); or derive as the case may be. And, in doing so deal with the greater polygon complexity in some manner (the afore mentioned AABB / OBB trees, or if you want to do a lot of work, incorporate unlimited collision meshes along with decomposition of the mesh to an efficient number of sub convexes)
If it weren't for #1, I'd use dif's and I'd be done with this task.
I'd appreciate your clarification Ben, and thanks again for your time and attention. I hardly expected to receive such interest and quality comments such as these [and the related thread] have received. My thanks to Matt and Stephen as well.
Torque 3D Owner Stephen Zepp
Of course, if you are willing to do the research necessary, there are other collision algorithms that can be used...including increasing the number of total meshes allowed for complex shapes. You just need to keep in mind a couple of things:
1) This is going to severely affect performance, especially with the number of meshes you describe.
2) Collision checking has multiple steps, and from what you seem to be describing it's only the last one (most accurate) that is really important to you, so focus on that, but you really need to keep extremely close attention to performance as you develop an alternative strategy.