Query:Best Method To Overcome Floating Point Error
Blitz3D Forums/Blitz3D Programming/Query:Best Method To Overcome Floating Point Error
| ||
| Hello, What is the best way to handle floating point error, in particular in large outdoor environments where the movement step of a unit is very small compared to the world coordinates? Would it work to have a grid of pivots widely spaced apart (10,000 units for instance) which the moving unit parents itself to when within said distance and then using local coordinates for positioning instead of global coordinates? Thanks, from Matt |
| ||
| use string maths if you are going for accuracy alone or change your scale if your steps are too small! yes the grid should work too. Also I have heard moving the terain and everything in it around the camera instead of actually moving the camera helps with floating errors. |
| ||
| string maths is no use to me if the blitz entity positioning commands are only single precision and don't accept strings. I'm not worried only about the camera's position but also the other entities which could be very far away but need to be positioned accurately as well - as they may be interacting with each other. I guess my question is really - will blitz convert my local coordinates for each entity relative to pivots which may be far from the origin into global coordinates when it performs its internal calculations for move/translate/rotate/position entity? For example: global coordinates x = 100,000.0 dx = 1.0 x+dx = floating point imprecision however if I parent the entity to a pivot which is at x=99,900.0 then the local coordinate would be at x=100, and the dx would still be 1 - would I still have a problem with floating point imprecision or would the issue be resolved. |
| ||
| ...or would the issue be resolved. The issue remains. The small, local x is now more accurate. But it must eventually be combined with "100,000 sized" values when Blitz deals with the rest of the world. So the inaccuracy returns. That's why you are better off with a system which moves the currently active part of the world to the origin. |
| ||
| Use normalisation, i.e. when the camera is greater than, say, 20000 units from 0,0,0, move it back to 0,0,0. Note the distance that the camera has moved on each axis, and move every other entity by the same amount. Probably find it easier to attach everything to a pivot except the camera, then you just have to move the camera and pivot. |
| ||
| There must be methods, similar to GfK suggested for example, to reduce the 'scale' of your 'play area'. Having a 100 000 : 1 scale just doesn't sound like a good thing for any situation to be honest. Changing the absolute distance wont make any difference because the scale would still be the same, but changing the relative distances will, so you'd need to find a means of compressing everything together in ACTUAL 3D space, whilst ensuring that it all looks as though it's the 'correct' distance/size. I believe it's possible to change the Camera entity scale, but to be honest, I'm not 100% sure on how this works. In theory, though: Your 'world' is currently at a scale 100 000 : 1 Modify all the distances and sizes to reflect a 1 000 : 1 scale Now things will look odd and too close together and/or too big Now Scale the camera entity to 1% of its original size. So now, only the camera has the scale of 1 000 000 : 1 now, which, if you configure the drawdistance and fog range to limit to 1000:1 you should have no problems. |
| ||
The small, local x is now more accurate Yes, I've noticed the floating point error has been addressed in some way or another. I no longer get severe camera jitters when I'm 5000 units away from 0,0,0. Not sure what Mark did but it was a very welcome fix. |
   |