More on ExtrudedPolyList
by Joel Baxter · in Torque Game Engine · 04/22/2002 (3:34 am) · 1 replies
(Breaking this out from the Item thread.)
Some of the TGE objects (Item and Player anyway... haven't checked out the new vehicle code) use an ExtrudedPolyList to represent the path of the object's axis-aligned world bounding box over the course of a tick, in collision calculations. Some things I've noticed about this beast:
---
Only the "leading faces" of the polyhedron are dealt with. Each face with a normal that is less than 90 degrees away from the direction of extrusion is extruded into a new polyhedron; the other faces are discarded. (If the extrusion distance is zero, all faces are discarded.) This is probably fine for use in collision tests, but might not be what you would have expected.
---
The "velocity" vector you set for the extruded polylist is used in collision testing to discard polygons that are facing away from it. Doesn't look like the magnitude of this vector matters.
Because the extrusion behavior seems to generally limit this class to being used for collision testing, with extrusion in the direction of motion, the velocity vector should probably always be in the direction of extrusion. Can't immediately think of any reason to supply a different velocity vector. (Is there?)
---
If you extrude a polyhedron that has more than 30 faces, you may overrun fixed arrays in the code. Likely everyone will just be extruding boxes, but some odd folks may be interested in extruding more complex shapes... if so, be careful.
---
There's a member function adjustCollisionTime which, according to the comments, is to be "called after all the polys have been added", but it isn't currently called by any code in TGE. Its purpose is apparently to adjust the returned t value that indicates when in the tick a collision occurred. However, after looking at the code that originally calculates the t value, I can't see why it would need adjusting... so I guess that I'm not surprised that this function is never called :) just a little uneasy about it.
It looks like t is originally calculated as the perpendicular distance from the collision point to the (pre-extrusion) colliding plane, divided by the total distance that the plane will travel in the direction of its normal during extrusion. That seems good to me.
If it turns out the adjustCollisionTime isn't needed, then the various faceShift-related code could go away, since the only use of that code is to track the "adjustments". On the other hand, if it is needed, then it should be called. :)
Some of the TGE objects (Item and Player anyway... haven't checked out the new vehicle code) use an ExtrudedPolyList to represent the path of the object's axis-aligned world bounding box over the course of a tick, in collision calculations. Some things I've noticed about this beast:
---
Only the "leading faces" of the polyhedron are dealt with. Each face with a normal that is less than 90 degrees away from the direction of extrusion is extruded into a new polyhedron; the other faces are discarded. (If the extrusion distance is zero, all faces are discarded.) This is probably fine for use in collision tests, but might not be what you would have expected.
---
The "velocity" vector you set for the extruded polylist is used in collision testing to discard polygons that are facing away from it. Doesn't look like the magnitude of this vector matters.
Because the extrusion behavior seems to generally limit this class to being used for collision testing, with extrusion in the direction of motion, the velocity vector should probably always be in the direction of extrusion. Can't immediately think of any reason to supply a different velocity vector. (Is there?)
---
If you extrude a polyhedron that has more than 30 faces, you may overrun fixed arrays in the code. Likely everyone will just be extruding boxes, but some odd folks may be interested in extruding more complex shapes... if so, be careful.
---
There's a member function adjustCollisionTime which, according to the comments, is to be "called after all the polys have been added", but it isn't currently called by any code in TGE. Its purpose is apparently to adjust the returned t value that indicates when in the tick a collision occurred. However, after looking at the code that originally calculates the t value, I can't see why it would need adjusting... so I guess that I'm not surprised that this function is never called :) just a little uneasy about it.
It looks like t is originally calculated as the perpendicular distance from the collision point to the (pre-extrusion) colliding plane, divided by the total distance that the plane will travel in the direction of its normal during extrusion. That seems good to me.
If it turns out the adjustCollisionTime isn't needed, then the various faceShift-related code could go away, since the only use of that code is to track the "adjustments". On the other hand, if it is needed, then it should be called. :)
Torque 3D Owner Joel Baxter
It looks like the original code used 64-bit bitmasks, as there are comments to that effect everywhere. As you might guess, I've been experimenting with extruding complex shapes... turns out that if I change over to 64-bit bitmasks, and reduce the number of generated extruded planes per face by 1 (by undoing a particular shortcut that required that extra plane), I can just exactly get by.