Questions on coordinate system, etc

I am trying to feather a nest for myself in jME and have a good number of simple questions that may be too obvious for the FAQ but will spare me from a considerable number of experiments (which my neophyte level may lead me to do incorrectly!) to get started.

People more conversant in 3d-speak probably infer these truths from indirect expression (e.g.:  "It uses a right-handed coordinate system").  I don't mind if you toss in such factoids, but please also supply a literal answer in the language prompted for in my way of asking, as this ensures that I "get it".

Handedness:  If we take +Z to be forward, I take it that X is side-to-side and Y is up/down.  If +Y is up, is +X left (or right)?

Rotation: In pitch, is a positive change pointing skyward, or downward?  In yaw, is positive to the left or right?  In roll, is it tipping left or right?

Thanks in advance for helping me put this into language I understand.  Once I know what the underlying truth is, trial and error will help me complete a simple set of functions which I think will promote success in people who (like me) use layperson expressions quite comfortably, and start to quake when shown a quaternion or Euler angle.

Thanks in advance!


If +Z is into the screen (forward), +Y is up, then +X is left. This is, as you said, because it is a right handed coordinate system. That is, if you straighten your fingers on your right hand and point them forward (+Z) and your thumb is facing up (+Y) when you curl your fingers they go to the left (+X).

EDIT: typo fixed.

another way is to point the thumb in the z direction and the fingers in the x direction.  then if you bend your last three fingers they will point in the y direction.  (also see

Thanks … I guess I was used to left-handed systems.  Can you quickly touch on the rotational directions?

I am creating a wrapper around the Node class to provide a very boiled-down interface for those who know terms like left, right, up, down, forward, back, pitch, yaw, and roll, but simply want units they are immediately familiar with (degrees) and have all the directions of rotation be the ones they'd assume knowing nothing about the underpinnings (e.g.:  Up and Right are positive, the way God intended or He wouldn't have made sliders and knobs on our electronic devices which reflected this design choice!).


Heh, well up and right can still be positive (and are in our default settings) in a right handed system.  In that case, Z simply points out of the monitor.

wrt rotations, maybe this link will help get you started on positive/negative rotation values, etc:

        Node n1 = new Node("");
        Node n2 = new Node("");

        n1.setLocalTranslation(new Vector3f(1,1,1));
        n2.setLocalTranslation(new Vector3f(1,1,1));

        System.err.println("node 1 has world Translation = " + n1.getWorldTranslation());
        System.err.println("node 2 has world Translation = " + n2.getWorldTranslation());

This generates the following output:

Jan 11, 2006 4:21:20 PM com.jme.scene.Node <init>
INFO: Node created.
Jan 11, 2006 4:21:20 PM com.jme.scene.Node <init>
INFO: Node created.
Jan 11, 2006 4:21:20 PM com.jme.scene.Node attachChild
INFO: Child () attached to this node ()
node 1 has world Translation = com.jme.math.Vector3f [X=1.0, Y=1.0, Z=1.0]
node 2 has world Translation = com.jme.math.Vector3f [X=1.0, Y=1.0, Z=1.0]

What I don't get is:  why isn't node 2's world translation [X=2.0, Y=2.0, Z=2.0] after all this?
It has a local translation of 1,1,1 on a parent node that in turn has one of 1,1,1.  Should it not have followed its parent through its motion in the n1.setLocalTranslation() call?


Did you call updateGeometricState?

the world transforms are only updated when you call for them to be updated (as mojo points out)  (same with world bounds, final geometry renderstates, etc.)

Many thanks.  No.  I did not know I had to call this function or what things I did which created the need for its use… 

It would be great if the Javadoc alluded to these requirements, say at setLocalTransform() and setLocalRotation().

Even so, I am not finding myself really brought fully up to speed on it as I look at its Javadoc entry:

public void updateGeometricState(float time,
                                 boolean initiator);

    updateGeometricState updates all the geometry information for the node.

        time - the frame time.
        initiator - true if this node started the update process.

If a Spatial's local transform is altered, is this a call which finalizes all such changes and updates the Spatial's world transform?  Does this (on a Node) cause its child Spatials to undergo the same process?  I think perhaps I should get the source for jME again, but would rather see this migrate into documentation (and I'd be willing to help with that if you'd brook it!) , perhaps to bring it to a state more like so:

public void updateGeometricState(float time,
                                 boolean initiator);

    updateGeometricState updates all the geometry information for the node and its children.
    Specifically, any changes made in its local transform (translation and rotation) are applied to
    its world transform when this call is made, providing an optimization if a series of local transforms
    are made before the net change in world transformation must be considered.

        time - the frame time.  (guessing) Plug in the time of the last return value of (something here),
                 or just 0.0f if you are not rendering 3D scenery
        initiator - true if this node started the update process. (Guessing) Use "true" when calling it --
                 "false" is for internal use as the update propagates through the Node's children

One suggestion you may have considered is to use dirty lists and/or dirty bits for objects requiring such treatments.
e.g.: updating a local transform should mark its world transform dirty, and calls which return world transform stuff could detect this and call these "compiler" methods before continuing with their logic.  Similarly, before the next render cycle is called, the engine could itself resolve those from lists of objects requiring the handling.

edit:  thanks for your help.  I am learning, and hope I'm not annoying you with complaints.


The wiki (particularly the user's guide) is being built to support all this. You questions should be answered there, but if they aren't let us know and a section will be beefed up (or written to begin with).