Vega Strike Forums

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.

Your wish is my command.

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.

This is just a thought that popped into my mind about the coordinate problem: Why not make the camera/ship/persona the origin?

That was EXACTLY my plan, when I started working on my own 3D game engine, many years ago.

Should also be stickied as well.

Forgot all about that.

I'm not admin, but I agree: this subject comes up way too often not to.

there we go, stickied it is.

Thanks, Zay.

So, WRT having the world coordinates follow the camera. I suggested that long time ago, but the silence was so resounding I gave up. Before someone else calls this gotcha: There would be a problem with accelerations: When the player accelerates, it would be as if the universe is accelerating the other way, so the physics must take this into account. A simple vector subtraction, no big deal, but there it is.
For the same reason, there'd be a problem with physics if we allowed world coordinates to rotate. Turning your head you'd send the stars and galaxies tumbling about by centrifugal force. This would no be as easy to compensate for, so my idea was that the origin of world coordinates would track the camera's origin, BUT, the rotation of the world coordinate system would ramain constant, aligned with the rest of the universe.
Another superficial gottcha is that all objects, including stationary ones, must move relative to world coords when the player moves. Huge CPU load? Hardly: First of all NOTHING is stationary. Secondly, most geometry is in meshes in the videocard, in model space. Only the origins of objects need move. A vector addition is a laughable CPU load compared to the mere act of telling the video card to show the object at each frame.
And this method solves, wipes out, erradicates, the problem of having to switch coordinate systems ever. We can have contnuous 3D from extended inter-system SPEC flight to in-system flight to atmospheric flight to landing, walking, driving to another city, and ordering champagne at your hotel room. Whaddya say, devs?

Ehm... Chuck.

Did you forget your own analysis of current's 64-bit (56 mantissa) transform matrices? All objects in their own local coordinate system, even terrain features, a 64-bit matrix to place them, you got like a nanometer scale in light-seconds, IIRC?

We don't need to change that.

The real problem is collision detection: radically different algorithms, otherwise they would be too complex for realtime computation. So, switching back and forth, switching visual rendering algos, etc... it's the transition what brings all the trouble. Plus, inifinite-LOD spheres, etc, etc...

OK, it gives micrometer precision for light-hour off-center regions, but still.

No, no, I didn't forget about the double prcision. That's good, but it's only for planets and ships. In a city, you wouldn't represent the position of every house, tree, pigeon, car, and median marking on the road using doubles. You might have double precision representation for the center of each city block or corner, but most of the other data will be floats. And you'd probably want to keep track of the camera relative to city coordinates, not relative to the sun.
Now, you might say, "If we traverse the hierarchy from planet to city to city block, I can add position vectors and apply matrix rotations while automatically converting to double as I add to my double planet position vector. That's true, but it takes more time. Quite a bit more time, in fact.
Wheras, even if the camera's position is expressed as a vector of doubles from the sun, I only have to subtract once from the sum of the sun-planet and planet-city vectors, in double precision, convert the result to a float, and from then on process all city objects in float precision. Much faster.
And if you track the camera relative to the city's coordinate system, it's easier yet.

Having the origin centered on the player seems like an elegant solution to the coordinate switching problem to me.

OK, just to make sure, we are NOT talking about an FPS (or really a First Person Perspective) but actually the landing of the craft.

Those are orthogonal things: Landing of a craft can be done in 1st or 3rd person perspective. Not sure what your question is, but, for the record, *my* vision is: You're flying in space, appoach the planet at a shallow angle, feel the burn, glide down through clouds and past mountains, touch down on a spaceport landing strip, release parachutes, get towed to a hangar, jump out of the ship, walk through the space-port first to Customs, then to the exit, flag a taxi, go to a nice sidewalk cafe, order a cafe au lait, sit at a table under a shade, and watch the girls walk by, or read a book; or else go shopping, or solve a murder mystery, or find this electronics wiz your pirate friends recommended you to, who can modify your ship's transponder so that you can choose which faction it identifies you as. Or go home, if you own one in this particular planet. But you may need to take a bus or train if your home is not in the same city as the spaceport.

It's frightening, chuck, that the more you talk about this stuff, the more you make me want it. Me, the guy who just wants to fly a ship and sell cargo, and not have to worry about landing or anything of the like.

