Page 2 of 3

Posted: Wed Jun 04, 2008 12:30 am
by charlieg
Don't get hostile. Safemode has done more for VS than most of us around here. He deserves your respect, nothing less. You can make this point (the desire for the feature) without resorting to offensive comments.

Posted: Wed Jun 04, 2008 6:11 pm
by chuck_starchaser
@2asueekim:
I think what safemode meant was pretty clear: For seamless atmospheric flight you need a continuous LOD system that increases detail as you get closer to the surface.
safemode wrote:The thing is, there is no detail generation.
Nothing less than progressive, procedural generation of detail is really worthwile; I have to fully agree. What's the point of flying close to a planet only to see larger and larger triangles, down to when you're close to the surface and then all you see is a single triangle extending from horizon to horizon, and texture pixels measuring kilometers?
The surface detail has to be able to go down to sub-meter size, if you want to see terrain as you touch down, to the sides of the air-strip. But that implies that the terrain has to be procedurally generated; because even as compressed height data, a whole planet in meter detail would take several thousand hard drives to store.
Procedural generation is hard, but harder yet is matching the edges of patches that are switching LOD levels asynchronously; and harder still is to combine procedural LOD-ing of meshes AND autogenerated normalmaps.

Well, perhaps I'm misunderstanding Tarzan's work; I can't read the french comments in the code, and without code tags all the lines are flush to the left; so I haven't been able to make out what he's doing. But I see very flat planes in the close-up pictures; so I'm judging (or misjudging) from that.

Anyways, there are some open source solutions out there, but they all have limitations; and a more modern solution should actually make use of the GPU for much of the terrain generation. I saw a paper and demo of one system that does that, a while ago; but it was very complex.

It's true that a lot of people have been clamoring for seamless flight; but does that count? What counts, IMO, is the efforts to make it happen; and there have been a few such efforts, and so far they have failed.

On the other hand, a system that allows you to get closer to a planet and see more detail might be better than nothing; but what we'd want eventually is something procedural that allows you to go right down to the surface.

And... Ditto about safemode; he's done huge amounts of high quality work on the engine; and it's almost laughable to see a newbie who hasn't done a thing telling him off. If atmospheric flight is so important to you, just make it happen, or help Tarzan make it happen. Hell, if Tarzan makes this work, PU will adopt it instantly, even if Vegastrike doesn't.

Posted: Fri Jun 13, 2008 2:22 pm
by Tarzan02
to add detail to the texture, you can used the noise texture and to multiply the uv coord of a point as i do in the given shader:

noise texture:
Image

Posted: Fri Jun 13, 2008 2:48 pm
by safemode
tarzan: after you're done cleaning up your algos and such for generating terrains and what not. When you're ready to actually start working on porting it into VS. The way i'd go about it is sequentially.

First, we need a method to setup the LOD changes as you approach a planet. This is different from normal ships and such because the planets would have _Way_ more LOD's than any other unit in the game. Right now i can pretty much crash into the surface of a planet. What we are missing from VS is the terrain generation, and the atmosphere.
So. maybe follow this.

step 1. LOD'ing planets correctly. We dont have to get detailed enough to see trees and shrubs at this point, but non-pixilated mess when very near the surface would be nice. Of course, this would be tested on non-atmo planets

step 2. Auto generation of detail meshes. Again, tested on non-atmo planets.

step 3. Collision detection and such on detailed generated meshes. Correct functionality to return to low detail mode and back again etc.

step 4. Get atmospheres to work right. (probably the hardest step yet to be done)

step 5. Get shaders to operate correctly in planet atmo.

step 6. Clean up physics of in atmo flight a bit. (add drag and such).

step 7. start placing bases at geographical locations. Have RADAR convert to a planet based radar setup with a horizon and such.


everything additional is gravy. All of this is assuming you can rectify the issue of scale and in the end, have it all perform at a speed that makes it viable.

If you can get step 1 and 2 done and working in VS. I dont think you'll have any problem getting help to complete the remaining steps, assuming that they aren't already exposed as being impossible to do without total rewrites catering to just this one feature.

Posted: Fri Jun 13, 2008 7:30 pm
by Tarzan02
thank's safemode. agree with your approach. before step1 i propose to test my vertex shader to test the detailed surface, i'll give you the result of my test. The next step is to implement the automatic generation of the lod without heightmap, i'm not familar with open gl so it takes me some time, i will need help on the code and where to insert my procedure (after adaptation of course).

stuck_starchaser: if you see large plane it's because when the spliting is done the planet surface seems to be plane (as on earth, except near the see). I will make a video with a mesh in wire and you will see the tessalation of the mesh in action.

Posted: Sat Jun 14, 2008 11:52 pm
by chuck_starchaser
Can't wait.

As for terrain generation, it would be best to use a callback function, like

Code: Select all

