Game Development Community

Mounting with mountPoint node

by Daniel Buckmaster · in Torque Game Engine · 06/17/2007 (12:09 am) · 9 replies

The above is not a feature that comes with shapeBase-derived classes by default, so I decided to add it to a custom class I've written, Pickup. I just had a look in shapeBaseImage to see how it was handled there. It seemed to be using a matrix mountTransform that would hold the transform to get to the mount point from the object's centre. So I realy just copied the image code to my own class (based off Item). Here are the changes:

in PickupData::PickupData
mountTransform.identity();
Just initialising the matrix.

in PickupData::Preload
S32 node = shape->findNode("mountPoint"); //Find mountPoint node
   if (node != -1) {
      MatrixF total(1);
      do {
         MatrixF nmat;
         QuatF q;
         TSTransform::setMatrix(shape->defaultRotations[node].getQuatF(&q),shape->defaultTranslations[node],&nmat);
         total.mul(nmat);
         node = shape->nodes[node].parentIndex;
      }
      while(node != -1);
      total.inverse();
      mountTransform.mul(total);
   }
Copied the code from shapeBaseImage preload to find the mountPoint node.

in Pickup::registerLights
Point3F mountOffset;
   mDataBlock->mountTransform.getColumn(3,&mountOffset);
   mLight.mPos = getBoxCenter() + mountOffset;
Originally this read 'mLight.mPos = getBoxCenter();'

in Pickup::ProcessTick
if(isMounted())
   {
	  MatrixF mat;
      mMount.object->getMountTransform(mMount.node,&mat);
      mat.mul(mat,mDataBlock->mountTransform);
      Parent::setTransform(mat);
      Parent::setRenderTransform(mat);
   }
This if-clause was already there - mat.mul was all I added.

in Pickup::interpolateTick
if (isMounted()) {
      MatrixF mat;
      mMount.object->getRenderMountTransform(mMount.node,&mat);
      mat.mul(mat,mDataBlock->mountTransform);
      Parent::setRenderTransform(mat);
   }
Again, just added mat.mul.

Now, this code does work - however, the object is being mounted on a point that's twice as far away from the shape's origin as it's mountPoint should be. Here's a visual aid:
img137.imageshack.us/img137/3245/korkwithlasgunjv0.pngThe red/green dot is Kork's mount0 point, where it should be mounted. Red/blue is the weapon's mountPoint node. Red/red is the weapon's origin (roughly).
I've tested with a normal shapeImage, and the mountPoint works as normal there. So what have I done wrong?

About the author

Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!


#1
06/20/2007 (7:23 am)
I've also found some different problem - when the object is mounted, it seems to lag behind the animation of its holder by a small amount. It isn't really a major issue, but it looks strange on close inspection. I guess this could be something to do with pack/unpackUpdate?
#2
06/20/2007 (7:48 am)
Amazing coincidence. I had this exact same problem when making a default weapon class (been working on it for a few weeks now).

I got so frustrated with the bugged-offset of the mountpoint and mount0, that I switched over to a pure AFX solution that solved all of my problems.

I'm interested in seeing the solution to this problem from a TGE standpoint. Good work so far, and I'll let you know if I figure anything out.
#3
06/20/2007 (7:50 am)
@Daniel: I noticed the same problem about animation lag and posted this thread about it not too long ago. No solutions yet, though.
#4
06/20/2007 (10:52 pm)
Huh. Sounds like there's definately something special in the ShapeImage class. I'll look into it, but I doubt I'll find anything good :P. Did you use mountPoint for your object, or just the origin? I may have to just use the origin on my models. mountPoints would be so much nicer, though. Maybe.

Quote: got so frustrated with the bugged-offset of the mountpoint and mount0, that I switched over to a pure AFX solution that solved all of my problems.
AFX?

EDIT: I'm thinking processAfter might be something to look into, but I thought this happened automatically when mounting?
#5
06/21/2007 (4:48 am)
@Daniel -

Arcane FX Tech For Torque

afxWeapon Blog #1

afxWeapon Blog #2

I was making a base weapon class, so I was going to derive off ShapeBase...but that didn't allow mounting of weapons (ShapeBaseData). There were a few other problems I started to encounter, so I scrapped the weapon class and started over. Using AFX makes any kind of effect (explosions, magic, blood spray, mounting of weapons and armor), much simpler to script out and implement.
#6
06/21/2007 (5:12 am)
Don't give up. I can't help you directly, but I remember having the same issue but I managed to fix it.
#7
06/22/2007 (9:40 am)
Not giving up just yet ;). This is a really critical bit of coding for me, because this class is what everything that needs to be held (weapons, mainly) will be based on. Sort of important that they mount properly :P.

Ah, I have heard of AFX - I just didn't know it did such a range of things, I thought it was just particles. It looks pretty dandy, but I've heard that there have been problems with it and the TMK interacting.

Quote: was making a base weapon class, so I was going to derive off ShapeBase...but that didn't allow mounting of weapons (ShapeBaseData).
My class is basically a copy of Item with some functionality removed and some added. Among the planned changes is to implement RigidShape-style physics. That should be fun...
#8
06/22/2007 (4:06 pm)
@Daniel & Rubes, I wish you success! That little lag drives me bats, and it gets uglier with larger scale stuff.

I'm no coder (not a competent one anyway) and my trial-and-error attempts to address it (adding calls to animate(), setmaskbits, get/settransform & rendertransform all over the place) haven't paid off. All I know for sure is that it gets worse when running a Debug build.
#9
06/22/2007 (4:12 pm)
@Joe: Thanks, it drives me nuts, too. I think the mounting system utilized by AFX might take care of it, as long as mounted objects can retain their collision meshes...and I think they can, with the latest stuff Jeff has done. It will be a little bit before I know for sure, since I'll have to make some major code changes to incorporate it all.