Game Development Community

Torque 3D Beta 1 Bug - TerrainBlock square collision with neg. z coords (FIX)

by Konrad Kiss · in Torque 3D Professional · 05/06/2009 (12:04 pm) · 8 replies

Update: there's only one real bug here:

Negative z coords break collision. You can reproduce this by sinking some of a TerrainBlock's squares below 0 z (world space). Collision on the sunk squares will not work, and the player will fall through the terrain.

Original post:
Quote:
Together with bank and Michael Hall we have uncovered a hideous one.

Negative coordinates of terrain squares cause a number of problems. Many functions assume that all 3 coordinates of every vertex of the terrain are positive.

When using a negative coord (x or y coord), certain functions will misbehave such as any TerrainBlock::getNormal and other similar functions, or the TerrainSquare::findSquare function. The later accepts U32 coords only.

Concerning negative z coords, that one breaks collision when below 0. You can reproduce this by sinking some of a TerrainBlock's squares below 0 z. Collision on the sunk squares will not work, and the player will fall through the terrain.

We saw that all existing terrains in the beta have that negative offset. Only newly created terrains will have xy coords above 0.
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Tom Spilman
Sickhead Games
#1
05/06/2009 (3:30 pm)
Quote:Negative coordinates of terrain squares cause a number of problems.

Realise that terrain internally is in its own U32 based object space. Nothing in that space should ever be negative... ever.

One thing that is confusing is that its hard to tell if a terrain function is working in world space or object space. There are some hints....

Like if it takes U32/S32s its usually working and returning object space data.

If the function takes F32s or Point3Fs then its probably working in world space.

Its not an oversight that these things take integer or floating point coordinates. Its that way on purpose.

Quote:You can reproduce this by sinking some of a TerrainBlock's squares below 0 z.

Is this in object space or in world space? Specifically you mean from within the terrain editor tools or doing it via code?

Associate Konrad Kiss
Bitgap Games
#2
05/06/2009 (10:56 pm)
I see, so before using getNormal, the TerrainBlock's object space coordinates must be fed to the function instead of its world space coordinates? (which must be the same when the terrain is at 0,0 - that explains it all!)

Give me a little time to test around, but after your explanation, it looks like there's no xy bug after all. I just want to test it first.

That below 0 z is in world space, and I was able to reproduce it in a vanilla FPS Genre Kit through the editor. So that negative z still seems to be a bug.

Associate Tom Spilman
Sickhead Games
#3
05/07/2009 (12:11 am)
Yea... so TerrainBlock::getNormal() is an example of a confusing API. It takes a Point2F, but if you look in the function itself you can see it assumes this is in object space.

I just documented those functions in the header so that hopefully it won't confuse people as much in the future.

Ok... so the bug here is then that moving the terrain below a z of 0 will cause the collision to fail.

Associate Konrad Kiss
Bitgap Games
#4
05/07/2009 (1:55 am)
Yep, I tested with object space coords, and everything seems to be in order. Thank you for your help once again. :)

I'm modifying the title of this thread to better reflect the negative z problem.

Torque 3D Owner Kenneth Holst
Default Studio Name
#5
05/11/2009 (5:08 pm)
Logged as THREED-446

Associate James Ford
Sickhead Games
#6
05/12/2009 (12:59 am)
I have a fix for this issue that worked for me here. If you would like to see if it works for you there, you can change the early out test at the top of TerrainBlock::buildConvex in terrCollision.cpp to look like this:

const Point3F &terrainPos = getPosition();
   if (  box.maxExtents.z - terrainPos.z < -TerrainThickness || 
         box.minExtents.z - terrainPos.z > fixedToFloat( mFile->getMaxHeight() ) )
      return;

Associate Konrad Kiss
Bitgap Games
#7
05/12/2009 (1:43 am)
This works perfectly James, thank you.

There was another issue I reported, and this solves the falling through terrain part there.

Torque 3D Owner Caylo Gypsyblood
#8
05/12/2009 (12:47 pm)
I hammered this fix into TGEA1.8.1, and it works to remove the same type of bug there also.