Comments on: Tips for Managing Multiple Coordinate Systems All good points... This goes to a bigger issue. Many times in our code there is a lot of information that we would like to surface, but showing it all often causes overload. (No pun intended). I've long been toying with alternate ways of showing that info... I now have this weird vision of an IDE that highlights type conversions and shows the relative cost/lossiness of them via hue&saturation. I think it's time to take my meds ;) All good points… This goes to a bigger issue. Many times in our code there is a lot of information that we would like to surface, but showing it all often causes overload. (No pun intended). I’ve long been toying with alternate ways of showing that info…

I now have this weird vision of an IDE that highlights type conversions and shows the relative cost/lossiness of them via hue&saturation. I think it’s time to take my meds ;)

]]>
By: Ben Carter/2011/02/28/tips-for-managing-multiple-coordinate-systems/#comment-1157 Ben Carter Wed, 02 Mar 2011 11:29:48 +0000 You raise an interesting point on "cost". There is another issue with some conversions where the transformation is "lossy" so repeated transformation will lose accuracy faster than the usual float inaccuracies we are used to. More naming extensions could solves those but I guess you have to draw a line somewhere between code readability and convenience. I think I still prefer XXXToYYY (position) rather than just ToYYY( position ). I think knowing what it came from gives you a chance of knowing about performance and conversion issues, without needing the extra Fast or Approx naming convention. I guess its all a balancing act. Also depends on how many different conversion routines there are. A problem I've had with "Fast" routines, you rarely know exactly how inaccurate they are (especially if its someone elses library/code) so its hard to work out when you should use them. You raise an interesting point on “cost”. There is another issue with some conversions where the transformation is “lossy” so repeated transformation will lose accuracy faster than the usual float inaccuracies we are used to.

More naming extensions could solves those but I guess you have to draw a line somewhere between code readability and convenience.

I think I still prefer XXXToYYY (position) rather than just ToYYY( position ).
I think knowing what it came from gives you a chance of knowing about performance and conversion issues, without needing the extra Fast or Approx naming convention. I guess its all a balancing act. Also depends on how many different conversion routines there are.

A problem I’ve had with “Fast” routines, you rarely know exactly how inaccurate they are (especially if its someone elses library/code) so its hard to work out when you should use them.

]]>
By: Rachel 'Groby' Blum/2011/02/28/tips-for-managing-multiple-coordinate-systems/#comment-1149 Rachel 'Groby' Blum Wed, 02 Mar 2011 02:13:14 +0000 > though doubles are seem pretty safe. Well sure they're safe as long as you use them like an int52 :-) > I’ve never tried replacing floats completely with it. Have you done that on a project? Sort of in StarTopia (because it was this bizarre bent world), though we committed so many other idiotic coordinate sins I'm not sure I'd hold it up as a paragon. All my other commercial games have been small single levels so precision wasn't an issue. For my latest homebrew project I do use integers for all world coords though, and it works fine (it's also on a hex grid, so X and Y are at 60 degrees to each other which hurts the brain somewhat). Although it's just me on it, so take with the appropriate pinch of salt - you can survive a huge number of dumb things when it's just one person. > - there’s a lot of floating point power just going idle? floating processor and possible vector unit? The amount of actual math you do with world coordinates is pretty trivial. As I say, first thing you do in any routine is take a relative value from object A to object B (which produces a float32), then do all math on that. > - some processors (ie. iphone) don’t have an integer divide.. I can't think when I've ever done divides with world coordinates! > - converting from float int is possibly the most expensive thing you can do on many machines due to having to write it to memory and read it back in after a very long stall. True on the current consoles, but it's not a general rule (e.g. x86). Also, if your alternative is float64, is there a fast path float64->float32? I've forgotten. > - does your engine need to be completely fixed point also? At some point I would think a lot of the coordinates get fed back into the engine. Again, I think 99% of the time you first take a relative position and then do all your math with that. I made it completely impossible to do maths with my world coordinates (for a variety of reasons) and it just doesn't seem to be a problem. But for all the reasons you mention, I do tend to use integers for stats when possible. Because at least when you get "add zero" problems they happen consistently :-) > If there was one thing I’d wish for from chip designers, its really fast int float conversion Yup, agreed (and I think my architecture does these pretty quickly - it was an important priority). But that's for very different reasons than dealing with world coordinates. > though doubles are seem pretty safe.

Well sure they’re safe as long as you use them like an int52 :-)

> I’ve never tried replacing floats completely with it. Have you done that on a project?

Sort of in StarTopia (because it was this bizarre bent world), though we committed so many other idiotic coordinate sins I’m not sure I’d hold it up as a paragon. All my other commercial games have been small single levels so precision wasn’t an issue. For my latest homebrew project I do use integers for all world coords though, and it works fine (it’s also on a hex grid, so X and Y are at 60 degrees to each other which hurts the brain somewhat). Although it’s just me on it, so take with the appropriate pinch of salt – you can survive a huge number of dumb things when it’s just one person.

> – there’s a lot of floating point power just going idle? floating processor and possible vector unit?

The amount of actual math you do with world coordinates is pretty trivial. As I say, first thing you do in any routine is take a relative value from object A to object B (which produces a float32), then do all math on that.

> – some processors (ie. iphone) don’t have an integer divide..

I can’t think when I’ve ever done divides with world coordinates!

> – converting from float int is possibly the most expensive thing you can do on many machines due to having to write it to memory and read it back in after a very long stall.

True on the current consoles, but it’s not a general rule (e.g. x86). Also, if your alternative is float64, is there a fast path float64->float32? I’ve forgotten.

> – does your engine need to be completely fixed point also? At some point I would think a lot of the coordinates get fed back into the engine.

Again, I think 99% of the time you first take a relative position and then do all your math with that. I made it completely impossible to do maths with my world coordinates (for a variety of reasons) and it just doesn’t seem to be a problem.

But for all the reasons you mention, I do tend to use integers for stats when possible. Because at least when you get “add zero” problems they happen consistently :-)

> If there was one thing I’d wish for from chip designers, its really fast int float conversion

Yup, agreed (and I think my architecture does these pretty quickly – it was an important priority). But that’s for very different reasons than dealing with world coordinates.

]]>
By: James Podesta/2011/02/28/tips-for-managing-multiple-coordinate-systems/#comment-1114 James Podesta Tue, 01 Mar 2011 00:32:05 +0000 I like to define different types for each coord space, even if they all just contain the same x,y,z members. That way if you call PositionGeoToLocal instead of PositionLocalToGeo by accident, the compiler will usually spot it. Note this does not in any way endorse C++ overloading of type conversion to do it "magically" for you - that way lies insanity. You can also go further. In general the only maths you should ever routinely do with global coordinates is (a) add local offsets to them (i.e. velocities) and (b) take relative positions from one to the other. So make functions to do that and then yell at people that go poking around inside them. Then you can change your global coordinates to something more robust than a float32, for example an int64. See rant <a href="http://www.eelpi.gotdns.org/blog.wiki.html#[[A matter of precision]]" rel="nofollow">here</a>. I like to define different types for each coord space, even if they all just contain the same x,y,z members. That way if you call PositionGeoToLocal instead of PositionLocalToGeo by accident, the compiler will usually spot it. Note this does not in any way endorse C++ overloading of type conversion to do it “magically” for you – that way lies insanity.

You can also go further. In general the only maths you should ever routinely do with global coordinates is (a) add local offsets to them (i.e. velocities) and (b) take relative positions from one to the other. So make functions to do that and then yell at people that go poking around inside them. Then you can change your global coordinates to something more robust than a float32, for example an int64. See rant here.

]]>