Timeline for What's the largest "relative" level I can make using float?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 12, 2022 at 21:21 | history | suggested | Salvatore Ambulando | CC BY-SA 4.0 |
fixed typo in 16 384 (changed word to synonym for min char count)
|
| Jan 12, 2022 at 21:20 | review | Suggested edits | |||
| S Jan 12, 2022 at 21:21 | |||||
| Jan 30, 2020 at 2:32 | history | edited | DMGregory♦ | CC BY-SA 4.0 |
Math formatting on exponents
|
| Apr 30, 2019 at 8:09 | vote | accept | jokoon | ||
| Jul 18, 2018 at 15:47 | history | edited | DMGregory♦ | CC BY-SA 4.0 |
Detail & formatting
|
| Apr 6, 2018 at 12:26 | comment | added | DMGregory♦ | @jokoon There are lots of ways to avoid that, but the comments aren't the best place to hash it out. Try asking a new question if you'd like to explore this in more depth. One simple method is to store all positions relative to your chunk, and keep your chunks spaced at representable numbers over your range. Then repositioning chunks never rounds the chunk positions, and ground truth positions are available for all chunk contents by summing the chunk position & position relative to chunk. | |
| Apr 6, 2018 at 9:46 | comment | added | jokoon | I still am wondering what does it mean to recenter the world for a graphical API. If I have a big chunk of instanced (or not instanced) geometry, is it still safe to do it? I guess it means translating ALL transforms, but if I do this several times, isn't there a risk of floating point precision loss? | |
| Jun 27, 2017 at 16:27 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
Fixing digit spacing
|
| Oct 17, 2016 at 23:05 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
Typo
|
| Oct 17, 2016 at 21:15 | history | edited | DMGregory♦ | CC BY-SA 3.0 |
Adding note on changing unit size
|
| May 24, 2014 at 11:45 | comment | added | DMGregory♦ | It will depend on the numerical stability of the algorithms employed by your rendering and physics systems - so for a given codebase/engine, the only way to know for sure is try a test scene. We can use the table to estimate maximum accuracy (eg. A camera 16 km away from an object will tend to see at least millimetre-sized errors, so your zoom should be wide enough to keep those smaller than a pixel - if the zoom needs to be tighter for your game then doubles or some clever math may be required), but a chain of lossy operations can run into problems well before this hypothetical limit. | |
| May 24, 2014 at 7:30 | comment | added | jokoon | the question is, how big that re-centered region can be ? if for example in my game I want to shoot at a high distance with a strong zoom, do I absolutely need to use double or is float enough? isn't it better to recenter according to a quad tree or some tile algorithm ? | |
| May 24, 2014 at 6:35 | comment | added | API-Beast | What about using fixed point coordinates? Maybe with 64 bit integers if necessary? | |
| May 24, 2014 at 4:47 | comment | added | Floris | Recentering is definitely the way to go! | |
| May 24, 2014 at 0:59 | history | answered | DMGregory♦ | CC BY-SA 3.0 |