• Create Account

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

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

15 replies to this topic

### #1codeBoggs  Members

1492
Like
0Likes
Like

Posted 22 July 2016 - 08:22 AM

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 by Heelp, 22 July 2016 - 10:57 AM.

### #2codeBoggs  Members

1492
Like
0Likes
Like

Posted 22 July 2016 - 09:21 AM

//Deleted


Edited by Heelp, 22 July 2016 - 10:57 AM.

### #3ExErvus  Members

695
Like
0Likes
Like

Posted 22 July 2016 - 10:43 AM

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 by ExErvus, 22 July 2016 - 10:47 AM.

### #4codeBoggs  Members

1492
Like
1Likes
Like

Posted 22 July 2016 - 10:48 AM

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

Edited by Heelp, 22 July 2016 - 10:56 AM.

### #5Nanoha  Members

2439
Like
3Likes
Like

Posted 22 July 2016 - 11:04 AM

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 by Nanoha, 22 July 2016 - 11:14 AM.

Interested in Fractals? Check out my App, Fractal Scout, free on the Google Play store.

### #6Tangletail  Members

2673
Like
3Likes
Like

Posted 22 July 2016 - 11:05 AM

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 by Tangletail, 22 July 2016 - 11:09 AM.

### #7ExErvus  Members

695
Like
0Likes
Like

Posted 22 July 2016 - 11:22 AM

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.

### #8codeBoggs  Members

1492
Like
1Likes
Like

Posted 22 July 2016 - 11:26 AM

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 by Heelp, 22 July 2016 - 11:57 AM.

### #9ExErvus  Members

695
Like
4Likes
Like

Posted 22 July 2016 - 11:53 AM

You are right, forgot that fact =)

### #10codeBoggs  Members

1492
Like
1Likes
Like

Posted 22 July 2016 - 12:59 PM

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 by Heelp, 22 July 2016 - 01:13 PM.

### #11Tangletail  Members

2673
Like
2Likes
Like

Posted 22 July 2016 - 07:29 PM

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

### #12codeBoggs  Members

1492
Like
0Likes
Like

Posted 23 July 2016 - 02:58 AM

What do you mean - inefficient?

### #13Nanoha  Members

2439
Like
3Likes
Like

Posted 23 July 2016 - 05:15 AM

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 by Nanoha, 23 July 2016 - 05:28 AM.

Interested in Fractals? Check out my App, Fractal Scout, free on the Google Play store.

### #14WiredCat  Members

1326
Like
-1Likes
Like

Posted 26 July 2016 - 05:56 PM

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

### #15EarthBanana  GDNet+

1765
Like
2Likes
Like

Posted 28 July 2016 - 09:06 AM

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/

### #16codeBoggs  Members

1492
Like
0Likes
Like

Posted 28 July 2016 - 10:27 AM

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!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.