TestWalkingChar questions

Hello everyone.

I was playing around with the code for TestWalkingChar.java and have the following questions:

  1. I was trying to implement a third person camera so that the view of the camera follows the direction the model is facing. I tried to use the code from the tutorial “making the camera follow a third person character”. All I ever get from transplanting that code was a camera that is fixed on the spot. Is there a better way of doing this? I just want the camera to be like the ones in third person games like Assassin’s Creed or Tomb Raider, ie over the head of the hero/heroine and turn to where they are looking.

  2. Whenever I use the mouse to change the direction of the camera, then tried to fire a shot of the nifty plasma cannon, the direction of the cannon round is in the direction of the camera. That is if my camera is looking at the ground, it is shooting the round directly in front of the model. Is there a way to decouple the shot direction from the camera direction and make it fire along the direction the model is facing?

    I have played around with all the functions inside the code and getting nowhere. I have scoured the documentation and have been unable to find the answer. Thank you for any help in advance.

    This engine rocks and have good potential.


A possible solution is attaching the same CharacterControl to camera and the model and defining the space between them.

In Hello Collision example you have some code to attach the control to camera.

Try doing the tutorials first and then modifying the example code.

Thanks harton,

I went through the tutorials with a fine tooth comb and was munching my way through the jme3 test tutorials.

I was playing around with several, including TestWalkingChar and TestHoverTank (being the impatient type) amongst others.

I know the answer to my questions is somewhere in one of these tutorials as the beginning tutorials would be too simple.

Little did I know that the answer to the first question is in Hello Collision as you pointed out. The magic line is:


I modified this line to:

Vector3f cameralocation = player.getPhysicsLocation();

float x, y, z;

x = cameralocation.x;

y = cameralocation.y + 4;

z = cameralocation.z -3;

cameralocation.set(x, y, z);


A very amateurish and treasonous mod as most programmers are loath to use more than one line for any solution. Must be a hangover from the imbedded programming era when you get magic lines like “while(getc(sprintf(x = a + b sin(m)/t)) = dosweetfa()) { selfdestruct() }”

The above code enabled me to relocated the camera back and above the ‘character’. I’m sure you can do it a better way, but for now, to avoid cranial overload, it will suffice.

Now I am trying to breakdown TestHovertank. In this demo a groovy tank fires in a somewhat straight line whilst the camera is looking down on the tank, ala RTS games. I’ll figure it out from there and post my ‘findings’.

if anyone has a snappy one liner like harton (thanks again) for this, please feel free to drop one here and help out a noob. Many thanks.

Now to find the class/functions documentation…

I don’t understand what do you want. Do you want a fix third person camera like max payne? Or do you want a fix third person camera but when you move the mouse up and down the character (or tank) don’t change the direction of the weapon?


However that’s still not going to work as you are always moving the z back 3…which means if the player turns to face left you will now be offset in the wrong direction.

I solved this by adding one additional geometry to the player node, called ‘geoViewersEye’. Then, the camera is attached to this geometry (position and rotation):

[java]public void updateCamera()


// Position and rotate the camera to the location and rotation of the viewers eye:




In the game update loop, there is call to updateCamera(), so the camera will keep following the player. This camera is fixed to the player and can be freely rotated (by rotating the geometry, you need to write a function for that which is triggered in the AnalogListener, see below for an example). When the player rotates or moves, the camera will remain in the same position relative to the player.

Using this geometry geoViewersEye saves you from some mathematical calculations :slight_smile: and it is not interfering with anything the player character does.

Function to rotate the camera’s geometry:

[java]public void RotateCamera(float value, boolean pitch)


if( pitch )


camPitch += value;




camYaw += value;


camRotator.fromAngles(camPitch, camYaw, 0);



Example of AnalogListerner to rotate the camera:

[java]private AnalogListener analogListener = new AnalogListener()


public void onAnalog(String name, float value, float tpf)


if (name.equals(“View Up”) && mouseLook == true)


RotateCamera(value, true);


if (name.equals(“View Down”) && mouseLook == true)


RotateCamera(-value, true);


if (name.equals(“View Left”) && mouseLook == true)


RotateCamera(value, false);


if (name.equals(“View Right”) && mouseLook == true)


RotateCamera(-value, false);




Doing it like this, you can also very easily implement the possibility to move the camera around when you press some keys.

You don’t need the geometry. Do something like:

[java]private static final Vector3f CAMERA_OFFSET = new Vector3f(0,0,3);

cam.setLocation(myShip.getWorldTransform().transformVector(CAMERA_OFFSET, null));



(This code assumes that myShip is also the node…if not then you’d need to query the node from the ship).

By attaching the geometry you’re adding extra work to all the scene processing when all you really need is the above.

Hello Folks

Harton, you are correct I want the camera to behave ala Max Payne. The code I used I originally tried in the HelloCollision tutorial. It appeared to work. When I patched this in the TestWalkChar, it produced the funny behaviour zarch pointed out.

I am now trying out husky’s and zarch’s suggestions in the TestWalkChar sample. They should work fine this time.

Thank you very much guys. I have a very long way to go when it comes to coming to grips with this engine.

@zarch: If I set the CullHint to ‘always’, wouldn’t this prevent the geometry to consume resources?

I have tried your proposal, but this gives some weird results when the character is starting to turn around its 3 axis (could be I have implemented it faultly, though…).

@husky said:
@zarch: If I set the CullHint to 'always', wouldn't this prevent the geometry to consume resources?

Honestly I'm not sure how many resources will be consumed in that situation but it will still be some. At the very least it needs to process the geometry and discover that it is always culled. Someone more knowledge than me of JME3 internals would be able to say if it's a problem.

As far as I know all that the game does with the geometry is apply the world transform onto the co-ordinates within it .... so I don't see why you would get strange results.