Collision bug on trees
by Duion · in Torque 3D Beginner · 12/12/2012 (4:56 pm) · 31 replies
Recently i noticed, that there is a bug in tree collisions, it behaves weird, you can walk up trees or you get stuck, sometimes permanently.
Any ideas what this could be? Collision mesh is properly set up and the bug is with all trees, even the default tree that comes with torque 3d, the default tree is not that bugged, cause it has a very simple collision mesh, but if you run at it against the positive y-axis you walk vertically into the air untill you are on top of the tree.
Any ideas what this could be? Collision mesh is properly set up and the bug is with all trees, even the default tree that comes with torque 3d, the default tree is not that bugged, cause it has a very simple collision mesh, but if you run at it against the positive y-axis you walk vertically into the air untill you are on top of the tree.
About the author
http://www.duion.com - Human Paradigm Specialist
#22
04/11/2013 (10:13 am)
Oh great! So you set it once in the manually placed one and then maybe leave it under the terrain or something?
#23
Michael,
You're not the first to run into that. When you create a forest, you have to first load up just a single mesh of each tree. There is a little check box in the mesh inspector window called player step. Its located in the collision section. Make sure that is NOT checked. This way you tell the game that this mesh has collision, but you do not want your player to walk on it.
Hope that helps
Ron
-EDIT Doh just realised he was the first to reply to this thread!
04/11/2013 (10:32 am)
Ron just also confirmed this in an email:Michael,
You're not the first to run into that. When you create a forest, you have to first load up just a single mesh of each tree. There is a little check box in the mesh inspector window called player step. Its located in the collision section. Make sure that is NOT checked. This way you tell the game that this mesh has collision, but you do not want your player to walk on it.
Hope that helps
Ron
-EDIT Doh just realised he was the first to reply to this thread!
#24
04/11/2013 (10:41 am)
Hmm yes, it is still happening with a fresh forest after adding all these meshes with those settings
#25
04/11/2013 (11:25 am)
Does anyone have the Torque 1.0 version of this area on player.cpp to see what was changed?while (pList != &rList) {
Convex* pConvex = pList->mConvex;
// Alright, here's the deal... a polysoup mesh really needs to be
// designed with stepping in mind. If there are too many smallish polygons
// the stepping system here gets confused and allows you to run up walls
// or on the edges/seams of meshes.
TSStatic *st = dynamic_cast<TSStatic *> (pConvex->getObject());
bool skip = false;
if (st && !st->allowPlayerStep())
skip = true;
if ((pConvex->getObject()->getTypeMask() & StaticObjectType) != 0 && !skip)
{
Box3F convexBox = pConvex->getBoundingBox();
if (box.isOverlapped(convexBox))
pConvex->getPolyList(&polyList);
}
pList = pList->wLink.mNext;
}
#26
04/11/2013 (11:57 am)
From Torque 3D 2009 SDK 1.0while (pList != &rList) {
Convex* pConvex = pList->mConvex;
// Alright, here's the deal... a polysoup mesh really needs to be
// designed with stepping in mind. If there are too many smallish polygons
// the stepping system here gets confused and allows you to run up walls
// or on the edges/seams of meshes.
TSStatic *st = dynamic_cast<TSStatic *> (pConvex->getObject());
bool skip = false;
if (st && !st->allowPlayerStep())
skip = true;
if ((pConvex->getObject()->getType() & StaticObjectType) != 0 && !skip)
{
Box3F convexBox = pConvex->getBoundingBox();
if (box.isOverlapped(convexBox))
pConvex->getPolyList(&polyList);
}
pList = pList->wLink.mNext;
}
#27
04/11/2013 (12:00 pm)
Here is the entire Player::stepbool Player::step(Point3F *pos,F32 *maxStep,F32 time)
{
const Point3F& scale = getScale();
Box3F box;
VectorF offset = mVelocity * time;
box.minExtents = mObjBox.minExtents + offset + *pos;
box.maxExtents = mObjBox.maxExtents + offset + *pos;
box.maxExtents.z += mDataBlock->maxStepHeight * scale.z + sMinFaceDistance;
SphereF sphere;
sphere.center = (box.minExtents + box.maxExtents) * 0.5f;
VectorF bv = box.maxExtents - sphere.center;
sphere.radius = bv.len();
ClippedPolyList polyList;
polyList.mPlaneList.clear();
polyList.mNormal.set(0.0f, 0.0f, 0.0f);
polyList.mPlaneList.setSize(6);
polyList.mPlaneList[0].set(box.minExtents,VectorF(-1.0f, 0.0f, 0.0f));
polyList.mPlaneList[1].set(box.maxExtents,VectorF(0.0f, 1.0f, 0.0f));
polyList.mPlaneList[2].set(box.maxExtents,VectorF(1.0f, 0.0f, 0.0f));
polyList.mPlaneList[3].set(box.minExtents,VectorF(0.0f, -1.0f, 0.0f));
polyList.mPlaneList[4].set(box.minExtents,VectorF(0.0f, 0.0f, -1.0f));
polyList.mPlaneList[5].set(box.maxExtents,VectorF(0.0f, 0.0f, 1.0f));
CollisionWorkingList& rList = mConvex.getWorkingList();
CollisionWorkingList* pList = rList.wLink.mNext;
while (pList != &rList) {
Convex* pConvex = pList->mConvex;
// Alright, here's the deal... a polysoup mesh really needs to be
// designed with stepping in mind. If there are too many smallish polygons
// the stepping system here gets confused and allows you to run up walls
// or on the edges/seams of meshes.
TSStatic *st = dynamic_cast<TSStatic *> (pConvex->getObject());
bool skip = false;
if (st && !st->allowPlayerStep())
skip = true;
if ((pConvex->getObject()->getType() & StaticObjectType) != 0 && !skip)
{
Box3F convexBox = pConvex->getBoundingBox();
if (box.isOverlapped(convexBox))
pConvex->getPolyList(&polyList);
}
pList = pList->wLink.mNext;
}
// Find max step height
F32 stepHeight = pos->z - sMinFaceDistance;
U32* vp = polyList.mIndexList.begin();
U32* ep = polyList.mIndexList.end();
for (; vp != ep; vp++) {
F32 h = polyList.mVertexList[*vp].point.z + sMinFaceDistance;
if (h > stepHeight)
stepHeight = h;
}
F32 step = stepHeight - pos->z;
if (stepHeight > pos->z && step < *maxStep) {
// Go ahead and step
pos->z = stepHeight;
*maxStep -= step;
return true;
}
return false;
}
#29
04/11/2013 (1:43 pm)
This is terribly naughty but i added a check to the allowplayerstep check in player.cpp to make all forest items allowstep falseif ((st && !st->allowPlayerStep()) || pConvex->getType() == ForestConvexType)
skip = true;
#30
@Michael; Indeed a bit too naughty if you use the ForestEditor for more then only trees :)
04/13/2013 (10:50 am)
@Duion; If the top side of the collision box is a few percent larger then the bottom so it's just passing the 180 degrees then my player doesn't run up to trees anymore. The example I posted has a bit exaggerated conical shape (I'm making an adventure game); So, you can still make the shape fit pretty accurate for your shooter.@Michael; Indeed a bit too naughty if you use the ForestEditor for more then only trees :)
#31
Making the top bigger is not always a solution, since sometimes you have trees that have a big bottom and get thinner to the top, which is also the common way trees grow, so in same cases even the same size at the top than at the bottom is too much.
I hope for a better solution than rebuilding all trees.
04/13/2013 (11:12 am)
The opposite can work also, if you make the bottom larger, you also can not walk up, but it does not have to be a continuous mesh, you need more segments.Making the top bigger is not always a solution, since sometimes you have trees that have a big bottom and get thinner to the top, which is also the common way trees grow, so in same cases even the same size at the top than at the bottom is too much.
I hope for a better solution than rebuilding all trees.
Duion
Not nice solution, collision has to be pretty exact like the trunk shape, at least for a shooter like game, since players want to shoot through where they can see through, or imagine someone wants to throw a grenade closely alongside the tree trunk or over it and it bounces back because of an invisible oversized collisionmesh.
@Micheal
No, not in the forest editor, in the shape editor. So first add the tree as shape, uncheck allow player step, then delete, but this solution does not work since the new version, but with version 1.0 it seemed to work this way, but now the bug is back.