Game Development Community

Explosions dissappearing in portal'd areas

by Eric Hartman · in Torque Game Engine · 02/27/2005 (10:06 pm) · 4 replies

When you're in a portal'd interior and you shoot at the floor, the explosion will often not be rendered. It seems to be because the explosion is too close to the edge of the interior and the engine thinks it is outside the portal.
I got around it by adjusting the projectile's explosion along the contact normal a tiny bit:
void Projectile::processTick(const Move* move)
{

...

if (getContainer()->castRay(oldPosition, newPosition, csmDynamicCollisionMask | csmStaticCollisionMask, &rInfo) == true)
   {
      // make sure the client knows to bounce
         if(isServerObject() && (rInfo.object->getType() & csmStaticCollisionMask) == 0)
            setMaskBits(BounceMask);

         // Next order of business: do we explode on this hit?
      if(mCurrTick > mDataBlock->armingDelay)
      {

...

            [b]rInfo.point += rInfo.normal * 0.01;[/b]
            onCollision(rInfo.point, rInfo.normal, rInfo.object);
            explode(rInfo.point, rInfo.normal, objectType );

...
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque 3D Owner Robert Blanchet Jr.
#1
02/28/2005 (1:10 am)
Ah, nice find. I've actually known about this problem for awhile now through my work with Legends. I believe Tribes 2 got around this problem by doing the very same thing you do, by fudging with the position. It's too bad there isn't a more elegant way of doing this.

Also, this not only happens when your inside an interior but also outside, usually with thin walled interiors if a projectile collides on a wall sometimes it will seemingly disappear.

Torque 3D Owner Robert Blanchet Jr.
#2
02/28/2005 (1:15 am)
I just got to thinking. Perhaps the castRay or even collisions in general are bugged. Seems to be that if it detects a collision like this that it should be using the position and normal of the surface collided with. While it may be using the normal of the surface I'm starting to wonder if it's using the position of the object colliding and not the object collided with, ie the surface.

Because if it was using the surface position then why would this type of error even occur? Something to investigate further I suppose.

Torque Owner Gonzo T. Clown
#3
02/28/2005 (2:10 am)
The modification you are making is already being made for you. And yes, it would appear there are two different positioning methods being used. In "void Projectile::explode", the server adjusts the position exactly as you did via...

mExplosionPosition = p + (n*0.01);

Which has the same effect as your modification does. But for some reason, the client explosion does NOT get adjusted and is simply rendered on the original position via...

xform.setPosition(p);

So it would appear that the best way to fix this would be to simply adjust the client as well like this...

xform.setPosition(p + (n*0.01));


I wish I knew how you created your problem so I could test this fix out. If you can force the disappearing explosions somehow, would you mind testing this change instead to see if it will work correctly? You said "the explosion will often not be rendered", and I have a sneaky suspicion that it's because the client explosion position was not matching the server position as shown above.

Torque Owner Eric Hartman
#4
03/01/2005 (2:15 pm)
@Gonzo: That change works, but the relevant line is 
pExplosion->setInitialState(p, n);
As far as i can tell the lines:
MatrixF xform(true);
xform.setPosition(p);
pExplosion->setTransform(xform)
dont actually do anything, or if they do anything, it is overridden by the call to setInitialState()