Hi there,
I have created playerNode with child ghostNode. I have defined LookAt for ghostNode, say at enemy. Next step I cast the ray from ghostNode to looked enemy … and result for shootables is null.
Setting for testing playerNode instead of ghost gives me bucket of data.
How to understand fact of attaching ghostNode to playerNode? If Im rotating playerNode, the ghost is rotating too - obviously. But if LookAt is switched for ghost node then it should trace the enemy despite parent is rotating counterwise? Simplifing - why ghostNode does not want to cooperate?
Getting a direction from one object to another is simple enough without using the lookAt method.
// roughly translates to enemy subtract player equals distance.
// Normalized distance = direction.
Vector3f a = new Vector3f(100, 200, 300);
Vector3f b = new Vector3f(200, 300, 400);
Vector3f direction = b.subtract(a).normalizeLocal();
To answer your question, though, I don’t think ghost controls rotate. They use axis aligned bounding boxes. The box will change size as you rotate but it’s still aligned to the axes. So you’re essentially always pointing at -Z or forward.
A node will rotate and so you get your desired output.
Ok thanks. Is any such simple way to recognise in understandable form, variation between Vector3 direction and say Vector3 b?
Well vectors can be so many things, that’s what’s so great about them. I’ll post a link to a book that I have read many times. I encourage you to read it in your spare time.
https://natureofcode.com/book/chapter-1-vectors/
Strictly speaking a direction is what’s called a unit vector. A vector with a magnitude of 1. You can check this with the method myVector.isUnitVector() - which the javadoc describes as:
true if this vector is a unit vector (length() ~= 1), or false otherwise.
i thought about angle recognition rather more than breaking the structure of vectors to atoms…
Well a direction will vary between -1 and 1. So if we take the sine or cosine of the value we’ll get an angle in radians. If we multiply that by the constant RAD_TO_DEG it will convert radians to degrees. Generally, though, you should work in radians and provide data to the end-user in degrees. I don’t think the engine works with degrees anywhere.
// the angles of my direction in radians.
float radiansX = FastMath.cos(myVec.x);
float radiansY = FastMath.sin(myVec.y);
float radiansZ = FastMath.cos(myVec.z);
// angles in degrees
float degreesX = radiansX * FastMath.RAD_TO_DEG;
float degreesY = radiansY * FastMath.RAD_TO_DEG;
float degreesZ = radiansZ * FastMath.RAD_TO_DEG;
Well… SOLVED 
Thank you
Vector3f dirPlayer = characterNode.getWorldTranslation();
Vector3f dirEnemy = enemyNode.getWorldTranslation();
Vector3f direction = dirEnemy.subtract(dirPlayer).normalizeLocal();
float radiansPlayerZ = FastMath.sin(dirPlayer.z);
float radiansDirectionZ = FastMath.sin(direction.z);
float degreesPlayerZ = radiansPlayerZ * FastMath.RAD_TO_DEG;
float degreesDirectionZ = radiansDirectionZ * FastMath.RAD_TO_DEG;
float variation = degreesDirectionZ - degreesPlayerZ ;
Not at all however. Result is slightly odd and I still have no idea what does it mean… 
in your code dirPlayer is not a direction, its a location, so radiansPlayerZ will not be what you expect.
Vector3f dirPlayer = characterNode.getLocalRotation().getRotationColumn(2);
Vector3f dirEnemy = enemyNode.getLocalRotation().getRotationColumn(2);
Yeah I tried direction but using these ones is giving me no result
should be cos if axis z of coz but still no efect
I have no idea what you’re trying to do. If you want to know the rotation of a node you query the rotation quaternion.
// get the rotation of a node in radians. each axis is an index of the array (x, y, z).
float[] angles = new float[3];
node.getLocalRotation().toAngles(angles);
If you want the world rotation use .getWorldRotation().
I would like to measure the angle to test if autoaiming should be switched on/off. It is best and easiest way for my case
Angle between player direction and line of sight on enemy
Node player;
Node enemy;
// get the rotation of the player in radians.
float[] playerRotation = new float[3];
player.getLocalRotation().toAngles(playerRotation);
// get the direction of the enemy from the player
Vector3f dir = enemy.getLocalTranslation().subtract(player.getLocalTranslation()).normalizeLocal();
// convert the direction to radians.
float[] rotationToEnemy = new float[3] {
dir.x * FastMath.HALF_PI,
dir.y * FastMath.HALF_PI,
dir.z * FastMath.HALF_PI,
}
// get the rotation required to look at the enemy.
float[] difference = new float[3] {
rotationToEnemy[0] - playerRotation[0],
rotationToEnemy[1] - playerRotation[1],
rotationToEnemy[2] - playerRotation[2],
}
Or something like that. I wrote it off the top of my head. The way I see the math is that if i’m 23 degrees rotated and the enemy is 38 degrees, i should get 38 - 23 = 15 degrees required to “look directly” at the player. So from what you said you want to know if that angle is large or small to decide if you should auto-aim. That should work.
If that’s not what you mean then i have no idea 
Another case where angles are totally unnecessary… but I’ve beaten the “dot product” drum about 500 times on the forum so it should be easy to find. Almost this exact same question appeared just in the past week.
Ergh. Yes. I actually read the thread you’re referencing.
I’m not sure of this because effect is similar as achieved earlier. results oscillating between ±0.039 etc. or even -0.025 when directions are perpendicular visually. Any ideas?
sorry… circa -1.5 if perpendicular
Well it’s a float. It’s fast not precise. If that value is in degrees I’d call it a win. The dot product is faster and more precise since there are less calculations involved. I’m not on my pc now so I can’t write any code. It takes forever on my phone.