Your wish is my command.Duality wrote:I remember posting a site where it had the actual code for the seamless planetary flight but I don't know if thats feasable or not.
And I don't also remember where I posted it at.
Anyways, there should be a sticky thread about seamless planetary flight instead of making making millions of threads about it.
Okay, I'll just post here the nature of the problems, in the hope of getting good ideas, links, or whatever, and so that all this stuff stays together in one thread.
Definition: You fly your ship to low orbit, and after 10 or 20 minutes of aerobraking in the stratosphere down to MACH 3 or less, you glide down to a landing strip and land like the Space Shuttle. Or at least that's how I'd envision it. And you get out of the ship, walk around, got through Customs, and grab a taxi home or whatever. "Seamless" means no switching between engines or data sets; or at minimum, no *visible* switching.
Schedule: It will happen when it happens, I guess. I imagine that at some point we'll get walkable bases into the engine, and later on we might bridge the gap and get the "flight" part. So it might be "seamfull" before it gets "seamless".
Problem Areas:
1) Space, Amospheric flight, Open space ground, and Indoor ground environments have very different requirements and constraints, which usually are addressed by different kinds of engines. Seamless spanning of these environments requires a degree of "universality" from the engine that may be very tricky to achieve.
2) Coordinate systems switching: OpenGL assumes there is a "world coordinate system", which is an arbitrarily chosen origin and rotation of a system of x, y and z axes where all things are positioned. Presently in VS that origin is placed at the center of the main star in any one system. In a game like Quake, the origin is usually somewhere in the middle of a "level". Just a matter of convenience.
Now: If we go from flying in space to walking around in a beach, we need to somehow move our origin from the star to somewhere near that beach. Reason is, the planet is spinning and moving in space, and you wouldn't want to update the coordinates of every dune and lizard tail at every frame, so you'd rather use a local reference, and consider the star a billboard moving through the sky, rather than the other way around. But the question becomes, at what point do we switch coordinate systems? Probably long before the ship lands, I'd say, as dynamically computing terrain LOD is heavy enough a load on the CPU, that we don't need to be pumping it through a star-referenced transformation matrix on top of it.
IOW, if we do NOT switch engines, our engine must be capable of switching coordinate systems.
There are two ways we could do this: Switching at once, or switching gradually.
Switching at once may imply a sudden freeze while all the geometry is either transformed or reloaded, as well as re-sent to the video card.
Switching gradually implies that we may have more than one concurrent coordinate system active, which in turn implies that we'd be rendering stuff in one coordinate system, then overwriting our OGL world matrix, then rendering the stuff in the other coordinate system. Personally, I like this last solution best.
3) Planet representation: Planetary LOD must differ radically from normal object (ships) LOD's. As you get closer to a planet, you getting closer to a particular patch on its surface much more rapidly than you're getting closer to the whole thing. Therefore, patches on the surface need to increase in level of detail (LOD) faster than other patches. Morover, as you get even closer, a particular sub-patch gets bigger faster than the other sub-patches. So we need to represent a planet like a tree or something, where each branch and sub-branch of the tree LOD's on demand (proximity), independently of the others.
It gets even more complicated: You might approach a point that is where the corners of 3 or more patches meet, so that this may require up to four patches LOD'ing up in unison.
And if that's not enough, the fact that neighbouring patches may NOT grow in LOD in unison, implies complex hacks to stitch the generated strips in two neighboring patches that have distinct degrees of subdivision.
4) Terrain generation: Presumably we'd have "scripted" planets, or planets whose surface geometry and textures come from files. Earth, Mars, and other planets in our solar system, for which NASA maps are available would certainly fall in this category. We'd also probably have planets that were fractally generated off line, but treated as "scripted" planets at run-time. We might also have planets that are generated upon entering a system, while you are passing through a jump point. And, finally, we could have planets that are only roughly generated while going through a jump point, but that automatically generate more detail as you approach them.
The latter approach woudl be the most desirable, IMO.
There are various algorithms that produce mountains, hills, continents. What we need, though, for believable terrains, is an algorithm that, in one shot,
A) can produce younge and sharp mountains, old and eroded mountains, mesas, cliffs showing strata, volcanos, canyons, craters, plains, deserts, small hills, dunes, fyords...
B) produces the same results every time you approach the same place in the same planet,
C) can increase the level of detail (e.g.: cuadruple data points per unit of area) on demand without changing the positions of existing points, and
D) looks realistic; --i.e.: mountains look like real mountains, not like "fractal mountains", if you know what I mean.
Allright, take it from here.