Hi All,
I tried this post in the OpenGL coding: beginner forum without getting a real answer. Do you mind giving a look to it?
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=271405#Post271405
Thanks,
Alberto
Alfonse actually answered your question, I think - and it matches the approach you’re trying.
Some related interesting info, and then thinking out-loud:
Some MMOs tackle precision-problems by dividing the world into bounding AABB, that have integer coordinates; basically virtual pivots. These pivots reset where the world is, according to the camera position. This seems to me mathematically the same as your “glTranslate(-1000000, -1000000, 0)” and “intPoint.X += 1000000;”. The difference, I guess, is how the precision can be lost (assuming intPoint.X is a 32-bit float). If you have some virtual integer pivots and integer camera-position major-coordinate ( “struct{ ivec3 ipos; vec3 fpos;} Position;” instead of simply “vec3 position;” ), maybe you can guarantee the user non-degradable precision in a wide range, without keeping everything as double-precision. Managing ivec3+vec3 coords can be nasty, so looking back at floating-point precision: 32-bit floats can contain any 24-bit integer, 64-bit floats can contain any 53-bit integer. So, with simple 64-bit floats for pivot-position and camera-position there’s no absolute necessity for a custom initial glTranslate() to have nasty maths with ivec3+vec3 tuples. Maybe a viable idea would be to replace all precision-degrading functions in the path (the whole MVP calculation) to use 64-bit or 80-bit floats.
Yet, the integer-pivots and having vertices in 32-bit float format be child-relative to such pivots seems to me as the best course of action. It can keep precision high with objects that are near regions-of-interest; a camera easily specifies its ROI. A segment-Any intersection also easily specifies its ROI. (you just need to have those ROI-defining items track/calculate their position with 64-bit floats).
[/white noise]
Thanks Ilian,
I didn’t understand that Alfonso was telling that my approach was fine.
ScreenToClient conversion is inaccurate by design, therefore I don’t care too much about precision here.
Alberto