I Can't Properly Rotate The Enemy To Look At Me All The Time.

[Heelp 1688]

Guys, I spawned an enemy that moves towards me all the time no matter where I move.

 

Now I need to somehow rotate properly the enemyRun animation so the enemy faces ME all the time, no matter where I move.

 

Sounds easy, but that glm::rotate function is unbelievably messed up ( at least for me ).

 

What my logic is:

 

1.Find the vector pointing from 'enemyPosition' to 'playerPosition' and normalize it. Lets call that vector 'movementDirection'.

 

2.Now find the vector that shows the current direction that the enemy faces. When my enemy is spawned, I made it to face the +X axis by default.

 

3. Then find the angle between the current direction the enemy faces( along +X ) and the direction the enemy needs to face ( towards me ) and somehow regulate it to rotate somehow. ( this is the part where I don't know what I'm doing )

 

Update 1: The glm::rotate function accepts radians not degrees, this means that rotation.w should be in radians, so glm::radians( angle ).

Update 2: Dot product doesn't work for 360 degrees, just for 180, I need more vectors to cleary distinguish the position in a 360-degree environment.

Update 3. In order to get the 360 degrees I need a third vector, lets say I can get the third vector using a cross product, but then how to use the third one properly?

 

The movement is ok, but the rotation is messed up. Here is the code:

 

Note: rotation.w is the rotationAngle, rotation.y = 1.0f means: rotate along the Y axis.

void Enemy::moveTowardsPlayer( glm::vec3 playerPos )
{
    movementDirection = normalize( playerPos - position );
    rotation.w = dot( movementDirection, faceDirection )*someNumberIdontKnow; //This is the rotation angle
    rotation.y = 1.0f;
    position += movementDirection/50.0f;
}

Edited July 22, 2016 by Heelp

[Heelp 1688]

//Deleted

Edited July 22, 2016 by Heelp

[ExErvus 695]

Use the formula arcos(dot(v, w) / (mag(v) * mag(w)) where v and w are the players position and the enemies position.

 

This will give you the angle between the two. Use that angle to rotate your enemy to your player.

 

Edit: That will give you the value in degrees. Multiply the resulting angle by PI/180 to convert it to radians.

Edited July 22, 2016 by ExErvus

[Heelp 1688]

Yes, this is the dot product, but it works only for [ 0; 180 ], not for [ 0; 360 ], so I need something else.

Edited July 22, 2016 by Heelp

[Nanoha 2681]

I personally find angles really horrible to work with and store orientations as. This would be a lot easier if you stored orientations as a matrix or a quaternion. Also quaternions would give you SLERP which is great for doing an animated rotation towards your target. What you want is something along the lines to atan2 which is great because your enemy faces x by default.

movementDirection = playerPos - position;
// going to ignore elevation
movementDirection .y = 0;
movementDirection = normalize( movementDirection );
rotation.x = 0;
rotation.y = 1;
rotation.z = 0;
rotation.w = atan2(movementDirection.z, movementDirection.x); // this won't work if the enemy doesn't face x by default
position += movementDirection/50.0f;

Ideally you should set things by angles but it's easier to store and manipulate things by avoiding angles. Creating this kinda thing here doesn't even require any angles, it just needs a forward vector (movementDirection), an up vector (0, 1, 0) and a cross product. That will give you enough to build an orthogonal basis which you'd use as your orientation matrix. Those vectors would just be rows in the matrix.

 

I remember using angles a lot in the early days and I have to say it is so much easier without them. Of course at times you do need them but you should drop them as soon as possible (accept angles as initialisation because they are user friendly but internally work with quaternions or matrices). Also same goes for degrees, drop degrees as soon as you can and use radians. Use them if you are exposing an angle to a user/designer because degrees are more intuitive but drop it as soon as possible and store it as radians. Convert from degrees as soon as possible and to degrees as late as possible.

Edited July 22, 2016 by Nanoha

[Tangletail 2915]

Quick question... if you're trying to make an enemy look at you the entire time... then why are you bothering with the angle between two look directions?

 

In reality, you're making this more complex then it needs to be. I'd also assume that you're always keeping track of the enemy's rotation, otherwise your life will be difficult.

Just subtract your position from the enemy's position. This will give you a vector with magnitude. Convert this into a unit vector, and you now have your rotation target.

You can then use LERP or SLERP to smoothly rotate the enemy if you're in 3d.

Edited July 22, 2016 by Tangletail

[ExErvus 695]

This is not the dot product. The dot product is a part of the formula. This formula tells you exactly how many degrees you need to rotate.

[Heelp 1688]

Nanoha and Tangletail, thanks. I will gather some info about quaternions, I have one 3d math book focused on games, will have to read one chapter on quaternions today, apparently.

 

ExErvus, two things:

 

First, the dot product maps:

180 degrees to -1

90 degrees to 0

0 degrees to 1

 

That's why your formula doesn't work, man.

 

arccos will turn [ -1; 1 ] into [ 0; 180 ] range, not [ 0 ; 360 ]. Dot product between 2 vectors doesn't distinguish between left and right. Quaternions are the answer.

 

Second, see this website: http://www.cplusplus.com/reference/cmath/acos/

This says that acos ( which is the c++ 11 <cmath> variant of arccos ) returns the principal value of the arc cosine of x, expressed in radians, not in degrees, as you said.

Edited July 22, 2016 by Heelp

[ExErvus 695]

You are right, forgot that fact =)

