getWorldTranslation vs updateGeometricstate

Well, I want to know if it is possible to allow some kind od incremental update system here.



Basic problem:

If i have two things doing logic that needs and changes worldposition/rotation then I have to seperate them and call updateGeometricState between them



Example:

Imagine two AI-Soldiers trying to kill each other.

They can move, switch weapons and shoot at each other. (Also they might not be in the rootNode, but in a child, like on a train.



Currently I have to do this:



move()

updateGeometricState() //to apply move

switchweapons() //get the weapon best for the current conditions needs worldposition of enemys

updateGeometricState() //to get the end of the weapon where the bullets come out vfor proper effects

shoot() //needs worldposition of enemys and myself

updateGeometricState()//so the bulletinformations is updated (dodge use shields) for next call to move() needed



//Please not this is only an abstract example, inte4ndet to show you the problem, it might give a better solution here, but that is not the point of my example.





This really sucks to split the logic like this, however I have not found a more eleant solution to this.

So my Idea would be to not calculate the world positions untill a call to getWorldx() it is recived, and then update that part that is needed instantly and cache it till the next call of any setLocalX(). As the above gets more problematic with complexer Logic.

Yes, its filed as an issue in the gc bug tracker, look for “local updates”.

Cheers,

Normen

Localized updates will essentially allow you to access world transform (getWorldlTranslation and friends) without having to call updateGeometricState().

Adding the same feature to lights and world bounding volumes might be a bit more complicated though.

Well just for spatials it would be really helpfull already :slight_smile:

Okay it is in.

You can now use the getWorld**** methods to access translation, rotation and scale, without having to call updateGeometricState() on the root node.

Note that to do collision or getWorldBound() you still must use updateGeometricState(). I may fix that at some later point.

Really, really useful functionality. Fantastic!:smiley:

yay perfect no more updategeometric state for every ai entity :slight_smile:

@Momoko_Fan did you commit this change?



i have an issue related to this post : http://hub.jmonkeyengine.org/groups/general-2/forum/topic/camera-woes/



The position computation of the camera is based on the localTranslation of the spatial.This is wrong if the spatial is rotated with the rootnode in the main loop as described in the post.



So i changed the chaseCamera code to base the calculation on the worldTranslation of the spatial. But from then…the spatial doesn’t move anymore (i don’t understand why to be honest) and the camera just follow some invisible node…



The only way i made this work is by calling updateGeometricState on the root node in the main loop after the root node rotation, or to call updateGeometricSpace on the camera target’s parent in the camera update method, before calling the getWortdTranslation on the target.

The first way is too bad because the user will have to call updatgeometricstate in the main loop in order to the camera work properly.

The second just seems to be hacky, and won’t work in every case…



Any Suggestion?

Changing the translation of the rootNode and then using getWorldTranslation() on one of the subnodes should work.

Is there any way to reproduce this issue?

yep, take the testChaseCamera test case

change the updateCamera method of ChaseCamera to



public void updateCamera() {

float hDistance = distance * FastMath.sin((FastMath.PI / 2) - vRotation);

Vector3f pos = new Vector3f(hDistance * FastMath.cos(rotation), distance * FastMath.sin(vRotation), hDistance * FastMath.sin(rotation));

//target.getParent().updateGeometricState();

pos = pos.add(target.getWorldTranslation());

cam.setLocation(pos);

cam.lookAt(target.getWorldTranslation(), initialUpVec);

}



try to move the target with the arrow keys, you’ll see that the target does not move anymore



if you uncomment the target.getParent().updateGeometricState(); line…it works. but can’t work in every situation

if you had a simple update method to the test case



@Override

public void simpleUpdate(float tpf) {

rootNode.updateGeometricState();

}



it works

Okay I found it. The localized update did not update the geometry’s cached transform matrix as it was supposed to. Fix is in SVN.

It works thanks! :wink: