PDA

View Full Version : don't understand angle source in calculations



technologist
11-13-2017, 07:46 PM
I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

2544

And when it reappears here as a "rotation":


float adjacent = hypotenuse * Math.cos(Math.toRadians(rotation)); // note, toRadians because we were working in degrees
float opposite = hypotenuse * Math.sin(Math.toRadians(rotation)); // cos and sin only accept radians


I know better how to build my camera class if I can understand angle A.

I understand why it is there as far as the trig fx, but how is the angle calculated and where does it come from for use in the trig fx?

technologist
11-14-2017, 05:52 PM
Is the angle A localized to XY space?
Is rotation (below) equal to Angle A?

Here, the :float adjacent = hypotenuse * Math.cos(Math.toRadians(rotation))

Confused: which axis does rotation belong to? I need specifics.

I understand you use the sides of the triangles to translate...without knowing how to solve the angle its pointless.

didydriver
12-03-2017, 09:35 AM
I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:


This would be only one angle for the FOV || Field of View. Its not telling you how to set it but giving the a basic pothagorem therum to demonstrate how to calculate the FOV of the players camera. Allowing to let the operation know what it is to draw.

didydriver
12-04-2017, 02:13 AM
[QUOTE=technologist;1289343]I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:


This guy is making things way to complicated. There is a much easier way as far as I'm concerned, and always allow elevation to control the verticle movement.

It's degned for a mouse but will work directly the same if it's the center focus of your translation. Current scale can be used as a speed variable without any major adjustments to your systems layout. There is no reason for doing all that fancy stuff when it can be broken down into 4 quadrants since; at all 4 quadrants you will have to evaluate a different measure anyway.

If this doesn't make since draw a circle on the floor representing a compass , break it down into 4 quadrants and further more into 8 subquadrants , and it should make perfect sense then. each one has to be evaluated in order to determin the azmath ( degree of rotation ). this is within 1 moa ( minut of angle ) off less than 1 inch throughout the span of travel

If you are moving on an elevation save a copy of the variables calculated the difference afterwards and add a degenerative effect for uphill vs downhill if you want a more realistic engine. It's not that much extra code and can be evaluated easily. Or just pass the degeneration as a part of currentScale , never realized how portable this was. But you only need pass the Horizontal plane to the function in order to obtain your movement. Vertical plane with horizontal plane would be for a flight simulator or underwater simulator more than a FPS.



