Collision : getPolyList/buildPolyList... which one do I want?
by Justin DuJardin · in Torque 3D Professional · 07/24/2009 (7:43 pm) · 10 replies
EDIT: I've re-classified this thread as informational, and not reporting a bug. The solution for my problem was to rely on buildPolyList rather than getPolyList. getPolyList generates tetrahedrons from each triangle so that the GJK solver (that powers the vehicles physics) will work properly.
I've been debugging an issue with player collision in Torque3D, and believe that the OPcode poly soup may be doing weird things.
For reference I'm using a modified version of the 3D Action Adventure Kit from Ubiq visuals that I've ported to Torque3D.
Most of the functionality of the player worked out of the box with a DTS counterpart, except for the ledge grabbing bit.
I've been down a number of bad roads trying to figure out why this could be, and then realized that by manually calling buildPolyList instead of relying on Convex::getPolyList functionality fixes the issue.
From all the tracing into the code I've done, it seems like both of these should be returning the same data, but here's what I've found :
getPolyList

buildPolyList

Looking a bit further into why there is a discrepancy, I stumbled across this function that appears to be what is generating the pyramid shape geometry that's being passed into the working list.
Thanks for your thoughts.
Edit: Props to KillerBunny for halping me understand what was going on.
I've been debugging an issue with player collision in Torque3D, and believe that the OPcode poly soup may be doing weird things.
For reference I'm using a modified version of the 3D Action Adventure Kit from Ubiq visuals that I've ported to Torque3D.
Most of the functionality of the player worked out of the box with a DTS counterpart, except for the ledge grabbing bit.
I've been down a number of bad roads trying to figure out why this could be, and then realized that by manually calling buildPolyList instead of relying on Convex::getPolyList functionality fixes the issue.
// GOOD pConvex->getObject()->buildPolyList(&polyList, plistBox, SphereF()); // BAD pConvex->getPolyList(&polyList);
From all the tracing into the code I've done, it seems like both of these should be returning the same data, but here's what I've found :
getPolyList

buildPolyList

Looking a bit further into why there is a discrepancy, I stumbled across this function that appears to be what is generating the pyramid shape geometry that's being passed into the working list.
bool TSMesh::buildConvexOpcode( const MatrixF &meshToObjectMat, const Box3F &nodeBox, Convex *convex, Convex *list )
Thanks for your thoughts.
Edit: Props to KillerBunny for halping me understand what was going on.
About the author
#2
I have no freaking idea why it is doing this, but that is what it is doing, and why it looks like that.
07/24/2009 (9:08 pm)
Those are pyramids. The base of each pyramid is a triangle that has been passed by the collision box check. TSMesh::buildConvexOpcode creates an instance of TSStaticPolysoupConvex for every triangle that is returned by the opcode collider.I have no freaking idea why it is doing this, but that is what it is doing, and why it looks like that.
#3

Can you put up the problem DTS somewhere or email it to me and I'll have a look...
07/25/2009 (1:37 am)
I haven't been able to reproduce this in the Warrior Camp. However, I did run into some hilarity with the collision on the campfire :)
Can you put up the problem DTS somewhere or email it to me and I'll have a look...
#4
07/25/2009 (3:29 am)
Wow! That's an amazing lot of collision detail for a campfire :D
#5
I've put up a zip containing the DAE colored blocks that you see in my screenshots.
Please note that you will not likely get the same simplified collision rendering that I have in these shots. I am actually rendering just the polyList results from my ledge grabbing method, not the entire mConvex of the player.
blocks.zip
These shapes are just 1x1x1 cubes that I created in constructor, then converted from .DIF to .DAE in T3D.
Let me know if there's anything else I can provide to help you with this.
07/25/2009 (10:12 am)
Hi Josh,I've put up a zip containing the DAE colored blocks that you see in my screenshots.
Please note that you will not likely get the same simplified collision rendering that I have in these shots. I am actually rendering just the polyList results from my ledge grabbing method, not the entire mConvex of the player.
blocks.zip
These shapes are just 1x1x1 cubes that I created in constructor, then converted from .DIF to .DAE in T3D.
Let me know if there's anything else I can provide to help you with this.
#6
I'm still not 100% certain this is a fix for all cases, it definitely allows my game to appear to behave properly.
07/25/2009 (2:43 pm)
Update: I managed to fix this oddity on my end of things. The two code paths that should be doing the same thing, now appear to be doing the same thing. I'm still not 100% certain this is a fix for all cases, it definitely allows my game to appear to behave properly.
#7
07/25/2009 (2:52 pm)
EDIT: Removed code patch as it's not really useful.
#8
You will probably find issues with some other object types, although if e.g. terrain (where this collision reporting idiom originated) doesn't give you good connectivity it's probably not a big deal.
As you've noticed different ways of getting the polylist give different results; in terms of cleanliness you probably want to actually use the object's polylist rather than getting the polylist of the convex - the latter is not guaranteed to give you real connectivity.
07/27/2009 (11:47 am)
It generates tetrahedrons so that vehicle collision works properly. The vehicle collision uses the GJK algorithm and expects that the convexes it is given have volume, which a flat triangle does not. To my knowledge no other collision consumer in the engine assumes valid connectivity, so you represent a whole new usage scenario. :) You will probably find issues with some other object types, although if e.g. terrain (where this collision reporting idiom originated) doesn't give you good connectivity it's probably not a big deal.
As you've noticed different ways of getting the polylist give different results; in terms of cleanliness you probably want to actually use the object's polylist rather than getting the polylist of the convex - the latter is not guaranteed to give you real connectivity.
#9
07/27/2009 (3:33 pm)
Logged as THREED-604
#10
After speaking with ClarkF and BenG about this, it appears the tetrahedrons are a necessary evil in current Torque. I'll rely on buildPolyList to generate a set of triangles that I can query in the way that I need to.
You can probably close this as a bug.
Thanks!
07/29/2009 (11:55 am)
Thanks for following up on our conversation in this thread, Ben!After speaking with ClarkF and BenG about this, it appears the tetrahedrons are a necessary evil in current Torque. I'll rely on buildPolyList to generate a set of triangles that I can query in the way that I need to.
You can probably close this as a bug.
Thanks!
Torque 3D Owner Robert Blanchet Jr.