3rd Person camera collision

#1 *bump* This problem is really frustrating me :/

#2 This little problem is causing me alot of headaches. I am willing to put a bounty on this one if someone wants to look into it. Ill send you paypal if you can figure this one out! Thanks

#3 Hmmmm i think i know the answer to this. let me check the code.

#4

void Camera::validateEyePoint(F32 pos, MatrixF *mat)
{
   if (pos != 0) {
      // Use the eye transform to orient the camera
      Point3F dir;
      mat->getColumn(1, &dir);
      pos *= mMaxOrbitDist - mMinOrbitDist;
      // Use the camera node's pos.
      Point3F startPos;
      Point3F endPos;
      mObjToWorld.getColumn(3,&startPos);

      // Make sure we don't extend the camera into anything solid
      if(mOrbitObject)
         mOrbitObject->disableCollision();
      disableCollision();
      RayInfo collision;
      U32 mask = TerrainObjectType |
                 InteriorObjectType |
                 WaterObjectType |
                 StaticShapeObjectType |
                 PlayerObjectType |
                 ItemObjectType |
                 VehicleObjectType;

in camera.cc the Mask there more then likely is what you wanna edit.
I can't check and make sure right now, but you might wanna try there.

#5 It's quite simple in concept really. Player is derived from Shapbase. You need to override the ShapeBase::getCameraTransform method, so just copy the one from shapebase and add it to the player class. Now in the overriden method, look for the castray function call and remove from the collision mask, anything you dont want the camera to collide with.

The problem is that it may now happen that the camera may sometimes be placed inside another player because it now does not know the player exists.

#6 The solution to the above problem is to add a second castray which only looks for player objects and then does something clever with the camera if it collides with another player, like move it up a few meters but still aim it at the player who owns the camera.

#7 Just an idea.

To solve the problem you may have with completely opaque players between the camera and the player you might want to swap out textures according to how close the character object is to the camera. LIke this resource talks about http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7007

The idea being when a player is within a certain distance from the camera put a texture on him that is the same only with an alpha channel in it.

#8 @ Affectworks, I think that would look REALLY nice if done right. Peter would still need to modify the

getCameraTransform method to detect when to change textures.

#9 @Peter, I have not fully researched the following due to lack of time, but the concept of turning obstructing players semi transparent should look quite nice. I'd say make them about 70% transparent.

I have not looked at that resource but you should not need to use it as the engine already has a method called setSkinName which you use to change skins.

Steps...

(1) prefix your existing skin name with "base." i.e. base.myplayer_skinTexture
(2) create another skin with an alpha channel at 70% transparent, name it base.myplayer_skin_semitransparent etc
(3) re-export your player characters with the texture names updated as above
(4) add an overridden getCameraTransform method to the player class
(5) locate the cast ray and remove player objects from the collision mask
(6) add another castray function AFTER the old one with only player objects in the collision mask
(7) the new castray should cast from the updated camera position to the player location
(8) if it detects a player object, call setSkinName("myplayer_skin_semitransparent ") on that player object
(9) if it detected a player, you will need to cast another ray from that player location to your player in case there are several players between the camera and the camera owner


That should do it.

#10 Thank you Duncan!! getCameraTransform was the function I have been searching for. I updated the collision mask and its working perfectly.

#11 @ Peter, as shapebase is the parent of many things besides the player class, it would be safer to make your changes in an overridden player method rather than changing it in shapebase.

#12

Quote:@ Peter, as shapebase is the parent of many things besides the player class, it would be safer to make your changes in an overridden player method rather than changing it in shapebase.

I just wanted to add that that is extremely good advice. Matt Fairfax I think wrote somewhere (thread, FAQ, resource, not really sure!) just how "fat" ShapeBase is--and that's because so many objects use it.

As Duncan suggests, it's almost never the best solution to change something in ShapeBase without fully understanding all of the implications for derived classes--instead, you should reimplement in an overriding child method.