float altitude( float longitude, float latitude );
so as to keep the generative code independent of the LOD'ing mechanism.

I would think that a good altitude noise function would begin by converting latitude and longitude into a quaternion. The good thing about a quaternion is that it excpresses a spherical angle (direction) using four quantities that change smoothly and continuously; which would prevent the noise function from producing terrains with discontinuities, such as longitudinal compressions at the poles.

Posted: Mon Jun 16, 2008 8:01 am
by Tarzan02
The noise texture is not for teh altitude, it's a texture mixed with the diffuse texture to add some perturbation and add detail even at low altitude. The elevation for the planet is a raw texture in grey level load in a 2 dimension array. For each vertex (with a uv coord) i retreive the elevation from this array, and when the triangles are small, the elevation is computed with a random access (in fact each triangle has a seed number to initiate a random generator and to give allways the same result with the same seed number).

Posted: Mon Jun 16, 2008 1:58 pm
by chuck_starchaser
That's good! --altitude already coming from a texture.
As for the random seed at greater magnifications, the problem I forsee is that you might have problems at the seams where the main 6 quadrants meet. Easy to solve later.
In any case, my first concern from the previous post still stands: the callback function. You don't want to mix or hard-code terrain generation into the planetary LOD code; you want these things to be separate.

Posted: Mon Jun 16, 2008 4:24 pm
by Tarzan02
In fact, my mesh is an icosahedron (all triangles composing the mesh are the same). I've got a root mesh composed of 320 triangles serving me for the culling. The real mesh is a decomposition of the root mesh in 4 sons => giving a mesh with 1280 triangles. Each son triangle having their seed number computed with the seed number of their parent. As you approach the planet, the triangle is divided more and more in smaller triangles and so on.
Each triangle has a level, when the level reach a number defined (for my test i give 6), the altitude is randomly generated with the seed number otherly from the raw texture.

Posted: Mon Jun 16, 2008 4:58 pm
by chuck_starchaser
Well, the more I hear about what you're doing, the better it seems. ;)
Keep it up.

Posted: Thu Sep 25, 2008 3:23 am
by Deus Siddis
Is work on this feature still ongoing?

Because I wholeheartedly hope so- besides making the stunning improvement of transforming a few elaborate menus with backdrops composed of still renders into actual, realistic, massive planetary exploration, this feature is a gateway between being an open space game engine and being an everything open game engine, the universal open game.

Starflight, Frontier: Elite 2, Spore and Infintity: The Quest for Earth, games like these have gone down this road and as a result stand out clearly from the wrest that confine the player to the vacuum. But none of them is both modern and open as is Vega Strike.

This feature would be a major step towards the engine being able to produce entire, believable, beautiful planets. And that is a major step towards worlds' worth of awesome sites and incredible gameplay--

Exploration of worlds and its inhabitants thereupon, planetary combat in the skies and waters and across the land between everything from fearsome futuristic war machines down to the most unimaginably alien lifeforms, with the help of familiar fluid friction flying at hundreds of kilometers per hour weaving between rugged mountains and stratospheric high rises to reach your destination landing pad nestled amoungst these planetscapes, etc.

Posted: Thu Sep 25, 2008 1:11 pm
by charlieg
Sadly nobody is working on it at the moment because it's just an incredibly difficult task.

Posted: Thu Sep 25, 2008 2:55 pm
by pyramid
Last time I looked at the code a couple of months ago there was no specific class for drawing planets. A basic sphere class is being used for planets and shields. This is the greatest obstacle I see currently to start creating planetary surfaces. Nothing has changed since then.

Personally I made a test with a spiky sphere but I just didn't have the time (and patience) to learn how to separate the code to obtain a planet class so that the shields would remain spherical but the planets would be hooked into their own class.

The code for planetary surfaces that has been shown by various volunteers is quite easy to implement (in its basics) as long as you know where to start integrating it. With the current setup it's simply not possible and a rewrite and preparation of the framework would require the help of a dev that has some idea of the app workflow. At the moment all devs are 100% RL so I don't see that happen anytime at all without the proper framework prepared.

Posted: Sat Sep 27, 2008 11:37 pm
by Fendorin
for my opinion it would be preferable for the moment to improve the visual effect over the existing structure of the game

i would like planetary flight but maybe if the game was in one system is possible but is already difficult with all our freetime to made 1 ship or station

and personnaly i prefer have a nice space environnement (debris huge asteroid belt/field, more station, some ancient relics..possibility to have a derelict ship after kill/destroy them, recuperation/extraction, and mining workable, collision, blob, gas field too, dust, pulsar and other strange thing ..etc)..but not plannetary flight
than a plannetary flight and nothing improvement in the space

And personnaly the idea of 2D picture when you are landed is very stylish
is mean like a quiet/calm moment after trought the dangerous space.
of course we need to do a lot of new background ....lol

