buildPolyList methods not respecting bounding box
by Daniel Buckmaster · in Torque 3D Professional · 11/29/2012 (3:14 am) · 0 replies
Not entirely sure if this is a bug or a feature. Some buildPolyList methods do not respect the bounding box that is passed to them. [GroundPlane](https://github.com/GarageGames/Torque3D/blob/master/Engine/source/T3D/groundPlane.cpp#L291) is a prime example - it simply adds its infinitely large plane to whatever buildConvex call is made. TerrainBlock is another culprit.
This is often fine for collision purposes, because having too much information isn't usually a problem. However, when integrating Recast, I found the data was fairly unhelpful, since Recast would try to size the grid of voxels based on the triangles input at the buildPolyList stage.
It's easy enough to fix this in either the Recast-intermediate classes (by adding lots of special cases for objects like GroundPlanes, though TerrainBlocks have no workaround for this, IIRC), or, as I did in Walkabout, by adding a new PolyListContext hint and adding custom code to buildPolyList when this hint was given. I.e.,
What I want to discuss here is: should this problem be fixed in general? I.e., is it more desirable for these classes to return data that fits entirely within the bounds? Or should this be edge-case behavior that is only used when it's really necessary?
There are ways around it for specific cases like Recast integration, but I feel it's a more general issue.
EDIT: Sorry, forgot that the method was buildPolyList, not buildConvex. Dumb mistake, but the question still stands!
This is often fine for collision purposes, because having too much information isn't usually a problem. However, when integrating Recast, I found the data was fairly unhelpful, since Recast would try to size the grid of voxels based on the triangles input at the buildPolyList stage.
It's easy enough to fix this in either the Recast-intermediate classes (by adding lots of special cases for objects like GroundPlanes, though TerrainBlocks have no workaround for this, IIRC), or, as I did in Walkabout, by adding a new PolyListContext hint and adding custom code to buildPolyList when this hint was given. I.e.,
void GroundPlane::buildPolyList(PolyListContext context, ...)
{
if(context == PLC_Navigation)
{
// Add a plane that fits the bounds given
}
// Stock code:
// Add a massive plane!
}What I want to discuss here is: should this problem be fixed in general? I.e., is it more desirable for these classes to return data that fits entirely within the bounds? Or should this be edge-case behavior that is only used when it's really necessary?
There are ways around it for specific cases like Recast integration, but I feel it's a more general issue.
EDIT: Sorry, forgot that the method was buildPolyList, not buildConvex. Dumb mistake, but the question still stands!
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!