Game Development Community

castRay collisions with rotated static shapes and the normals

by Stefan Beffy Moises · in Torque Game Engine · 01/18/2003 (7:55 am) · 9 replies

I've encountered some strange phenomena with the collisions of e.g. projectiles with static shapes...
I've got breakable glass implemented as a StaticShape object, and I am using the "bullethole" resource to apply decals to the glass if I shoot at it... works great as long as the glass objects are in their original orientation...
Now if I rotate the "windows" along the z-axis and shoot at them, the decals STILL are applied as if they were NOT rotated...
so the decals are facing the wrong direction :/
But I don't know if it is a general problem with castRay... my guess is that the normal of the hitobject returned by the castRay function is somehow wrong...
if (getContainer()->castRay(oldPosition, newPosition,
                                  csmDynamicCollisionMask | csmStaticCollisionMask,
                                  &rInfo) == true)
...
onCollision(rInfo.point, rInfo.normal, rInfo.object);
but I've got no idea where to start looking and why the heck it works if the shape isn't rotated... :(
any ideas? did anybody else ever have problem with rotated shapes and collisions?
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Associate Stefan Beffy Moises
#1
01/18/2003 (11:14 am)
Btw., I've just tried in Debug build and enabled the boundingBox rendering with 
$GameBase::boundingBox=1;
(nice little feature btw.), and the bounding box seems to rotate with the shape... so I really don't have the slightest idea why this projectile/decal anomality would happen... but it does... :/
Thanks for any hint!!

Torque Owner Max Robinson
#2
01/20/2003 (1:44 pm)
Try doing some console output of the normals, and see if its the same before and after rotation.

To me, it seems like the decal manager would be the problem more than the raycasting...

Since the object obviously rotates, it doesnt seem like its a client/server problem...

Associate Kyle Carter
#3
01/20/2003 (3:32 pm)
Maybe the normal the castray function returns is the normal before rotation. IE, the code that gets the normal isn't taking into account the rotation of the object.

Associate Stefan Beffy Moises
#4
01/20/2003 (11:06 pm)
Ben seems to be on the right track...
the problem seems to be the castRay, cause the decal manager is getting the same normal for every object, independent of its rotation...
I have tried to different static shapes, one rotated, and one in the original rotation, and for both I am getting:
mFabs(normal.x) mFabs(normal.y) mFabs(normal.z) 0.000000 - 1.000000 - 0.000000
I am outputting that before the decal manager does anything to the normal, so it seems to happen in projectile.cc...
newDecal->allocTime = Platform::getVirtualMilliseconds();
   
   Con::errorf("mFabs(normal.x) mFabs(normal.y) mFabs(normal.z) %f - %f - %f", mFabs(normal.x),mFabs(normal.y),mFabs(normal.z));
   if(mFabs(normal.z) > 0.9f)
      ...

Doh! could it be that the col box of the glass shapes itself is invalid and that causes this "normal" problem:
Quote:
Warning: shape projectca/data/shapes/glass/tinted_glass.dts collision detail 0 (Collision-4) bounds exceed that of shape.
....
gotta check that... :P

Associate Stefan Beffy Moises
#5
01/21/2003 (12:48 am)
Hm, no! :(
Even if I fix that collision errors, I get a normal of
0.000000 - 1.000000 - 0.000000
for every "glass" StaticShape (works fine for TSShapes, e.g. the trees), no matter how they are oriented...
Could anyone please verify this? thx...! :D

Associate Kyle Carter
#6
01/21/2003 (3:54 am)
Maybe check around line 1654 of engine\ts\tsMesh.cc. That's where the "real" castray functionality seems to live.

In fact, yup, line 1776:

rayInfo->normal   = planeNormals[curPlane];

You're going to want to apply a transformation to that normal to make it reflect (rotated) reality.

Associate Stefan Beffy Moises
#7
01/21/2003 (4:40 am)
The strange thing is, though, if I use a RW tree dts instead of my planar glass.dts, it works and returns correct normals...
So either my glass shape is missing something (although I triple-checked it at least...) OR castRay is screwing up if it deals with planar, box-type objects...?

Associate Kyle Carter
#8
01/21/2003 (6:31 am)
You might check to see that the same code is being called for the tree and the glass shape. The castRay function uses object-type specific code, so that it can support querying the terrain, interiors, shapes, etc.

It could be that the tree is using slightly different code or somesuch. Failing that, check the code that's generating the normals - it looks like the normal castray is returning is from some runtime generate data structure.

Associate Stefan Beffy Moises
#9
01/21/2003 (6:34 am)
Hm, really should be the same code... all I did is changing the path to the shapefile in my "Window" datablock... so both are "StaticShapes"...
heck, I simply don't get it... :(