but maybe for the release 7.0 we should have this target (have a begining of planetary flight)?

thank

Posted: Sun Sep 28, 2008 5:04 am
by Deus Siddis
Fendorin wrote:for my opinion it would be preferable for the moment to improve the visual effect over the existing structure of the game

i would like planetary flight but maybe if the game was in one system is possible but is already difficult with all our freetime to made 1 ship or station
You don't understand though, this isn't content I'm asking for, it's code. Procedurally generated planet surfaces that locally subdivide/tessellate into higher LoDs dynamically as you approach them.

The only content that is needed are some terrain textures for when you get really close, planetary life (flora, fauna, exotics, etc.), ports, bases and cities, surface and atmospheric vehicles, etc.

I would be more than willing to work on this planetary content myself, leaving you to continue work on the purely space dwelling structures and craft, if there was just this code to support realistic planets at low altitudes.
and personnaly i prefer have a nice space environnement (debris huge asteroid belt/field, more station, some ancient relics..possibility to have a derelict ship after kill/destroy them, recuperation/extraction, and mining workable, collision, blob, gas field too, dust, pulsar and other strange thing ..etc)..but not plannetary flight than a plannetary flight and nothing improvement in the space
I'm sure the devs wouldn't drop everything to work on planets, work on the space portion would continue at about the same pace.

But this is a very important step for VS, space games and open source games in general and it has been requested by many people over and over throughout the years on the VS forum. It has been done decades ago in games like Elite 2 and Starflight and it has been done recently in games like Spore, Infinity and I think Supreme Commander.
And personnaly the idea of 2D picture when you are landed is very stylish
is mean like a quiet/calm moment after trought the dangerous space.
of course we need to do a lot of new background ....lol
No one ever said that if something is realtime 3D, it has to be a nonstop shoot out. It could be just as peaceful and calm in a secure location like that, only you could explore it as a realtime 3D environment, rather than a series of still renders.
but maybe for the release 7.0 we should have this target (have a begining of planetary flight)?
A feature this big should be started as soon as possible, because it could take a few versions for glitches to be worked out and then for features that build off of this feature like I mentioned earlier to be implemented.

Posted: Sun Sep 28, 2008 5:35 am
by Deus Siddis
pyramid wrote:Last time I looked at the code a couple of months ago there was no specific class for drawing planets. A basic sphere class is being used for planets and shields. This is the greatest obstacle I see currently to start creating planetary surfaces. Nothing has changed since then.

Personally I made a test with a spiky sphere but I just didn't have the time (and patience) to learn how to separate the code to obtain a planet class so that the shields would remain spherical but the planets would be hooked into their own class.

The code for planetary surfaces that has been shown by various volunteers is quite easy to implement (in its basics) as long as you know where to start integrating it. With the current setup it's simply not possible and a rewrite and preparation of the framework would require the help of a dev that has some idea of the app workflow. At the moment all devs are 100% RL so I don't see that happen anytime at all without the proper framework prepared.
Wow, so the difficult part would be integrating this feature then, not creating it?

Either way planets should certainly get their own class within the near future. After all, at this point everything else in the game has been cleaned up nicely with the exception of nebulae.

Posted: Sun Sep 28, 2008 8:49 am
by rivalin
Yeah, this would be an amazing feature but Pyramid is right; what we really need is to get the framework into place where someone who knows what they're doing can implement it. If the code was cleaned up, the move to Ogre was completed etc then it would probably be fairly easy to recruit someone to write something. It seems fairly obvious the current coders aren't really interested in this feature, so if it's going to be implemented a good idea would be to trawl the internet, mod sites etc looking for programmers to help clear up some of the code, complete the move to Ogre and then implement planetary flight.

Posted: Sun Sep 28, 2008 10:54 am
by pyramid
The decision to implement a new engine feature depends on two factors:
1) Preparedness of the framework (not given)
2) Developers / coders willing to implement and enhance the feature (not given)
It should not depend on any other improvements that are going on in the game that are of artistic nature.

At the moment we are doing some parallel improvements mainly on the artistic side (shaders and units) and the amount of work that can be completed is limited by the number of contributing artists.
Still, if we had an active coder onboard we could start preparing the framework and primitive features (like surace flight with visible elevation profile but wothout landing) without impacting too much the rest of the game. Then move on toward improvement of the feature.
This could be done independent of the artistic developments and independent of the moce to Ogre. There is no point waiting for Ogre where there is nobody actively working on that port. Blocking the development of new features due to unavailability of other features is counterproductive.

So the blocking point seems to be coders willing to take a dive into the current code structure and prepare the framework for integration of a procedural planets.

