edit: I just located the CameraNode class, which obviates this to a degree, but a quick answer would be informative anyway…
I’m trying to work with the Camera and finding it ornery.
Why is the camera not a spatial so it can be manipulated as other similar objects are?
Looking at this code in FlyByCamera…
protected void rotateCamera(float value, Vector3f axis){
(snip)
Quaternion q = new Quaternion();
q.fromAxes(left, up, dir); // is this mathematically equivalent to right, up, back (x, y, z)?
q.normalize();
cam.setAxes(q);
}
Is handing left, up and forward (-x, y, -z) in to a function that expects x, y, and z mathematically equivalent?
Thanks in advance.
tone
The camera is the representation of where a viewport is looking. It’s not a real physical item and thus cannot be manipulated as spatials are. Because of this it does not fit in with the object hierarchy that is a Node or Spatial.
CameraNode lets you have a CameraControl that will get updated every frame in the update loop. It lets you manipulate the camera from that. This is useful for having a flying camera that moves without human interaction.
Jme is split into Spatials and Controls. The spatials do not update each frame, they rely on Controls to do that.
I’m finding the JME3 Camera/CameraNode counter-intuitive and perhaps more complex than required.
Two aspects of the design and its presentation in tutorials seem problematic to a new user:
- Do any benefits arise from having a camera that answers to an entirely different paradigm of positioning and orientation than every other transformed entity on the scene graph? If any do, are they perhaps minor ones that should be marginalized to simplify this? That is, I’d argue that the CameraNode should at least be emphasized in tutorials, if not that its functionality (primarily, that is derived from Spatial) should be made intrinsic to Camera.
- Second, the default behavior for a CameraNode is that the camera’s positioning and orientation should drive the CameraNode, rather than vice-versa. Conformant to my suggestion above, this should be the opposite.
I’m trying to figure out who wouldn’t want to merge camera and spatial handling into a homogenous skillset/toolset, and that the Spatial base class is the proper rallying point (given the relative superior numbers of Spatials to Cameras in any application).
tone
I was not involved in the design decision though I think it is the right one. These are just my thoughts on the subject having dealt with both types of systems in the past…
There are any number of reasons why having a camera forced into a node in the scene is problematic. Not the least of which is that it is viewing the scene that it is in. But specifically there are several considerations.
- Given that a scene is a tree starting a root node organized spatially for its own reasons, it is difficult to see where, logically, a camera node fits in this case. Is it in the root? Is it in some other spatially organized node and then is moved from one child to another as it moves around? A camera is not part of the scene… it is viewing the scene.
- A scene can be casually made up of multiple root nodes. This sort of extends the problem above. A single camera can be the positioning in multiple viewports… each with their own node hierarchy.
- It is also very common to have the camera at a fixed location and move the scene around it. This is what Mythruna does… and probably any system that allows free roaming over a large paged world. The camera cannot be part of the scene in this case without lots of extra work.
The common them through this is that the camera is used to view the scene. It is not part of the scene itself.
There are cases (many) where you want the position and orientation of the camera to have a representative object in the scene. And a CameraNode is one way to handle that case, I guess. (I’ve never used it.) However, even in that case it would be common to disassociate the camera from its node to move from first person to third person perspective, etc…
In those cases where you want some Spatial to inform the position of the camera itself, this is not hard to do at the application or app state level. It’s just that your control scheme for the node will be completely different… and it would have to be anyway because you are no longer moving some simple outside the scene thing but you are translating input into something that can be applied to an object that is potentially a child of a child of a child. It’s doable… it’s just something that can’t be defined in an easily general way without limiting options.
Though, my reading of CameraNode docs say that’s exactly what it’s doing. It takes the world transformation of the camera node and applies it to the linked Camera. Not the other way around. You’d still have to figure out how to map inputs to the CameraNode.