[Heelp 1688]

Guys, I fixed the problem by using neither quaternions, nor atan2().

 

I figured that if one dot product helps me to determine an angle in the range[0; 180], then two dot products can do it for [0; 360]

so I used 3 vectors to determine the rotation , not 2.

 

First, I find the cross product of the upVector( +y ) and the faceDirection( +x ), which happens to be +z ( or -z, depends on the order of the arguments ).

Then I say:

void Enemy::moveTowardsPlayer( glm::vec3 playerPos )
{
    crossVec = glm::cross( faceDirection, upDirection ); // Find the vector pointing at +z
    movementDirection = normalize( playerPos - position ); // find the vector between playerPos and enemyPos
    float dotProduct = dot( movementDirection, faceDirection );
    float crossVecDotProduct = dot( movementDirection, crossVec );
 
    if( crossVecDotProduct < 0 ) // If I turned left
    {
        rotation.w = std::acos( dotProduct ); calculate degrees from 0 to 180
    }
    else //else I turned right
    {
        rotation.w = std::acos( -dotProduct ) + M_PI;  calculate degrees from 180 to 360( thats why I increment by Pi )
    }
 
    rotation.y = 1.0f;
    position += movementDirection/30.0f;
    position.y = -0.5f;
}

Edited July 22, 2016 by Heelp

[Tangletail 2915]

That's probably the inefficient solution. But fair enough.

[Heelp 1688]

What do you mean - inefficient?

[Nanoha 2681]

What do you mean - inefficient?

void Enemy::moveTowardsPlayer( glm::vec3 playerPos )
{
    crossVec = glm::cross( faceDirection, upDirection ); //6 multiplications, 3 subtractions
    movementDirection = normalize( playerPos - position ); //3 multiplications, 3 additions, 3 subtractions, 3 divisions, 1 square root
    float dotProduct = dot( movementDirection, faceDirection ); // 3 multiplications, 3 additions
    float crossVecDotProduct = dot( movementDirection, crossVec ); // 3 multiplications, 3 additions
 
    if( crossVecDotProduct < 0 ) // If I turned left
    {
        rotation.w = std::acos( dotProduct ); // trig functions (these can be slow)
    }
    else //else I turned right
    {
        rotation.w = std::acos( -dotProduct ) + M_PI;  // trig func, addition
    }
 
    rotation.y = 1.0f;
}

15 multiplications, 8(9) additions, 6 subtractions, 3 divisions, 1 square root, 1 trig function
 

movementDirection = playerPos - position; // 3 subtractions
// going to ignore elevation
movementDirection .y = 0;
movementDirection = normalize( movementDirection ); // 3 multiplications, 3 additions, 3 divisions, 1 square root
rotation.x = 0;
rotation.y = 1;
rotation.z = 0;
rotation.w = atan2(movementDirection.z, movementDirection.x); // trig func

3 multiplications, 3 additions, 3 subtractions, 3 divisions, 1 square root, 1 trig function.

Obviously I may have missed something and a few odd bits I didn't count. I don't know how glm is calculating it's dot prodcts or cross products but there's a limit to how efficient it can be made. I don't know how atan2/acos are compared to each other but the second option appears to do less work. It depends largely on how slow the trig functions are, if there's a huge difference then that may be the deciding factor. Of course it's likely that you don't have any performance issues so it's no problem anyway. Your solution certainly does what it's intended to and it's easy to see why you came up with that (it makes sense).

Edited July 23, 2016 by Nanoha

[WiredCat 1452]

So you shouldnt use angles for that i wont explain whys that. Just vreate a rotation matrix since you will know 2 vectors you are all good firt vector is front enemy-player, second one is the up vector with these two normalized you make cross product and end wirh side vector if front and up aint parallel (i might use wrong word) then you need to normalize that cross product .build a mat out of these 3 vectors and aply it to enemy object simple as hell

[EarthBanana 1794]

I think your solution is fine but it might be worth it for you to switch over to quats in the future as they can make life a lot easier especially if you start animating things..

It seems glm has them already built in with gtx namespace?

http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-17-quaternions/

[Heelp 1688]

I've used many tutorials from that same website and it seems that I've totally missed out that one. Will check it definitely! 

Thanks!