I quite like the idea of recruiting coders on the internet or even offering internships for graduate students from multimedia computing courses (something I have already proposed and discussed with project leads). This is no minor task however and help with organization would be appreciated. What needs to be done:
a) Identify sites and universities that could have interested members.
b) Write a description of required knowhow and task at hand
c) Publish, collect feedback, assign task
d) Accompany development

I could do b), c) for universities, and d) to an extent (would be handled through forum anyway).

Thing is that in order to not discourage new members we should advise them of the current website handicap where we actually cannot receive new members until all issues are solved.

Posted: Sun Sep 28, 2008 2:36 pm
by Sindwiller
It would be ace if the artist could model the planetary environment (to some degree) though.

Posted: Sun Sep 28, 2008 7:13 pm
by Deus Siddis
pyramid wrote:This is no minor task however and help with organization would be appreciated. What needs to be done:
a) Identify sites and universities that could have interested members.
b) Write a description of required knowhow and task at hand
c) Publish, collect feedback, assign task
d) Accompany development

I could do b), c) for universities, and d) to an extent (would be handled through forum anyway).
I'm probably just stating the obvious, but there is the sourceforge.net volunteer help request/recruit page:

http://sourceforge.net/people/

You also have of course Google Summer of Code (which just ended for this year obviously but that would leave extra time for planning next year):

http://code.google.com/soc/2008/

Then you have gamedev which is more game focused than open focused but its forums seem to have alot of hobbyist or otherwise small projects coders:

http://www.gamedev.net/community/forums/

Looks like Oregon State University has a project to host open projects, which might indicate they would support student participation in open projects like VS:

http://osuosl.org/

The west coast of the united states in general has 'silicon valley' making it a bit of a tech hub (though more tech hubs continue to grow elsewhere in the US) and universities their might be good targets.

Same thing for scandinavian countries, plus I suspect OSS is a bigger part of modern culture in western and northern european countries, so their universities could be considered good recruiting grounds.

Not being a coder myself I would have to look into this more to find more specific targets.


Also worth noting for the actual implementation of the feature are:

Charlieg pointed this guy/project out who has started doing this in OGRE.

http://www.ogre3d.org/phpBB2/viewtopic.php?t=39254

There's another one in an early stage on sourceforge:

http://sourceforge.net/projects/fracplanet/

Posted: Tue Sep 30, 2008 10:12 pm
by chuck_starchaser
That last one is not meant for real-time.
Good idea to try and organize this as a separate project.
So many people have tried, and AFAIK the only successful implementation there's ever been is not open source.
Talking about the Infinity Engine, of course.

Posted: Tue Sep 30, 2008 10:28 pm
by pyramid
My fingers are itching...
I'd like to give it a try myself...
If I had the framework ready...
But as there are still so many things...
To do on artistic side...
And in user tool land...
I let it be...
(The sun will shine...)
(That I swear...)
(THAT I SWEAR!!!)

Disclaimer: this is not a poem

Posted: Wed Oct 01, 2008 4:28 am
by Deus Siddis
chuck_starchaser wrote:That last one is not meant for real-time.
Good idea to try and organize this as a separate project.
So many people have tried, and AFAIK the only successful implementation there's ever been is not open source.
Talking about the Infinity Engine, of course.
Sometimes I wonder if we all petitioned/begged/pleaded with Flavien for the sake of human civilization to do so, if he would at least release an early build of his planetary code.
pyramid wrote:My fingers are itching...
I'd like to give it a try myself...
If I had the framework ready...
But as there are still so many things...
To do on artistic side...
And in user tool land...
I let it be...
(The sun will shine...)
(That I swear...)
(THAT I SWEAR!!!)

Disclaimer: this is not a poem
If I haven't mentioned it before, I for one really appreciate the work you are doing to make VS' broken content pipeline something really friendly. You might be making this the first open source project to do so.

But when this and your other VS projects seem to be in a good place, on behalf of the open source community, fellow Starflight, Elite and Vega Strike fans abroad, please let loose those fingers on this feature.


PS: Despite his lack of interest expressed earlier towards this effort specifically, I wonder if when he gets back, if safemode would be interested in helping separating out this planet class?

Posted: Wed Oct 01, 2008 10:57 pm
by chuck_starchaser
Well, we could start brainstorming its interface, to save time.
Everything that ends good, in this business, begins with a clear specification and interface.
In fact, best software practice is to start with a testing specification.
If you know what you want, you should be able to specify how to test it.
If the testing code is done first, there are no ambiguities about what it is that the code needs to do. The answer is
simplest: it must pass this test.

Posted: Thu Oct 02, 2008 9:06 am
by pyramid
Good idea. It should at least take the parameters that are provided in the .system file. Plus planet type and some descriptive attributes like, amount of oceans, rivers, atmosphere type, highest mountain range (geological age?, seismic activity?), and probably many more....

This reminds me, I have somewhere a specification draft for redesigning planet types. But that deserves its own post.