First question is what is the maximum x,y,z cordinates that I can use in irrlicht?
Second question what would be a good scale to use. For example if I move an object from the orgin to 1 foot in the air. Would I want to move it by (0,1,0) or (0,100,0). I realize I can do both but I would think that 1 would be a poor choice becuase to move small amounts I would loose accuracy due to floating point precision. If I do 100 it seams like this would be a bit over kill?
Third question is what is the maximum values that a point can be at, for example if I have a point at the orgin and I want to move it to the farthest corner possible? Also what happens if I move beyond the maximum value would I get an overflow that is just ignored and warp to the other side or would the application crash. (assuming I don't change any behavior of the engine)
Scale and world size questions
ohhh f32-max should hopefully give me plenty of space to play around in.
However (it could of just been the skybox) I was playing around with the terrain example. I set the camera way out there (2 mil+) and it scenery (sky box) would jump as I move the camera around. But if it is just the skybox I can easily get around that.
However (it could of just been the skybox) I was playing around with the terrain example. I set the camera way out there (2 mil+) and it scenery (sky box) would jump as I move the camera around. But if it is just the skybox I can easily get around that.
The problem that you will run into is that the floating point types are very precise near 0, and are increasingly inaccurate the larger the value. A standard 32-bit float can only accurately represent about 6 digits with any precision.
If you put objects at a great distance from the origin and try to move them by a very small amount, they will not move at all or will move by the wrong amount. As an example, if you put an object at (0, 0, 1e6), and then move it by (0, 0, .1f) it will move to (0, 0, 1000000.125f). The error is .025f. If the object was at (0, 0, 1e7) and you moved it by .1f, it would not move at all and the error would be 1.f [1e7+.1f=1e7].
If you are going to use very large worlds, you should do something to avoid the precision problems of floating point numbers.
If you put objects at a great distance from the origin and try to move them by a very small amount, they will not move at all or will move by the wrong amount. As an example, if you put an object at (0, 0, 1e6), and then move it by (0, 0, .1f) it will move to (0, 0, 1000000.125f). The error is .025f. If the object was at (0, 0, 1e7) and you moved it by .1f, it would not move at all and the error would be 1.f [1e7+.1f=1e7].
If you are going to use very large worlds, you should do something to avoid the precision problems of floating point numbers.
Hmmmm......
I didn't want to do this but it looks like the best solution then would be to create a huge world and break it into a grid (which I already planned on doing).
But then the grid where the main player is at will be at the orgin and if the player switchs to a new grid then the new grid will be centered at the orgin. (with the world moving with it)
I didn't want to do this but it looks like the best solution then would be to create a huge world and break it into a grid (which I already planned on doing).
But then the grid where the main player is at will be at the orgin and if the player switchs to a new grid then the new grid will be centered at the orgin. (with the world moving with it)