Stupid Mathz Question for Trig Lovers

[Thothie]

Meh, last I took Trigonometry was in High School, and that was a very, very long time ago. I *know* there’s a quicker way to do this, that’d be less CPU intensive, so I thought I’d put it out there and see if anyone could recall what that might be.

Basically, I just need calculate the directional angle between vectors, in degrees (-180/+180). These are 3d vectors, but I only need the 2d angle returned.

This is how I’m currently doing it:

		//Thothie MAR 2008a - $angles(<start_origin>,<end_origin>) – returns the 2d angle between two vectors
 	else if( ParserName == "$angles" )
		{
			if( Params.size() >= 2 )
			{
				Vector Start = StringToVec( Params[0] );
				Vector End = StringToVec( Params[1] );
				float dy = End.y - Start.y;
				float dx = End.x - Start.x;
				float rang = atan2(dy,dx); //gets radians
				float xang = rang * 57.295779; //back to degrees
				RETURN_FLOAT(xang)
			}
			else return "0";
		}

I r a little worried that maybe rough on the server CPU, and again, I’m sure there’s a simpler way to do that, I just can’t think of how, off hand. (Although I know I don’t need the conversion float to be that accurate, it’s the tangent calc that’s the big FPU eater.)

If it was something to be called rarely, I wouldn’t worry about this, but this is for making game functions – such as Maldora’s barrier, more dependable, and could easily wound up being called every frame. Currently, Maldora’s barrier works by having it “face” the incoming target and apply its angle to the target with a whole lot of momentum – sending it flying away. This isn’t dependable under certain circumstances, however. Sometimes it doesn’t face towards the target proper, or in time, and sends it flying in the wrong direction, hence the application of the above command below:

 	local TARGET_ORG $get(PARAM1,origin)
	local TARG_ANG $angles(game.monster.origin,TARGET_ORG)
	setvelocity PARAM1 $relvel($vec(0,TARG_ANG,0),$vec(0,1000,0))

In short, calc the angle based on their respective vectors, and send him flying away in that direction.

This has other applications too, as very often it is imperative to move players/monsters out of a certain area to prevent stuckage.

So, if you understood any of that, feel free to reply with any alternative solutions you may have.

 

[J]

You could use a lookup table to replace the arctan but it has its downsides, too.

 

[Aische]

could u draw a picture that shows the problem given stuff n needed stuff im to tired to understand code

 

[Drigien]

you can write your own arctan with:
x - (x^3/3) , with x = (x/y)
(which involves less operations)

or with x,y :
(x/y) - ((x^3) /( 3*y^3))

The 'actual' function just has more terms depending on the amount of precision needed/wanted, eg:
x- 1/3*x^3 + 1/5*x^5 - 1/7*x^7 + 1/9*x^9 - 1/11*x^11 + 1/13*x^13 - 1/15*x^15 + 1/17*x^17 - 1/19*x^19...

you could try that and see if theres much improvement.

 

[dRkILL]

Nevermind... I didn't fully read the problem...

 

[Thothie]

x - (x^3/3) , with x = (x/y)

Yeah, I was thinking that, but it no workied... Maybe I just coded it wrong... Misa try again...

 

[CrazyMonkeyDude]

Thoth-thoth binks?

 

[Drigien]

x - (x^3/3) , with x = (x/y)

Yeah, I was thinking that, but it no workied... Maybe I just coded it wrong... Misa try again...

it will only work with x = (-1, 1), so you have to adjust it to make sure its going to be in that range or else:

[Red = Approx, Green = arctan(x)]
As you can see, the approx starts getting off close to 1 and then just gets worse from there.

 

[Mouse]

A look-up table should be pretty quick, but I like Drigien's solution. The taylor series expansion was clever . You could even use a linear approximation if accuracy isn't too important. There's also also a CORDIC algorithm that involves rotating the phase of a complex number. Its incredibly accurate but takes a lot of time. I'd go with the series expansion.