// hi ( this value is for the dominate of the area )
// lo ( this value is for the subordinate of the quadrant )
double newLocationHi ( double angle , double move , double currentScaleCubed ) { return abs((( ( 90 - angle ) * move ) * currentScaleCubed )); }
double newLocationLo ( double angle , double move , double currentScaleCubed ) { return abs(( ( angle * move ) * currentScaleCubed )); }
// can also be determined for the movement of an object and the direction it is facing
void moveMouse
( int xMove , int yMove , bool xRight , bool zUp , double currentScale ,
mouseControls * MouseControls ,
rotation * Rotation )
{
// this value was added for a way to scale the objects to a default size upon init obj::obj(); vs having to do it later
// it can be removed and replaced with whatever value you use to determine how far the object is moving
double cubed = ( currentScale * currentScale * currentScale );
// my default horizontal rotation
/* pointless. can't believe I left It there all this time... i'm ashamed..
if ( ( Rotation->y == 0.0 ) || ( Rotation->y == 360.0 ) )
{
if ( zUp ) MouseControls->MouseCurrentLocation.z += (yMove*currentScale)/10;
else if ( !zUp ) MouseControls->MouseCurrentLocation.z -= ( yMove*currentScale)/10;
if ( xRight ) MouseControls->MouseCurrentLocation.x += (xMove*currentScale)/10;
else if ( !xRight ) MouseControls->MouseCurrentLocation.x -= (xMove*currentScale)/10;
return;
}
*/
// keep rotation between 0 and 360 I should remove this since I recently made it a safeguard of the
// class itself
if ( Rotation->y < 0.0 ) Rotation->y += 360.0;
if ( Rotation->y <= 90.0 )
{
// can be switched with your keys
// e.g. xRight would be 'D' I guess
// zUp would be W (!zUp) would be S
if ( xRight )
{
MouseControls->MouseCurrentLocation.x += newLocationHi( Rotation->y,xMove,cubed);
MouseControls->MouseCurrentLocation.z += newLocationLo( Rotation->y,xMove,cubed);
}
else if ( !xRight )
{
MouseControls->MouseCurrentLocation.x -= newLocationHi(Rotation->y,xMove,cubed);
MouseControls->MouseCurrentLocation.z -= newLocationLo(Rotation->y,xMove,cubed);
}
if ( zUp )
{
MouseControls->MouseCurrentLocation.x += newLocationLo ( Rotation->y,yMove,cubed);
MouseControls->MouseCurrentLocation.z -= newLocationHi ( Rotation->y,yMove,cubed);
}
else if ( !zUp )
{
MouseControls->MouseCurrentLocation.x -= newLocationLo ( Rotation->y,yMove,cubed);
MouseControls->MouseCurrentLocation.z += newLocationHi ( Rotation->y,yMove,cubed);
}
}
else if ( Rotation->y <= 180 )
{
if ( zUp )
{
MouseControls->MouseCurrentLocation.x += newLocationHi ( ( Rotation->y - 90 ) , yMove , cubed );
MouseControls->MouseCurrentLocation.z += newLocationLo ( ( Rotation->y - 90 ) , yMove , cubed );
}
else if ( !zUp )
{
MouseControls->MouseCurrentLocation.x -= newLocationHi ( ( Rotation->y - 90 ) , yMove,cubed);
MouseControls->MouseCurrentLocation.z -= newLocationLo ( ( Rotation->y - 90 ) , yMove,cubed);
}
if ( xRight )
{
MouseControls->MouseCurrentLocation.x -= newLocationLo ( ( Rotation->y - 90 ) , xMove,cubed);
MouseControls->MouseCurrentLocation.z += newLocationHi ( ( Rotation->y - 90 ) , xMove,cubed);
}
if ( !xRight )
{
MouseControls->MouseCurrentLocation.x += newLocationLo ( ( Rotation->y - 90 ) , xMove , cubed );
MouseControls->MouseCurrentLocation.z -= newLocationHi ( ( Rotation->y - 90 ) , xMove , cubed );
}
}
else if ( Rotation->y <= 270 )
{
if ( xRight )
{
MouseControls->MouseCurrentLocation.x -= newLocationHi ( ( Rotation->y - 180 ) , xMove , cubed );
MouseControls->MouseCurrentLocation.z -= newLocationLo ( ( Rotation->y - 180 ) , xMove , cubed );
}
else if ( !xRight )
{
MouseControls->MouseCurrentLocation.x += newLocationHi ( ( Rotation->y - 180 ) , xMove , cubed );
MouseControls->MouseCurrentLocation.z += newLocationLo ( ( Rotation->y - 180 ) , xMove , cubed );
}
if ( zUp )
{
MouseControls->MouseCurrentLocation.z += newLocationHi ( ( Rotation->y - 180 ) , yMove , cubed );
MouseControls->MouseCurrentLocation.x -= newLocationLo ( ( Rotation->y - 180 ) , yMove , cubed );
}
else if ( !zUp )
{
MouseControls->MouseCurrentLocation.z -= newLocationHi ( ( Rotation->y - 180 ) , yMove , cubed );
MouseControls->MouseCurrentLocation.x += newLocationLo ( ( Rotation->y - 180 ) , yMove , cubed );
}
}
else if ( Rotation->y <= 360.0 )
{
if ( xRight )
{
MouseControls->MouseCurrentLocation.z -= newLocationHi ( ( Rotation->y - 270 ) , xMove , cubed );
MouseControls->MouseCurrentLocation.x += newLocationLo ( ( Rotation->y - 270 ) , xMove , cubed );
}
else if ( !xRight )
{
MouseControls->MouseCurrentLocation.z += newLocationHi ( ( Rotation->y - 270 ) , xMove , cubed );
MouseControls->MouseCurrentLocation.x -= newLocationLo ( ( Rotation->y - 270 ) , xMove , cubed );
}
if ( zUp )
{
MouseControls->MouseCurrentLocation.x -= newLocationHi ( ( Rotation->y - 270 ) , yMove , cubed );
MouseControls->MouseCurrentLocation.z -= newLocationLo ( ( Rotation->y - 270 ) , yMove , cubed );
}
else if ( !zUp )
{
MouseControls->MouseCurrentLocation.x += newLocationHi ( ( Rotation->y - 270 ) , yMove , cubed );
MouseControls->MouseCurrentLocation.z += newLocationLo ( ( Rotation->y - 270 ) , yMove , cubed );
}
}
}

didydriver
12-13-2017, 06:43 AM
I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

2544

And when it reappears here as a "rotation":



I know better how to build my camera class if I can understand angle A.

I understand why it is there as far as the trig fx, but how is the angle calculated and where does it come from for use in the trig fx?

If you used the function that I posted above now we can get to something a little more complicating. This next part is very partial but you can easily examine it and decipher how to acclimate it to your application needs.



double xChange = ( Camera->Location.x - Target->x );
double yChange = ( Camera->Location.y - Target->y );
double zChange = ( Camera->Location.z - Target->z );
Camera->Rotation.y = atan(zChange/xChange); // atan(z/x) hypot not needed

Doing the math inside the function isn't that much more overhead unless you have a few objects running around. MMO's and Online gaming might be faster this way. Single player can be done as such without any real issues with slowing down.


Camera->Rotation.y = atan(((Camera->Location.z - Target->z)/(Camera->Location.x - Target->x )));

Each step can be broken down further if you like. This however should suffice. It doesn't required multiple calculations on top of the processor. Something to play around with , warning I might have the variables backwards for the camera so if it's rotatingX when it should be rotatingY I apologize in advance. You use atan to get the degrees from the equation , already built in and far easier to use imho.

Angle A is theta of the equation.