My technical concept: Planet landing & other stuff.

[razorjack]

Hello,

I've readen some topics about the implementation of smooth planet landing. I haven't readen everything so I don't know if a practical solution was found or not.

If not, then I would like to contribute with my solution. I've done some researches on a simple and reliable geometrical structure. A brief descripion of this structure is:

- All topography is splitted up into segments having their local coordinate systems
- Segments can be subdivided into partitions. Doing so, all partitions will be scaled up again so they shouldn't become tiny.
You can repeat this subdivision/scale procedure as much as you want. The size of the topography will grow exponentially. E.g. I'm using 21 levels to describe 50.000 Mpc ( nearly the extent of our universe ).
- The segments will be loaded selectively.
- Hugh objects like planets, stars, galaxies are stored in higher levels. All the other ones are stored in the last level or in lower levels.
- Objects with high acceleration(to lightspeed or above) are migrating between different levels.

Some problems are solved automatically:
- No loss of percission. Don't need double variables.
- I've made this concept especially for procedural generation. E.g: if you are sampling up terrains continuously.
- works like visibility culling & has some LOD like effects
- Local coordinate orientation. Some problems like gravity are solved.
- Rendering is performed in multiple passes into alpha blended layers. To increase the performance you can redirect some layers into skycube(s) to use them in other frames.

I've written a small prototype for a scenegraph ( C++ ). I've concentrated myself on the organisation of segments (un-/loading & visibility culling).

Maybe you are interested. I'll give a link for my demo later.

[fuzzy_memories]

nice one! From what i understood of it it looks like a pretty simple concept, but effective. Did i read right when you said you managed to get a C++ concept of this working? If so could we have a small graphical screenshot/movie? Maybe i'm just getting too excited but it seems like pretty groundbreaking stuff!

[razorjack]

I've managed some parts of the concept above.
I plan to release a demo & sources of it by the weekend after I've corrected some bugs.

Hope you don't expect too much. This program is more a conceptional draft than a real engine. The main problems I had to manage were to detect all visible segments of each level, generate them and store them as long as they are needed. After that it calls drawing callback routines.
The drawing itself is far away from that which you see in "infinity: Quest of earth".

[fuzzy_memories]