Actually you wouldn't worry about landing on the planet, most of the time, but dock with the space elevator station, instead, and take the elevator down. Much cheaper! In this case, however, if you want that electronics whiz that works for the pirates to mod your ship, he couldn't, given his records, go up to the space elevator station without raising suspicions; or do the work there, with surveillance bots all over the place

chuck_starchaser wrote:In this case, however, if you want that electronics whiz that works for the pirates to mod your ship...

You seem to think that I'm the one looking for the whiz, as opposed to being the one who is the whiz

I'm not a combat fan (though I do enjoy an occasional fight), and much prefer to stick to the quieter side of things working with everyone and no one at the same time. Pirates and Confed alike.

Anyway. Back to the topic

But it's good to know that we don't have to worry about landing!

It seems like having space elevators would actually be a good intermediate step in terms of developing it- dock at the space elevator like a normal station, descend to the surface.

Then, the planetary flight mechanism could be implemented, while the extant space elevator mechanism would probably remain as the preffered means of docking with planets.

chuck_starchaser wrote:Those are orthogonal things: Landing of a craft can be done in 1st or 3rd person perspective. Not sure what your question is, but, for the record, *my* vision is: You're flying in space, appoach the planet at a shallow angle, feel the burn, glide down through clouds and past mountains, touch down on a spaceport landing strip, release parachutes, get towed to a hangar, jump out of the ship, walk through the space-port first to Customs, then to the exit, flag a taxi, go to a nice sidewalk cafe, order a cafe au lait, sit at a table under a shade, and watch the girls walk by, or read a book; or else go shopping, or solve a murder mystery, or find this electronics wiz your pirate friends recommended you to, who can modify your ship's transponder so that you can choose which faction it identifies you as. Or go home, if you own one in this particular planet. But you may need to take a bus or train if your home is not in the same city as the spaceport.

Heck, well count me in. I was thinking that the "Vegastrike:Planetside" projet was dead but its good to see its not. What can a noob do to help out.

You're helping out just by adding your voice. Devs need feedback and encouragement, as much as helping hands. But if you want to get involved in development, there are a zillion ways known, and probably another two zillion waiting to be discovered. Programming, Art, Models, Writing, Documentation, PR, whatever. Specifically for planetside, we'll probably need an engine. We were toying with the idea of using Ogre 3D as the rendering back-end for Vegastrike. Ogre 3D is basically just a renderer of an engine, but very well designed. If we do that, we could pick a FP walking engine that also uses Ogre 3D as the back end. I believe there are several. The guy who started the work incorporating Ogre seems to have vanished, though; and didn't leave any of his work with us... ^^

@Halleck:
Very true! Say, Halleck, you're a modeller, eh? Whaddya say we work together on, say, 4 models of space elevators? I can dig around for info, sketch stuff on paper, or even in Wings, but very sketchy; I'm no pro at it.
I could help creating the textures, also. Would you be interested?

chuck_starchaser wrote:@Halleck:
Very true! Say, Halleck, you're a modeller, eh? Whaddya say we work together on, say, 4 models of space elevators? I can dig around for info, sketch stuff on paper, or even in Wings, but very sketchy; I'm no pro at it.
I could help creating the textures, also. Would you be interested?

Heck, I'll help at it, if you want

I've done some 3D space-craft modelling, and I'd figure a "boxy" elevator style might even be easier. Texturing, though, I'm not the best at, but am willing to learn and die trying.

I'm up for anything. Lemme know what you need, Chuck.

I'm rather mediocre at 3d modelling. I get an easy break with the elite mod stuff.

I'd take coffeebot up on his offer first, he seems to be much more of an artiste than myself.

As to how I'm visualizing the space elevator... after your description of the nanotube cables being 'as thin as pantyhose', I can't help but imagine a space platform with miles of pantyhose stretching down to the planet's surface.

haha...I had missed the pantyhose comparison, but, really, that's almost what I was envisioning, myself. My question is: What's defending those "pillars" from a listing starship or rogue blaster fire?

