The World is Big and Round, and Why that Matters - Part 2

Yesterday I posted a bit about how the rounded shape of the Earth (and other planets) and the precision limits of the the single-precision (32-bit) floating point numbers used for rendering both offer challenges to performing rendering of a whole world.  I did a bit more investigation, and the book I mentioned yesterday does appear to have some approaches to the subject, so I will likely be purchasing it.  An hour of additional research only led me to one other detailed mention of the subject, a 2003 masters thesis from the Naval Postgraduate School that made reference to libraries that addressed the issue when used in conjunction with the specific GeoVRML-based environment being used there.

An unrelated challenge that springs from the size of the world is storage space.  That is, representing an entire world that isn't real-time procedural requires a lot of storage space.  Detailed elevation data alone could run into the hundreds of gigabytes.  Clearly, that is one of the advantages of approaches like fractals, that allow generation of detailed data for an area without dependency upon surrounding areas.  Unfortunately, a strictly fractal approach has definite drawbacks, which I've opined upon before.

However, that still leaves open the challenge of producing or storing data for an entire world.  One approach to meeting the challenge has occurred to me.  That is to combine one-time generation of coarse (global) data, which might only occupy a few megabytes of storage space, with more localized techniques when viewing areas in greater detail.  For example, coarse elevation, biome, and water data for a planet could be stored for a planet.  Then, when visiting a portion of it, procedural techniques could generate and cache a more detailed representation of the region visited.  I'll also note that vector data is often more compact than raster data.

And that's about it for tonight.  Goodnight, world.