G33X Nexus Entertainment > Precursors
RE: Models, screenshots, etc... in Developers' Discussion
contingencyplan:
Hrm. This sounds good, but I still want to see the implementation on the RBI / RBF before I can sign off on this. I think this will work, thinking about it, but we'll have to see it in action. And we still have to consider the cost of converting it to a float / double / long double. Likely the latter two - if we convert it to float, we'll still be running into the jitter issue, methinks: the jitter is caused by rounding and lack of precision. It doesn't matter how much precision we have when storing the value in the RBF. What matters is how much precision we have after storing it in memory as a floating point value (not necessarily a float).
Oh, and if we only have 8 bits, then we have a precision of 10 ^ -128 to 10 ^ 127, since we need to account for positve exponents too. But we'll see. I still think doing something of a fixed point implementation might be a better way to go about it, since we can guarantee to have a certain precision about what we're doing.
Morgul, any thoughts on when we can get a hold of the RBI code?
whitelynx:
--- Quote from: contingencyplan on October 19, 2006, 04:41:16 pm ---Hrm. This sounds good, but I still want to see the implementation on the RBI / RBF before I can sign off on this. I think this will work, thinking about it, but we'll have to see it in action. And we still have to consider the cost of converting it to a float / double / long double. Likely the latter two - if we convert it to float, we'll still be running into the jitter issue, methinks: the jitter is caused by rounding and lack of precision. It doesn't matter how much precision we have when storing the value in the RBF. What matters is how much precision we have after storing it in memory as a floating point value (not necessarily a float).
--- End quote ---
The issue with floats only arises when the values are relatively far from 0; ie. really big positive or negative numbers. If we're converting into a localized coordinate system (such as one centered around the player) the stuff that's far away doesn't matter because it'd be so small on the screen, so we don't care if it jitters. If it's closer, then it has good precision. Besides, float is all that CS and the hardware understand.
--- Quote ---Oh, and if we only have 8 bits, then we have a precision of 10 ^ -128 to 10 ^ 127, since we need to account for positve exponents too. But we'll see. I still think doing something of a fixed point implementation might be a better way to go about it, since we can guarantee to have a certain precision about what we're doing.
--- End quote ---
Actually, as I said above, we don't need positive exponents at all. RBI will handle that, since we have an effectively infinite range for the mantissa. The only thing we can't do with RBI currently is non-integral values, which is what the exponent would be for.
contingencyplan:
--- Quote from: whitelynx on October 19, 2006, 04:56:25 pm ---
--- Quote from: contingencyplan on October 19, 2006, 04:41:16 pm ---Hrm. This sounds good, but I still want to see the implementation on the RBI / RBF before I can sign off on this. I think this will work, thinking about it, but we'll have to see it in action. And we still have to consider the cost of converting it to a float / double / long double. Likely the latter two - if we convert it to float, we'll still be running into the jitter issue, methinks: the jitter is caused by rounding and lack of precision. It doesn't matter how much precision we have when storing the value in the RBF. What matters is how much precision we have after storing it in memory as a floating point value (not necessarily a float).
--- End quote ---
The issue with floats only arises when the values are relatively far from 0; ie. really big positive or negative numbers. If we're converting into a localized coordinate system (such as one centered around the player) the stuff that's far away doesn't matter because it'd be so small on the screen, so we don't care if it jitters. If it's closer, then it has good precision. Besides, float is all that CS and the hardware understand.
--- End quote ---
They don't even understand double? Honestly, I don't think adding the ability to consider coordinate systems as doubles would be very hard; just have an #ifdef to switch between them.
--- Quote ---
--- Quote ---Oh, and if we only have 8 bits, then we have a precision of 10 ^ -128 to 10 ^ 127, since we need to account for positve exponents too. But we'll see. I still think doing something of a fixed point implementation might be a better way to go about it, since we can guarantee to have a certain precision about what we're doing.
--- End quote ---
Actually, as I said above, we don't need positive exponents at all. RBI will handle that, since we have an effectively infinite range for the mantissa. The only thing we can't do with RBI currently is non-integral values, which is what the exponent would be for.
--- End quote ---
Ah, missed that part, sorry. Yeah, that should work then. Like I said, my main other concern is speed of conversion between these formats, especially if we're doing such conversions frequently (I'd suspect we'd be doing them numerous times per second, especially when there's a BUNCH of stuff on the screen [e.g., major battles]).
whitelynx:
--- Quote from: contingencyplan on October 19, 2006, 05:12:57 pm ---They don't even understand double? Honestly, I don't think adding the ability to consider coordinate systems as doubles would be very hard; just have an #ifdef to switch between them.
--- End quote ---
They have support for double in certain classes (see http://crystalspace3d.org/docs/online/api/group__geom__utils.php) but those classes aren't used in most of the engine proper, and we'd probably have a tough time convincing them that there was a need for #defines like that... There doesn't seem to be an option in configure to enable it currently.
After talking to the devs, they agree that there should be some work put into getting a better coord system into CS, but thebolt says that double probably isn't the way to go... Even if we did use double, it wouldn't solve much... it is still as non-linear as float is, as far as precision; it just wouldn't start to show the jitter as soon. (see http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BA%20matter%20of%20precision%5D%5D for more info, and check out the OffendOMatic while you're there)
--- Quote ---Ah, missed that part, sorry. Yeah, that should work then. Like I said, my main other concern is speed of conversion between these formats, especially if we're doing such conversions frequently (I'd suspect we'd be doing them numerous times per second, especially when there's a BUNCH of stuff on the screen [e.g., major battles]).
--- End quote ---
That is a valid concern... I'm tempted to simply go for a fixed-point implementation where the rightmost n digits of the RBI are beyond the decimal point (multiply the RBI by 10^-n) since it would simplify calculations and still give us a usable infinite coordinate system. (as long as we ignore the performance impact of extremely large numbers)
Of course, there's still other solutions we can explore... we could go with a paged memory-influenced algorithm, where we have a "sector" we specify with an int 3-vector, (so we basically have a 3D grid of sectors, kinda like a rubiks cube) and then float coords within that. The size of the sectors would depend on how much distance we can squeeze out before it gets jittery. Of course, this then brings up the question of what to do when we approach boundaries... my instinctual solution in this case would be to simply use sectors and portals, since that's what they're made for. :P
Edit: After reading up on that Tom Forsyth page, I'm starting to think a straight 64-bit int might be the best way to go... as he says, using a 64-bit int as a fixed-point number "gets you to the furthest distance of Pluto from the Sun (7.4 billion km) with sub-micrometer precision." That should be enough for in-system coords at least...
What do you guys think?
contingencyplan:
I'm gonna look at some fixed-point implementations online, see if we find any of interest.
DDJ article on a fixed point implementation: http://www.ddj.com/dept/cpp/193200474
The implementation described: http://www.mentor.com/products/c%2Dbased%5Fdesign/
Freaking long article on rounding algorithms: http://www.diycalculator.com/sp-round.shtml
(For those who don't know, DDJ is Dr. Dobb's Journal, a kickass publication for programmers. I'm going to be renewing my subscription soon, since the CS dept stopped having the free mag handouts a while back. I'd strongly recommend that everyone here subscribe - not every article is for you, but you oftentimes learn something new from reading through them.)
Navigation
[0] Message Index
[*] Previous page
Go to full version