Geomorphing
We now have 12 detail representations of the terrain mesh, organized in a terrain patch system. Obviously we don't want to draw them all on top of each other because that would just be, well, plain stupid, and not look very good. So we need to select between them in run-time based on the distance from the camera.
We also want some way of blending between the new selection and the previous selection to avoid a "popping" artifact when we switch between them. One solution would be to alpha blend between them in the pixelshader, over a specific blend region, but then there could be cracks visible in cases where the two meshes differ greatly.
The solution we ended up using was geomorphing. By geomorphing we mean gradually adjusting, or "morphing," the vertex positions of the higher resolution mesh to align with the lower resolution mesh, based on distance along a specific transition range. For this to work well without causing any cracks we need the morph target be exactly on an edge of the lower resolution mesh.
Note that this technique actually creates T-junctions along the edges of meshes of different LOD, but in practice this hasn't proved to be a visible problem.
Figure 4: Morphing edges in the a high resolution mesh to align with a low resolution mesh
The triangle trees actually let us to this morphing very elegantly, without the need to store any additional information. Consider that the child terrain patch containing the higher resolution triangle tree partially cover the parent terrain patch containing the lower resolution triangle tree. If we traverse both the lower resolution tree and the higher resolution tree in parallel at the same time, then we can easily generate morph target information for the high resolution tree, based on the low resolution tree. This works conveniently since a higher resolution tree is always a superset of the lower resolution tree of the same area.
Figure 5: Traversing the lower resolution tree in parallel with the higher resolution tree identifies the morph targets
|
Printer-Friendly Version
/Linus
Twitter: @BlombergLinus
Indeed, the game that inspired me at this time was Paul Woakes' Mercenary a year later in which you crash land on a planet and then have a number of adventures within that city as you seek a way to escape. This type of open world gameplay was new to me back then and may well have invented the genre - certainly, more so than Grand Theft Auto. The later sequel Damocles had you flying from planet to planet within a star system, giving a sense of enormous empowerment. This predates Frontier: Elite II by several years, which struck me as being too big, dry and purposeless. Flavien Brebion's Infinity (The Quest for Earth) is technically impressive - but ultimately as cold and detached as Space Engine or the Universe Sandbox. At times EVE Online veers too close to being as boring as a spreadsheet with a fancy sit-back-and-watch screensaver attached. The launch of Dust 514 for the PS3 just highlights the lack of cohesion in the game - you really ought to be able to land on a planet in your own ship rather than delegate the fun to some mercs and pay for the priviledge in the process. For a long time space games were out of vogue and it is interesting to see so many get funded through recent Kickstarter appeals, including Elite: Dangerous - which, in later versions, promises to let you land on planets.
However, as someone keen on this genre and finding nothing in the market since the release of Damocles, my yearnings for an adventure game set as much on the surfaces of astral bodies and inside spacecraft as much as between the stars drove me to work on the tools I thought I would need if I were to attempt to write such a big game by myself. Suffice to say I have put decades of research into boosting my productivity. C++ horrifies me: such an awful mish-mash of poorly concieved features wrapped in an error-prone syntax. Substantial use will need to be made of both kitbashing (assembling complex models from phasing the geometry of "prefabs") and the procedural generation of those prefabs. Miguel Cepero's work Procedural World looks a lot better than I need my game 'Universe' to look. Indeed, I would happily accept the rudimentary charm of Damocles if that was all I could manage, after all there are a lot of other aspects to the game that I think are more important than its presentation... I don't like this modern trend of squandering computational resources on special effects that have no impact on gameplay, whilst physics and AI get short-shrift again.
So, finally I wend my way around to my question. How would I apply a terrain solution like yours that depends on square tiles to a spherical planet? I don't think Latitude and Longitude will work as that will stretch stuff too much and result in awkward triangles at the poles. An isocahedron-sphere is nice, but relies on triangles. Is a (bloated) spherified cube the correct approach? What happens to the horizon? Will it appear to curve with more altitude? Should I trust my instincts and just use polar coordinates and a heightmap centred on the core of the planet? Any advice or pointers to research papers would be appreciated. I'd like to read up on this subject now whilst I'm implementing my programming language.