Still, sounds pretty good.
I had an idea and i was wondering if it was possible (and if you wanted to implement it, don't hesiatate)
Is it possible, using the engine you've semi-developed so that as you reach the bottom layer (hope i got this right) it generates a random mesh? and there could be one fixed mesh, similar to the planets in Evochron alliance.
Hope i helped,
Fuzzy

[razorjack]

I didn't play Evochron. What does fixed mesh mean?
There are different algorithms to create planets. I've heard that "inifinity" uses a cube to sphere mapping. My algorithm is somewhere similar. A trick is that you can easily subdivide a quad into subquads.


Generally I've kept the possibility to organize the contents of a segment in each way you want.

My idea was to keep a simplified content in a parent segment(like starpositions, or anything). After loading a partition the local contents will be sampled up using a pseudo random generator. The seed value can be taken from available data like segment indicies(after you hash them together).

The terrain can be computed using perlin. I want to combine it with diamond square algorithm to sample up heighmaps itteratively:
see also http://www.gameprogrammer.com/fractal.html
Quadtree based LOD terrains are useful in my case. Because their data structure is suitable for the principle of segment partitioning.

Currently I don't have much contents inside the demo. The terrains aren't implemented. I want to rewrite parts of the demeter terrain engine to paste them into my source. The problem is that I don't have enough time to work at this project. It's one of the reasons why I want to release it's source.

[fuzzy_memories]

Well i think i sort of just made up the "fixed mesh" terminology, but basically, it means a pre-set thing (like a base that is always there, and isn't randomly generated with the rest) almost like Cephid_17 in vegastrike, i think that is always somewhere near the middle?
As for Evochron, you could download the demo if you want (only gives you 1 hour of play, but it's good just to see the realtime planet rendering)

[razorjack]

Now I got what you mean.
Like I said I want to leave the possibility to let the coder decide if he wants to generate topography or if he wants to have some static objects. The scenegraph itself doesn't generate anything. It offers overrideable procedures for segment loading, where you can put your own code.

-------------

I've uploaded two exsamples on the following link:
http://www.razorjack.de/PSD.zip

The one is GUItest. One interesting element is the terrain heighmap sampler(three fields below). The main functionality is to scale up the geometry procedurally. Later I'll use it for the planet surface generation.

The second example is PSD. If you click "test scene" you'll see the universe model. You can travel through the universe by holding mouse buttons and moving the mouse.
- important buttons are "climb" and "descend". Use them if you want to change the layer of the camera. This option influences the detail level and camera velocity.
- other buttons are to show and hide the reticles. Reticles are useful if you want the see how the scenegraph works. Every reticle octet is representing a visible segment.

Note: Stars are visible at level 17. Starsystems are visible at level 15. You can approach a star and land on it (planets will use the same algorithm). A star becomes a sphere at level 9.

Following things aren't bugs:
- If you approach a star you will see more than one starpoint. It's because I'm drawing the starpoint in more than one layer.
- If you approach a reticle line at a very near distance the line jumps wildly. It's because I don't use Z-clipping at near distance. You can turn off reticles if they get too wild.[/url]

The algorithm of the scenegraph is a little bit different from the concept I've posted above. I'm using also embedded segment systems which have their own segments. Currently there are only three systems inside the example:
- the universe
- a star system
- star hull

Later there will be also these ones:
- planet hull
- galaxy
- star clusters
- galaxy clusters
- nebulas with embedded starsystems

[robothead]

if you are talking about having seamless planetary flight in vegastrike, then that idea has been discussed to death before on this game.

if this feature was to get implemented into this game, would players spend hours and hours exploring an entire planet from terrain to terrain in the same spot in the universe and system or do some space trading related activities such as hauling cargo, pirating, killing pirates, doing something to get more cash?

besides planetary flight woulden't make any sense because large majority of space crafts don't have aero dynamic like wings and will fall to a planet like a rock if it did entered the atmosphere.

but it'sa just me because i get more excitement from traveling into different frindges into space than i do on a planet.

[Vector_Matt]

besides planetary flight woulden't make any sense because large majority of space crafts don't have aero dynamic like wings and will fall to a planet like a rock if it did entered the atmosphere.

Unless they have anti-grav stuff for takeoff and landing.

[razorjack]

You're right. I made some negative experiences with X3 even if there aren't any seamless planetary flights.

But I think the problem isn't the size of the topography itself.
In X3 for example there are much things like automation and game controls which are too complicated and mostly useless. Such things makes the gameplay difficult, too.
Of course there are problems to explore such a huge world. But you can fix something this way: 99,99% of planets and starsystems don't have any valuable ressources and no live - because of diverse circumstances like high radiation(near supernovas) or unstable conditions. Their existance could be more decoratively.
Maybe it's also usefull to move parts of the gameplay on planets instead of expanding the gameplay. This would relax the situation additionally.

[Moe479]

take a look at elite 2/3 ... that worked even smoth on 486 cpu's and the detail could be incresed dramatical to use the current cpu's horsepower

the only problem i see is that wee need a lot of high res highmaps and corlormaps and some cloud and weather engine to have some nice lookin athmospherical effects ^^

the worrys about that it will be a mostly unused feature are just right if u think vegastrike with the current content ...

ever thougt about a mod that just covers one system?

what when we never reach the technolegy to leave our system??? .. who cares ... its still big enough! how many rocks of e serois size obiting jupiter? we still dont know exactly!
( http://www.ifa.hawaii.edu/~sheppard/satellites/ )
we have recently detected a 10th planet/planetoid like body out there ... what makes us that sure that there arent anymore?

to be honest a one-system-'realety'-mod is much more intresting than jumping trough thousands of systems without having anything to explore in deatail ...

[razorjack]

A mod of vegastrike which is placed only in one system could be a good decision to start with.
I'm thinking of the beginning of the space colonization aera by humans. There is very much room to start a real cool RPG game of it. The fact is that the space is currenty unexplored. The humans would begin to regard the space from an economical view and not only from the scientifical. And of course you can develop a nice storyline full with contents like interest or political conflicts.

I would buy such games.

[m2]

Razorjack: The community has allready decided that it wants planetary flight. Please stop discouraging it. Vegastike is very limited without it. Thankyou for making the code, It will hopefully make it into VS. We have been waiting years for this. There can be a mod _without_ planetary flight however if you want to play that on the side.

Planetary flight is very important to VS. It will be a great boon to the game. So please continue work on it. Thanks .

[ace123]

@m2, I don't think he is arguing against planetary spaceflight. He was only responding to another idea for a mod for only one system, which could be interesting IMO.

Don't be so negative to him, as all contributors are valuable to this open source project. He is under no obligation to spend his time if he does not want to. Planetary flight is not an easy project if you want to do it correctly. In fact, planetary flight had already been tried before:
/vegastrike/trunk/vegastrike/src/cmd/cont_terrain.cpp

I also had a feeling, however, that planetary flight might have to wait until we got the more modern rendering engine that comes with OGRE.

For now, I thought we had space elevators, which could possibly be more realistic.

[razorjack]

I've taken a look into the source of vegastrike. I don't know if it is really necessary to wait for an ogre port. I've found some point where wo could begin independantly:

One of the most interesting points is the class: Unit
Currently it uses the class "Transformation" to describe position and orientation. Is it possible to rewrite "Transformation" so that it don't just use a double precision vector, but uses additionally a reference to a scene node or a segment with a local coordinate system?
I would also suggest to split up the class "Unit" into a base class "Object" and the rest. The class "Object" would be not more than the class "Unit", but it wouldn't implement routines for everything like "Unit" does. Instead, it could offer overrideable procedures for drawing, collision detection, physics, lighting a.s.o. for user implementation.
Are there any possibilities to modify the architecture of vegastrike in this way? Maybe stepwise?
Of course, much other dependancies should be changed too. And it's impossible to change everything at once. But we don't need to. We could simply offer an emulation of the old architecture so we need only to change as much dependancies as necessary.

This is my idea.

[ObsessiveMathsFreak]

Here's a link that may be of interest if you haven't seen it already.

http://www.vterrain.org/Elevation/Artificial/index.html

The author talks about three different methods for generating random, realistic, terrain. One involves fractal generation, another involves fourier transforms, and another based on somthing called Perlin noise.

Here's another page you may find useful.

http://www.gameprogrammer.com/fractal.html

I think planetary landing, exploration and exploitation should be a keystone feature of space sims. Space flight is all very well, but when all you do is float about in space, docking on orbital stations, you lose some of the connection to the places you are visiting.

By the way, an essential part of any planetary interaction will be a more sophisticated automated system of flight control. Does Vegastrike already include autopilot routines for going into orbits, etc? If planetary landing is implemented, there should be an autopilot routine for that too. Players probably won't be very good at calculating rocket science equations in their heads. I can remember how much of a pain landing was in Frontier.

[razorjack]

I think planetary landing, exploration and exploitation should be a keystone feature of space sims. Space flight is all very well, but when all you do is float about in space, docking on orbital stations, you lose some of the connection to the places you are visiting.

How do you mean it if you say you're losing connections to places?

My engine uses an octree like algorithm. And every object is placed in it's segment.
If you're cruising through the space, your position will be retranslated for each new segment you're passing. That works also for a very high velocity by changing your scale layer (see my description at topic head). Segments will be loaded and unloaded in real time.
That would be also the generic principle of realtime generation. The implementation of different generators are more user specific.

[peter]

I think planetary landing, exploration and exploitation should be a keystone feature of space sims. Space flight is all very well, but when all you do is float about in space, docking on orbital stations, you lose some of the connection to the places you are visiting.

How do you mean it if you say you're losing connections to places?

I think he means that it doesn't feel as real for the player; that it's not as immersive as it could be. Nothing technical. My German skills are pretty much tourist-phrase-book quality, so I don't know if there's an equivalent figure of speech...

happy hacking.

[razorjack]

I've put up a little terrain engine together showing mercurys surface.
That is currently not much compared to infinity but this is a realtime generated terrain(with perlin). And you see a real planet terrain(not one of these squared ones) where you can travell from mountain to mountain for days:

http://www.razorjack.de/planetshot.bmp
http://www.razorjack.de/planetshot2.bmp
http://www.razorjack.de/planetshot3.bmp
http://www.razorjack.de/planetshot4.bmp

The terrain is drawed with bruteforce inside visible segments. I hope to get a 50-70 fps framerate by rendering to a skybox once and by implementing a quadtree LOD.