I was playing around with the code for TestWalkingChar.java and have the following questions:
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.
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.
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.
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 and it is not interfering with anything the player character does.
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.