I’m currenctly working on a game and I use collision (on a terrain).
So I used this tutorial which tells us to overwrite the flyCam controls by adding these lines:
[java]
cam.setLocation(player.getPhysicsLocation());
[/java]
(where player is a CharacterControl ).
But now my camera is not smooth, there are some “jerks”.
Does anyone have a better idea of the way to overwrite the flyCam controls?
EDIT: Alright, I tryed to “clean and build” it, I closed blender, photoshop and the SDK(which was using 1.2 GB RAM). Launched it and I got 300fps and no camera problems.
Classically, this kind of lags occur when the framerate drops. Then, you can see that the camera is not updated right.
The reason for this (from my humble experience) is that controls are executed in some specific order, that is very difficult to understand. (Yes, I know they are executed in the order they were added… but there are multiples queues considering controls and appstates.)
Finally, it comes that your control is called too early; next the player location is updated and the camera seems laggy.
All right, this is just my experience. If wrong, please correct me ;-).
All app states are updated… then all controls are updated in “scene graph order”. This order is predictable but generally relying on it is a sign of a bad design.
Also, if you don’t remember the existing fly cam then you will get this issue, I think.
For example I had to build a “tracking camera”, that stays focused on some object whatever their respective moves.
I’ve not found any clean way to achieve this without lags, but tweaking the scene graph until I got the right order.
Any advice on how to make this properly is welcome ;-).
@yang71 said:
For example I had to build a "tracking camera", that stays focused on some object whatever their respective moves.
I've not found any clean way to achieve this without lags, but tweaking the scene graph until I got the right order.
Any advice on how to make this properly is welcome ;-).
Off the top of my head, the camera is managed by an app state. A control is added to the “tracked object” to set the camera position/facing/whatever. That’s presuming that the camera can be switched from one object to another. Or if the camera can accept other input other than from the object.
Otherwise, just a control on the tracked spatial would be fine.
So you add (in last position) a control to the tracked object, so that the object has been updated before sending data to the camera. Very smart !
But I can’t see the role of the camera appState? You said previously that app states are updated before the scene graph. Thus, any "lookAt’ dropped there would be deemed to produce this awful lag.
@yang71 said:
So you add (in last position) a control to the tracked object, so that the object has been updated before sending data to the camera. Very smart !
But I can't see the role of the camera appState? You said previously that app states are updated before the scene graph. Thus, any "lookAt' dropped there would be deemed to produce this awful lag.
The app state would be to hold the camera if there are cases where it is not attached to the object or if you take separate input for the camera then that would be the place to manage the adding/removing of input listeners, etc…
As said, if you have none of those requirements and your camera lives just as long as the node then just add a control.