Standardizing polar coordinate directions
by Mike Lilligreen · in Torque 2D Professional · 07/11/2013 (8:21 am) · 15 replies
I didn't think much of it at the time, but within the particle system at an emission angle of 0, the particles move in the positive X direction.
Today I found out that for SceneObjects using setLinearVelocityPolar - putting an angle of 0 as one of the parameters sends the object in the minus Y direction!
Digging into the source, I found out why:
ParticlePlayer.cc
Cos, Sin for the vector
SceneObject_ScriptBinding.h
Sin, -Cos -> I assume this is from legacy TGB where minus Y was screen up.
This is an easy enough fix, the question is what should be the standard direction at 0 degrees: positive X axis (screen right) or positive Y (screen up)? To be mathematically correct with the unit circle, it should be screen right but historically I think we always had screen up.
Today I found out that for SceneObjects using setLinearVelocityPolar - putting an angle of 0 as one of the parameters sends the object in the minus Y direction!
Digging into the source, I found out why:
ParticlePlayer.cc
pParticleNode->mVelocity.Set( emissionForce * mCos( emissionAngleRadians ), emissionForce * mSin( emissionAngleRadians ) );
Cos, Sin for the vector
SceneObject_ScriptBinding.h
object->setLinearVelocity( Vector2( sin*speed, -cos*speed ) );
Sin, -Cos -> I assume this is from legacy TGB where minus Y was screen up.
This is an easy enough fix, the question is what should be the standard direction at 0 degrees: positive X axis (screen right) or positive Y (screen up)? To be mathematically correct with the unit circle, it should be screen right but historically I think we always had screen up.
About the author
#2
-
This is worth discussing for sure, but I doubt this type of change (coordinate system) swill make it in for 3.0.
The main reason the coordinate system is like it is right now (+y is up, -y is down) is to coincide with Box2D.
As such, the change could be done but would need to be tested in a variety of cases and would involve code changes in most object types.
07/11/2013 (4:40 pm)
@Mike : good find! Will test and try to implement as soon as possible. I've been digging around the particle effects with the help of your guides and posted issues and have found quite a few bugs that need squashing.-
This is worth discussing for sure, but I doubt this type of change (coordinate system) swill make it in for 3.0.
The main reason the coordinate system is like it is right now (+y is up, -y is down) is to coincide with Box2D.
As such, the change could be done but would need to be tested in a variety of cases and would involve code changes in most object types.
#3
Your comments on the coordinate system left me a bit puzzled though. I am not suggesting we change the coordinate system - I know it previously changed due to Box2D and I am actually happy it is this way now. The issues spring up with how velocities are handled. To summarize my proposal:
1. Coordinate system (+X is right, +Y is up) - everything is fine, no changes
2. Movement with Cartesian coordinates (setLinearVelocity) - I believe everything is working ok, no changes
3. Movement with Polar coordinates (setLinearVelocityPolar, EmissionAngle graph field) - not handled correctly/uniformly, needs fixing
The actual changes needed are fairly trivial (famous last words) - just need to alter the order/sign of mSin and mCos in the two lines of code I posted above. It's easy enough that I can make the changes, test it, and submit a pull request. You've got enough on your plate. :)
I just wanted some community/steering committee buy-in as to what direction 0 degrees should represent: screen right or screen up.
This is a breaking change though - if we go with screen up, for example, I will have to change all my particle effects (1 line in each ParticleAsset file, not a huge deal in the grand scheme of things). I would prefer we get any identified breaking changes in before 3.0 to be honest. 3.0 will hopefully attract a bunch of new users to T2D, and I'd rather we break stuff while the community is still relatively small. Although thinking more about it, I'm sure future releases will have plenty of system/feature overhauls in them anyway so maybe this is a moot point.
07/12/2013 (1:17 am)
Hi Simon, thanks for releasing those bug fixes a couple weeks ago for the issues I had posted on Github. Much appreciated.Your comments on the coordinate system left me a bit puzzled though. I am not suggesting we change the coordinate system - I know it previously changed due to Box2D and I am actually happy it is this way now. The issues spring up with how velocities are handled. To summarize my proposal:
1. Coordinate system (+X is right, +Y is up) - everything is fine, no changes
2. Movement with Cartesian coordinates (setLinearVelocity) - I believe everything is working ok, no changes
3. Movement with Polar coordinates (setLinearVelocityPolar, EmissionAngle graph field) - not handled correctly/uniformly, needs fixing
The actual changes needed are fairly trivial (famous last words) - just need to alter the order/sign of mSin and mCos in the two lines of code I posted above. It's easy enough that I can make the changes, test it, and submit a pull request. You've got enough on your plate. :)
I just wanted some community/steering committee buy-in as to what direction 0 degrees should represent: screen right or screen up.
This is a breaking change though - if we go with screen up, for example, I will have to change all my particle effects (1 line in each ParticleAsset file, not a huge deal in the grand scheme of things). I would prefer we get any identified breaking changes in before 3.0 to be honest. 3.0 will hopefully attract a bunch of new users to T2D, and I'd rather we break stuff while the community is still relatively small. Although thinking more about it, I'm sure future releases will have plenty of system/feature overhauls in them anyway so maybe this is a moot point.
#4
I will definitely bring it up next meeting (Saturday) and will post back here when we have a definite answer/plan. My guess would be +Y is up, as Richard said. It just intuitively makes sense.
The way we've discussed it amongst committee members, point releases will feature breaking changes. Just the way the in-file documentation for Doxygen is handled will require all functions to be rewritten without their usage string + a potential new callback system will definitely mean breaking stuff (for the best).
07/12/2013 (1:53 am)
Ah! Now I understand, sorry for my confusion.I will definitely bring it up next meeting (Saturday) and will post back here when we have a definite answer/plan. My guess would be +Y is up, as Richard said. It just intuitively makes sense.
The way we've discussed it amongst committee members, point releases will feature breaking changes. Just the way the in-file documentation for Doxygen is handled will require all functions to be rewritten without their usage string + a potential new callback system will definitely mean breaking stuff (for the best).
#5
07/15/2013 (10:24 pm)
I have noticed that I need to draw my sprites upside down because of the 0 degrees == straight down logic. Having 0 degrees be straight up would fix that annoyance. I therefore vote for 0 degrees = straight up, for what its worth.
#6
07/15/2013 (10:52 pm)
What methods/functions are you using to display your sprites Michael? My bugs were more movement related, so it sounds like there is another area in the source that needs fixing. Would be good to capture all polar coordinate issues in one bug fix.
#7
I use spriteObject()'s setImage() and setFrame() functions. It is only an issue for those object whose movement I direct according to their orientation. For example, for a seeking missile I set its movement using the polar version of set velocity using its orientation ( spriteObject.getAngle() ) and speed. Unless I keep track of an angular offset for each object that moves that way I need to align the sprite image to the 0 degrees direction. It just feels funny to draw all such objects pointing down.
07/16/2013 (3:15 pm)
It is just a matter of keeping my code simple, not a bug.I use spriteObject()'s setImage() and setFrame() functions. It is only an issue for those object whose movement I direct according to their orientation. For example, for a seeking missile I set its movement using the polar version of set velocity using its orientation ( spriteObject.getAngle() ) and speed. Unless I keep track of an angular offset for each object that moves that way I need to align the sprite image to the 0 degrees direction. It just feels funny to draw all such objects pointing down.
#8
First, I highly recommend making the coordinates in agreement with well established mathematical conventions. This means that 0 degrees is along the positive X-axis and that 90 degrees is along the positive Y-axis.
There is good reasoning for this, too. A slope (a tangent) is the rise of a slope over its run. Also known as the delta-Y over the delta-X. The inverse tangent should be able to take a delta-Y and delta-X and then get the same tangent angle.
Here's is a sampling of function calls I've made:
With the enormous inconsistencies, I don't see why we can't break everybody's functionality. A consistent system is superior to a patchwork system of functions.
I'm sure this is probably broken in tons of other areas, too.
If I can get agreement (is there a better place for that), I'd be more than willing to go through all of the code and make the angles consistent.
09/01/2013 (11:18 am)
I've been migrating my older 2D engine and have found several problems.First, I highly recommend making the coordinates in agreement with well established mathematical conventions. This means that 0 degrees is along the positive X-axis and that 90 degrees is along the positive Y-axis.
There is good reasoning for this, too. A slope (a tangent) is the rise of a slope over its run. Also known as the delta-Y over the delta-X. The inverse tangent should be able to take a delta-Y and delta-X and then get the same tangent angle.
Here's is a sampling of function calls I've made:
// To go from "0 0" to "5 0", the +X-axis ==>echo( Vector2AngleToPoint( "0 0", "5 0" ) ); 90 // To go from "0 0" t "0 5", the +Y-axis ==>echo( Vector2AngleToPoint( "0 0", "0 5" ) ); 180 // So where is 90 degrees? The +X-axis! ==>echo( Vector2Direction( 90, 1 ) ) 1 0 // So then where is the 180 degrees? The negative Y-axis! What?! ==>echo( Vector2Direction( 180, 1 ) ) 0 -1 // Let's rotate the X-Axis 90 degrees. What's happening?! ==>echo( Vector2Rotate( "5 0", 90 ) ); -2.2404 4.47 // Well apprently, we're looking for radians! // I'll pass in PI/2 (90 degrees), and get the positive Y-axis! ==>echo( Vector2Rotate( "5 0", 3.1415926/2 ) ); 0 5
With the enormous inconsistencies, I don't see why we can't break everybody's functionality. A consistent system is superior to a patchwork system of functions.
I'm sure this is probably broken in tons of other areas, too.
If I can get agreement (is there a better place for that), I'd be more than willing to go through all of the code and make the angles consistent.
#9
I had only focused on the polar movement functions, so it was only SceneObject, ParticlePlayer, and Scroller that I had intended to change. It looks like there are deeper issues with general vector math though - thanks for finding this!
I agree we should make everything consistent, this would be a good fix for the 3.0 update since point updates are where we include breaking changes. If you have time to go through the code and find all the areas where this needs to be fixed, that would be a huge help.
So far the majority that have replied to this thread have voted for 0 degrees being +Y, but there still is a good argument for having 0 be +X, as you mentioned. I suppose finding all the functions that need fixing is the first step, and while that is going on we can continue discussing as a community which axis should be zero.
09/03/2013 (8:59 pm)
Hi William,I had only focused on the polar movement functions, so it was only SceneObject, ParticlePlayer, and Scroller that I had intended to change. It looks like there are deeper issues with general vector math though - thanks for finding this!
I agree we should make everything consistent, this would be a good fix for the 3.0 update since point updates are where we include breaking changes. If you have time to go through the code and find all the areas where this needs to be fixed, that would be a huge help.
So far the majority that have replied to this thread have voted for 0 degrees being +Y, but there still is a good argument for having 0 be +X, as you mentioned. I suppose finding all the functions that need fixing is the first step, and while that is going on we can continue discussing as a community which axis should be zero.
#10
09/04/2013 (6:47 am)
Well hell, if we're gonna be all "correct" and "proper" we should probably follow the actual coordinate system - so people fresh out of school don't have to learn this backwards mess. Torque has enough confusion for new people built in, this should be fixed per William's suggestion.
#11
09/04/2013 (10:40 am)
I'll get a branch going today or tomorrow. Thanks!
#12
Done:
-----
* All script functions return angles as degrees; all script functions take angles as degrees.
* All polar coordinates everywhere follow the standard convention.
* Fixed mAtan and every use of it (plus, the script version can also take a space-separated vector).
* Fixed all of the Toys that used angle functions. (Simplified a lot of code! Yippee!)
* I've started a Toy that shows how to use the angle functions (both for scene objects and generically).
To Do:
------
* Verify that all angle uses in particle effects are correct.
* Finish the Toy.
09/13/2013 (3:07 pm)
Here's an update for anybody who might care:Done:
-----
* All script functions return angles as degrees; all script functions take angles as degrees.
* All polar coordinates everywhere follow the standard convention.
* Fixed mAtan and every use of it (plus, the script version can also take a space-separated vector).
* Fixed all of the Toys that used angle functions. (Simplified a lot of code! Yippee!)
* I've started a Toy that shows how to use the angle functions (both for scene objects and generically).
To Do:
------
* Verify that all angle uses in particle effects are correct.
* Finish the Toy.
#13
09/26/2013 (1:12 pm)
I'm a bit late in replying but thanks for the progress update. Do you think you will be finished soon? I'd like to make sure these changes make it into the 3.0 release.
#14
09/27/2013 (12:37 pm)
I'll very likely be done with my tests and feel "comfortable" with the changes this weekend. When is the 3.0 release?
#15
One thing to note, I recently updated the dev branch with changes for better doxygen support - it touched a lot of files since all console methods are now contained in their own ScriptBinding files. This might impact the coordinate fixes, depending on what files you modified.
09/27/2013 (10:16 pm)
There isn't a fixed date yet for the 3.0 release as it hangs a bit on the android port being finished. From what I heard though, we are talking about a matter of weeks and not months. Plus getting the changes into development will give people time to test, etc.One thing to note, I recently updated the dev branch with changes for better doxygen support - it touched a lot of files since all console methods are now contained in their own ScriptBinding files. This might impact the coordinate fixes, depending on what files you modified.
Torque Owner Richard Ranft
Roostertail Games