By: joe_duncan
>
> When you call the rotate() function and specify a
> target direction in radians, does the robot turn
> the shortest way around to get there?
No. As you can read in the documentation: "the angle of rotation is absolute (this means that bots facing different direction, required to make a rotation of the same angle, face at the end the same direction). One can get multiple complete rotations passing as arguments large enough angles."
That means that if you specify rotate(0), the bot will face direction 0 (let's say towards north). Then, from there, if you specify rotate(6.28), the bot will face the same north direction after a complete turn, while a rotate(-6.28) will do the same but rotating in the opposite direction.
That's why in my sample you can read rotate(getDirection()+angle) to rotate of a relative angle from the current direction.
This choice makes more difficult to control the bot in some situations but permits to specify absolute directions and also multiple rotations with a single call to the function.
> Does it matter if you use a 0 to 2pi or
> -pi to pi range?
Does not matter until you are consistent with your choice. The direction of 2pi or 0 is the same, of course. To chose one or other depends only on the initial direction of your bot and usually is better to choose the shortest path.
> For instance if you are pointing in the pi/4 direction,
> and you call rotate(-pi/4) or rotate(7pi/4) does it
> behave the same?
In the first case the bot is going to do a single half turn, in the other one turn and a half. To be more clear, another example: If you call again rotate() specifying the same absolute direction, the bot will not turn because it is already facing that direction.
> The best case scenario would be if it would
> turn in the negative direction,
> but I'm not sure that's always the case...
If you call rotate(getDirection()-pi/4) the bot will turn a quarter turn to the left, instead rotate(getDirection()+pi/4) will turn it a quarter turn of the right.
Feel free to ask more, if you have further questions.
--
Ciao, leo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I think I get it. Let me see if I have it straight. The bot holds an internal "direction" value, which could be anything and is not bounded.
So, if the bot's current direction was 1/2pi, and you called "rotate(getDirection() + 2pi)" three times in a row, the bot's internally stored direction would now be 13/2pi.
Then if you called a single "rotate(1/2pi)", even though 1/2pi and 13/2pi are technically the same direction, the bot would unwind the previous rotations by spinning around 3 times to end up facing the same direction as before.
No wonder any bot I have tried to make has been acting screwy. I've been normalizing all angles into the -pi to pi range in order to make the math simpler. Yikes.
Thanks alot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By: Joe Duncan
>
> The bot holds an internal "direction" value,
> which could be anything and is not bounded.
OK
> So, if the bot's current direction was 1/2pi,
> and you called "rotate(getDirection() + 2pi)"
> three times in a row, the bot's internally
> stored direction would now be 13/2pi.
> Then if you called a single "rotate(1/2pi)",
> even though 1/2pi and 13/2pi are technically
> the same direction, the bot would unwind the
> previous rotations by spinning around 3 times
> to end up facing the same direction as before.
The things are as you described them :)
I'm sorry for this behavior so uncommon, but at the beginning I thought that this way it was more versatile (to achieve more complete rotations with a single call)
--
Ciao, leo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, no worries. I was just confused. Thanks for making such a great game.
I have some other questions for you though, is there acceleration/decceleration between when you run and when you walk, or does the speed change discretely between 2.5 and 5.0?
Also, does the angular momentum from torso rotation affect bullet velocity?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By Joe Duncan
>
> is there acceleration/decceleration between
> when you run and when you walk, or does the
> speed change discretely between 2.5 and 5.0?
No acceleration or deceleration (to be consistent with the models' animations)
> Also, does the angular momentum from
> torso rotation affect bullet velocity?
Only the instantaneous linear speed of the model affects the velocity of bullets and grenades.
--
Ciao, leo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you call the rotate() function and specify a target direction in radians, does the robot turn the shortest way around to get there?
Does it matter if you use a 0 to 2pi or -pi to pi range?
For instance if you are pointing in the pi/4 direction, and you call rotate(-pi/4) or rotate(7pi/4) does it behave the same?
The best case scenario would be if it would turn in the negative direction, but I'm not sure that's always the case...
Any help would be appreciated.
Thanks!
By: joe_duncan
>
> When you call the rotate() function and specify a
> target direction in radians, does the robot turn
> the shortest way around to get there?
No. As you can read in the documentation: "the angle of rotation is absolute (this means that bots facing different direction, required to make a rotation of the same angle, face at the end the same direction). One can get multiple complete rotations passing as arguments large enough angles."
That means that if you specify rotate(0), the bot will face direction 0 (let's say towards north). Then, from there, if you specify rotate(6.28), the bot will face the same north direction after a complete turn, while a rotate(-6.28) will do the same but rotating in the opposite direction.
That's why in my sample you can read rotate(getDirection()+angle) to rotate of a relative angle from the current direction.
This choice makes more difficult to control the bot in some situations but permits to specify absolute directions and also multiple rotations with a single call to the function.
> Does it matter if you use a 0 to 2pi or
> -pi to pi range?
Does not matter until you are consistent with your choice. The direction of 2pi or 0 is the same, of course. To chose one or other depends only on the initial direction of your bot and usually is better to choose the shortest path.
> For instance if you are pointing in the pi/4 direction,
> and you call rotate(-pi/4) or rotate(7pi/4) does it
> behave the same?
In the first case the bot is going to do a single half turn, in the other one turn and a half. To be more clear, another example: If you call again rotate() specifying the same absolute direction, the bot will not turn because it is already facing that direction.
> The best case scenario would be if it would
> turn in the negative direction,
> but I'm not sure that's always the case...
If you call rotate(getDirection()-pi/4) the bot will turn a quarter turn to the left, instead rotate(getDirection()+pi/4) will turn it a quarter turn of the right.
Feel free to ask more, if you have further questions.
--
Ciao, leo
Ok, I think I get it. Let me see if I have it straight. The bot holds an internal "direction" value, which could be anything and is not bounded.
So, if the bot's current direction was 1/2pi, and you called "rotate(getDirection() + 2pi)" three times in a row, the bot's internally stored direction would now be 13/2pi.
Then if you called a single "rotate(1/2pi)", even though 1/2pi and 13/2pi are technically the same direction, the bot would unwind the previous rotations by spinning around 3 times to end up facing the same direction as before.
No wonder any bot I have tried to make has been acting screwy. I've been normalizing all angles into the -pi to pi range in order to make the math simpler. Yikes.
Thanks alot!
By: Joe Duncan
>
> The bot holds an internal "direction" value,
> which could be anything and is not bounded.
OK
> So, if the bot's current direction was 1/2pi,
> and you called "rotate(getDirection() + 2pi)"
> three times in a row, the bot's internally
> stored direction would now be 13/2pi.
> Then if you called a single "rotate(1/2pi)",
> even though 1/2pi and 13/2pi are technically
> the same direction, the bot would unwind the
> previous rotations by spinning around 3 times
> to end up facing the same direction as before.
The things are as you described them :)
I'm sorry for this behavior so uncommon, but at the beginning I thought that this way it was more versatile (to achieve more complete rotations with a single call)
--
Ciao, leo
Hey, no worries. I was just confused. Thanks for making such a great game.
I have some other questions for you though, is there acceleration/decceleration between when you run and when you walk, or does the speed change discretely between 2.5 and 5.0?
Also, does the angular momentum from torso rotation affect bullet velocity?
Thanks!
By Joe Duncan
>
> is there acceleration/decceleration between
> when you run and when you walk, or does the
> speed change discretely between 2.5 and 5.0?
No acceleration or deceleration (to be consistent with the models' animations)
> Also, does the angular momentum from
> torso rotation affect bullet velocity?
Only the instantaneous linear speed of the model affects the velocity of bullets and grenades.
--
Ciao, leo