# Better way to go up/down slope based on yaw?

Alright, so I got a bit of movement code and I'm thinking I'm going to need to manually input when to go up/down a slope. All I got to work with is the slope's normal, and vector, and My current and previous position, and my yaw.

Is there a better way to rotate whether I go up or down the slope based on my yaw?

``````Vector3f move = new Vector3f(0,0,0);
move.normalise();

if(move.z < 0 && slopeNormal.z > 0 || move.z > 0 && slopeNormal.z < 0){
if(move.x < 0 && slopeNormal.x > 0 || move.x > 0 && slopeNormal.x < 0){
move.y += slopeVec.y;
}
}

if(move.z > 0 && slopeNormal.z > 0 || move.z < 0 && slopeNormal.z < 0){
if(move.x > 0 && slopeNormal.x > 0 || move.x < 0 && slopeNormal.x < 0){
move.y -= slopeVec.y;
}
}

move.scale(movementSpeed * delta);
``````
-

According to your current code, both the x- and the z-component of my movement need to be pointing up the slope for me to start climbing. Consider a slope with the normal (0,1,-1) normalised, and my horizontal motion (0,0,1). I would not pass the conditions in the x-direction, even though I'm going straight up the hill. I doubt that's what you're trying to accomplish.

The dot product will tell you whether you're going up or down and by how much:

``````horizontaldotproduct = move.x * slopeNormal.x + move.z * slopeNormal.z;
move.y = -horizontaldotproduct / slopeNormal.y;
``````

The movement vector will now point along the surface, but leaves the x- and z-components alone. You may want to resize the vector to maintain absolute speed or compensate for gravity etc.

This method is anisotropic. It uses some shortcuts based on what is horizontal and what is vertical. As a result, it requires your terrain does not have vertical or overhanging surfaces and is quite limited in true 3D situations, such as bouncing from or rolling off surfaces.

-
move.y = -horizontaldotproduct / slopeNormal.y; kept making my Y into NaN, but move.y = -horizontaldotproduct * slopeNormal.y; worked. Thank you. – CyanPrime Jun 25 '12 at 12:11
That would suggest slopeNormal.y is zero, i.e. the slope is vertical. In such a situation there is no move.y that can make the object follow the surface without changing the horizontal velocity, so an error is to be expected. If you use multiplication instead of division, the vertical component will point in the right direction, but its magnitude will be too low for anything but a perfectly flat surface. In case you're getting this error on 'proper' slopes, you should check for bugs elsewhere. – Marcks Thomas Jun 25 '12 at 14:26