The sheer sheerness of them protects them. You can't see them, and they won't bounce radar either. But if you're flying towards them, first you get a warning by radio, soon followed by a long-range laser blast that turns you to aerosol before you touch the cables. Anyways, there should be a number of cables per elevator, on like a grid spaced apart several miles. And each of the individual cables, would be made up of a couple of dozen pantyhoses.
Allright, CoffeBot; --Thanks, first of all--; I'll start googling up SE concepts, put them in a folder, and come up with a rough sketch. There's an elevator thread, already in this forum, that we can use, so we can leave this one to the topic of seamless flight. I'll post to it later today. I still have work to finish up for wcu, so it'll be a sloft-start elevator project. Actually, I'll post some ideas to that thread now, to bump it up from wherever it is, and put my first coffe to work...

I've been working on the subject like six month ago, and I may have some input. however I worked on it in Ogre, so some of your problems were already solved in my case. If VS migrates to ogre, those solution will be implemented. It it doesn't, those solution may be good leads to find solutions using the existing engine.

1) different needs for different engines.
When I tried to render planets with dynamic LOD? I designed them as an object. basically, it's like a mesh that tracks the camera position, and generates its own LOD accordingly. So we don't have to switch engine, just make an object that works differently from the rest, and uses the optimisations we normaly use for an engine, but locally.
The problem is poly count. If you generate a planet with full detail, you rapidly end up with trillions of polys that aren't reall usefull. I guess the best solution would be a function somewhere that tracks poly count, and reduces the far clip, or transforms far objects into billboards, and therefore maintains an acceptable poly count. the more detail you have near you, the closer low detail objects get. In space you can see ships and planet at the other side of the system, and on the ground, the trees in the background, become billboards.

2) Honestly I didn't go very far in how VS currently handles local coordinates, but Ogre takes its coordinates from a tree. Moving the ship from a space reference to a planet reference isn't a hard thing to do : just take the required leaf, and attach your ship to it. The transition takes virtually no loading. I'll have to check for the camera though, as I think it remains in world coordinates.

3) That's exactly the approach I took in my attempt (which failed mainly because I lost the code in some OS reinstalation), and it does work (I didn't test it down to ground level though). You were adressing the problem of adjacent patches with different LOD levels, and the solution is there :
http://www.flipcode.com/articles/articl ... maps.shtml
It's an article about geo-mipmaps, and the exact same solution can be done in a sperical terrain. As you can see, you just have to find the neighbors in the tree, and then if they aren't at the same LOD level, a simple vertex rebinding solves the buggy looking terrain. Fast and effective. I hope VS used indexed vertexes.
However, it would be more simple if we make sure two adjacent LOD patches don't differ in LOD level by more than 1, as it might look awfull to correct more than 1 LOD level with this technique.

4) implementing multiple types of planet isn't that hard. We'll definitely need scripted planets for the sol system, and procedurally generated planets for the rest.
I believe geometry should be generated only on demand, and deleted when not needed (the data can easily become HUGE). And it's not hard to implement with a tree-like approach. When we get at twice the distance that would require LOD change, make a new branch. When we get to the LOD distance, display that branch. When we get further, we hide that branch, and use a lower LOD. When we get at say 4 times the LOD distance, we delete the branch.
However, some control will have to be made. If we allow to many divisions per frame, the FPS drops. If we don't allow enough, the LOD can't generate fast enough (which I believe is better in most cases). On my attempt, I allowed one division per frame, and the planet took a couple seconds to generate the required LOD for a high orbit on startup.

gezz, I wish i could start working on this now, but it will have to wait until october...... :,(

and btw, shouldn't someone also make a sticky on space elevators ? ^^

If the data is deleted, would that mean that different visits to a system would yield a different system? Or are the procedures designed to prevent that?

the procedures will have to be designed to prevent that ! if it doesn't, imagine the multiplayer part ! you're landing your craft next to your buddy's, but as the terain is different, you see your buddy walking 100 feet over you, because he landed on a mountain, and you landed on a plain, at the very same position !
On my attempt, I wanted to use perlin noise, which is good for chuck's A, B and C criteria for a good procedure. I don't know about the D though, I never walked in a perlin landscape
but it's main strenth is that it generates the same result if you give it the same set of parameters for a given position. and it can generate as much detail as you want.