The official "Seamless Planetary Flight" thread

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

i have now downloaded the concrete cascades demo.
i got all the shaders from it.
it features also waterfalls etc.
there is a huge amount of lookup tables.
i'll have to understand all that first in order to create
a basic voxel shader myself.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

After reviewing the Code, i Found out that it Must Be completely rewritten. This is Not the Problem,
I am not Done yet, i'm Programming on mac, and there is à Problem that you can't define lookup tables.
Is this Problem on other Hardware , too?
The gsgl 1.2 Book says i can define an initialized Array of Data through:

Code: Select all

int arr[10]=int[](1,2,3,4,5,6,7,8,9,0);
this won't Be accepted by my mac!
The lookup tables i got from the Demo seem to Be usuable.
Are there also Linux shader Programming programs, too?
If nothing helps, i have to load them As texture via an Uniform variable.
This mechanism seems to Be aimed by the creators of the Language.
Is there à possibility to Save à .png without compression?
Which constants do i have to put into the Save func to reach this behaviour?
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
log0

Re: The official "Seamless Planetary Flight" thread

Post by log0 »

google:
the problem is that Apple GLSL 1.2 implementation does not support array initialization constructor. it's a known bug… but never fixed
By the way i work around it by passing the array as a uniform.
Can't wait to see your planet shader in action. :)
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by ace123 »

@strook, is there a reason you can't declare a uniform, like:
"uniform int[10];"
and then intiialize the uniform from C++ code? Most cards allow several hundred uniforms at least, and if you are short on space, it's possible to pack them four at a time using a vec4 (even if they don't need to be floats).

The other advantage of uniforms is that they can change frame-by-frame without needing to recompile the whole shader, so for example, you can allow a planet's surface to change over time or something weird.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

Yes i use à shader IDE. And the sourcecode of vs can't Be executed,then,so i can't load the Data defined in the Code.
Instead i'll Write à Simple Save func for that .bmp Format for Uniform samplers.
.bmp has no or loseless compression. And is quite easy to implement.
I searched for shader IDEs and Found only qshaderedit and shader Editor for Linux.
Both didn't meet my requirements, since qshaderedit can't edit geometry shader Files and the other crashes when using Large Arrays (the lookup tables).

Additionally thx for all who Support me and wait for my work to Complete :)

when i completed the Basic shader, only 1/3 Part of my work will Be Done. The Next step would be bringing the Noise on the surface, then clipping and subdividing the cubes what i haven't googled yet, but i Know that there is à clipping var in the shader.
But there will Be more work to do if you want to Land on à Base on the Planet etc.
I have begun some work on Ground Units - i borrowed me the work from mechcommander 2 - so some known walkers would come up - if you don't mind (hehe) ;)
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
Haggis
Explorer
Explorer
Posts: 9
Joined: Wed Dec 05, 2007 10:17 pm
Location: Netherlands

Re: The official "Seamless Planetary Flight" thread

Post by Haggis »

Great Strook! I'm following your work with interest. Checking the forum for updates almost every day. This is very exciting :D .
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: The official "Seamless Planetary Flight" thread

Post by Deus Siddis »

strook wrote: I have begun some work on Ground Units - i borrowed me the work from mechcommander 2 - so some known walkers would come up - if you don't mind (hehe) ;)
That bridge,has already been crossed. :)

Though unfortunately the VS engine doesn't yet support animation (so legs of walking vehicles won't move).

But either way, if you can manage to implement ground vehicles with working physics, I'll start modeling/texturing some for you in full modern detail (MC2 is like 10 years old now). This is something I've wanted to have in VS for a long time now.
strooka
Atmospheric Pilot
Atmospheric Pilot
Posts: 1
Joined: Wed Sep 01, 2010 10:12 am

Re: The official "Seamless Planetary Flight" thread

Post by strooka »

Ok, guys, here is an update:
I 've Found a very good Shader ide Named Lumina.
It Supports all the Features i Need for Shader Programming and its free!
Unfoutunately, there is no Mac Version. I belive the Mac Shader ide has Bugs, i don't think Apple has invalid OpenGL Shader Support.
I downloaded the Source Code and installed qt on my Mac ( it's a depedency) but it didn't compile!
Does someone Know how to Build x11 Applications on Mac?
There is a Definition that lest the Compiler Know it is on mac, but the Mac qt implementation of the App Class has different function definitions cause they take Otter arguments.
Unfortunately i have no Time for qt Programming and im totally New to it.

(ok, Yes, the Editor Runs on my Linux pc, but i could spänt much more Time if it would Run on my Mac)

I have First results;
The marching_cubes planetshader compiles successfully but it gives no Output in the
Moment.

I will debug it the Next days.

I Could implement animated meshes, Lumina Supports a Bone animation System.
As Long i Know, the .obj Format doesn't Support Animation either, and the 3D data has to Be converted to .obj Files before importing it into vs.
Lumina has also an Blender exporter, but what i Want to say, i could Write a shader that you could use to implement Animation.
Then we had only to Write some additionally opengl Code in vs to Start the Animation and load the right Animation for an Action.
If you want to Start work on it right now, let me Know, i'll create a Lumina project for it, then.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

Bone Animation with Lumina ain't that easy. If you want to create Animation by shaderside, you had to create a Transformation and Rotation matrices for every Single vertex you want to modify.
This wouldn't Be easy.
Instead you could create an Animation with Blender, and Save every Frame to the .obj Format.
Each Frame could Be loaded in if an Index to the file Extension is given, Getting the actual Frame.
Maybe we could load in all the meshes by definining submeshes in the importer and live the resulting mesh a special Name extension.
I could create a Class Holding all the Frames and modify the draw Function of the mesh.
An Animation could then Be initiated by calling predefined Actions,defined in functions, like walk, Run, etc.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by charlieg »

I know it's good to be forward looking and try not to make the future difficult by failing to plan for important features in the future, but don't you think you should get the more basic aspects of the shader working before you get into animating the planets and a lot of the other aspects you talk about?

I think there's a lot of difficult tasks to accomplish, such as generating the terrain, the clouds, the atmosphere, transitioning between space and atmospheric flight, before you get on to some of the really advanced stuff you are alluding to.

There's nothing wrong with being ambitious, but be pragmatic too. ;)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

If He wants to create animated meshes and Support me i'll be happy.
Creating a New Class derived from the Unit Class will Be easy and getting all the submeshes From it i did already before this.
Modifying the draw function and replace the vertices - no problem, Found out.
The only Thing that will New to me is Holding a constant Animation Speed, i think i'll borrow me Some Code from the animated textures or create a thread that Calls every 1/4sec my vertices Change function of the mesh.

You See - this won't Be a very hard Task to Complete.
Also i could supply my First usuable results from reviewing and modifying the Code.

Maybe you could use it for creating animated spaceships in the Moment.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

Ok here is an update:
The last days, I spent my time by installing ubuntu on my Mac. Yes! You have read right Linux on Mac. After first installation my Mac didn't want to boot again and I got the error MSG "still waiting for boot disc", I thought almost all my music and videos were gone, but I found out a key combination (windows-key+alt+shift+del(I remember hardly)) that let start my Mac again. :mrgreen: (thanks goodness)
My programming work slept a bit but I'm nearly done with the animation shit - I moved this theme to another thread. (http://vegastrike.sourceforge.net/forum ... 27&t=15665)
The planet flight shit didn't went on a bit cause I had no time for it.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

another try: that shader programming work wasn't successfull at all.

i'll try it this way:
i'll create a large heightmap.
and create a new texture from it by merging water into lanscape maps, tiled, that ate already there by using the heightmap..
theni 'll define a sphere in the normal code using the texture.
for low orbit i'll use the normals of the sphere that are orthogonal to the player and extract the vertices and texturecoords from it.
then i'll place a terrainmesh over that vertices.
that should work.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: The official "Seamless Planetary Flight" thread

Post by Deus Siddis »

BTW, if you are having trouble with your implementation, you might want to check out the Simerge project (Forum).

They're an open source (free) game almost identical to VS, that are doing work on real time terrain generation and seamless planetary flight as well for their own engine. Maybe you could both team up to accomplish this same goal you have previously been working on independently, since you are both working under similar or the same licensing it seems.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

I've downloaded the simerge svn tree.
It is at a very early stage, and Linux development isn't implemented really.
There are make errors cause it is a native windows project.

But the good news are it __has__ already implemented seamless planetary flight and walkable ship interior.

The develop admin wants to go closed source, and I am already familiar with vs so I'll stick with vs.

So expect good news in the future now.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

After reviewing the terrain code, It seems that the polygons near to the ship must be subdivided and passed through the noise func.
The lower you come, the more vertices nearby the ship will be subdivided and the far ones will lower in detail.
This means I'll have to create a sphere that improves it's detail where the player is located above and reduces at the far ends.
To do this I'll access the vertex list of a 1000x1000 sphere again get the altitude and the collision value of a Ray to the mid of the sphere and the ship.
I hope collision rays are implemented in vs (which I have not seen in it).
It seems that it is being worked with the radius of an unit.
What about using bullet Lib if it is not implemented?
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
razorjack
Trader
Trader
Posts: 24
Joined: Sun Jan 07, 2007 2:14 am
Location: Germany, Bonn
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by razorjack »

To introduce me. I'm admin from Simerge Project. I've noticed today, that there are more posts about planetary flights in VS and I would like to give a small review of technics I use.
Most important is procedural generation and LOD LOD and LOD again. A planet can contain very much data (heighmaps, textures) in it's whole. It's more than can fit inside RAM and harddrive. So you need a realtime content generator coupled to LOD algorithms to decide where to use more and where to use less details. I would recommend to take a look at "Infinity: Quest for the earth" project and especially into their development journals at forum and http://www.gamedev.net/community/forums ... ?jn=263350 . For more inspiration on hardware based content generation you could take also a look http://www-evasion.imag.fr/Membres/Eric.Bruneton/ and http://www.outerra.com/ with its blog http://outerra.blogspot.com/2009/02/pro ... rithm.html .

The spherical terrain engine is based on the standard method. You have a cube bounding the planet sphere. Then each side is projected to the sphere itself. All you do is to place the center of a unit box and unit sphere at the origin and divide a point lying on a box side by its infinite Norm and multiply it by the planet radius. Then you can operate with each side as if it is a simple quadratic terrain map. For these you can use conventional terrain engine algorithms available today. Precision issues will require a little tricking since the Z-Buffer is 24 or 32 bit long and the GPU require vertices to be in 32 bit float format instead of 64 double.

What I do is as follows:
Beside a terrain generator http://libnoise.sourceforge.net/ , I use two LOD and scene organization algorithms. The first one is based on coordinate switching and multiple Z-passes. There I try to fight with precision problems. As it is half my invention it is unfortunately not well documented and I can't give any reference material. To describe it briefly, I build cubic volumes containing rendered geometry around the planet where each cube has his own coordinate system and belongs to a certain Z-pass. The geometry inside and their bounding volume cubes get subdivided, rescaled and rendered at a fixed amount of recursions steps. The trick is that planet sphere and the cube sizes are initially scaled down to a small size, so their local spaces are fitting into a fixed boundary of, let's say [-2000,+2000]^3. The vertices inside this boundary are renderable by the GPU! After that a subdivision is performed in a local environment of to camera. What I do is to divide cubes and scale them back to make them nearly as big as their parents. But ... Doing so the rendered geometry from the coarse levels would interfere with the one of the finer levels: The Problem is Z-buffer! And there is the point where multiple Z-passes come in place. After each subdivision/rescale/render step I clear the Z-buffer. ... This will get repeated until it reaches a fixed depth.
From there a second algorithm comes in action. This one is derived from Thatcher Ulrichs Chunked LOD thing http://tulrich.com/geekstuff/chunklod.html .
strook wrote:
The develop admin wants to go closed source, and I am already familiar with vs so I'll stick with vs.

So expect good news in the future now.
I have expressed myself a little wrong. I'm going to make a branch from my early engine version, because I want to make another commercial game and need to earn my bread. As it is always in our money oriented world. All is that there will be another game project sharing a common engine. But until all is decided, I mean things like license and financial, I'm not willing to take more programmers as you offered me :)
For Simerge. As for any GPL project, it can't be closed source, after once it was released under GPL. But for the future of the engine it is possible that I would re-release it again under different licenses (like MySQL or apache did). But details are uncertain now.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

Let me ask a question: why do you use that complicated cube downscale thing, like NVIDIA does as you have no benefits from it except that you could generate terrain with more variations like caves etc.
I don't think that I'm wrong with an easy noise generation method that as you said, too , modifies the terrain nearby the camera.
I think that you want with all your possibilities map the sphere to a map, that can be modified by usual terrain generators.
But if you take the nearest vertex to the camera, take the normal vector from it and generate higher detail for all vertices that have similar normal direction, you need no cube mapping. This was my intention.
You needed just to save the LOD in an added vertex in order to delete it again if the camera gets far away.

And btw: danke für den code, das statement und die links, aber sie brauchen nicht so arrogant zu sein. Ich bin nur ein hart arbeitender student, der in seiner freizeit etwas programmiert. Jeder fängt mal klein an und wen sie ein projekt veröffentlichen unter der GPL was noch jede menge arbeit benötigt, ist das kein Grund Hilfe abzuschlagen, auch wenn sie noch so klein ist. Man macht's schließlich umsonst.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
razorjack
Trader
Trader
Posts: 24
Joined: Sun Jan 07, 2007 2:14 am
Location: Germany, Bonn
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by razorjack »

strook wrote:Let me ask a question: why do you use that complicated cube downscale thing, like NVIDIA does as you have no benefits from it except that you could generate terrain with more variations like caves etc.
The divide/upscaling method is more for coordinate precision raising rather than terrain generation. Also it's not only applied in the planetary engine. I use it also to display the local solarsystem or surrounding stars or beyond this. Different planetary engine authors I mentioned in my previous post possibly use other approaches. My approach is based on multipass rendering by using different "Z-slices". Don't know how the people call it, I hope thats the name of it.
In detail, the camera frustum has a "virtual" far clipping depth of many astronomical units. Practically it can have an arbitrarily depth, from a few kilometers to thousands of megaparsecs. As the GPU and it's Z-buffer datatype isn't able to cover all distances, also not for a single planet, I split up the frustum into a fixed amount of slices in Z direction. I don't choose constant thickness for each slice. The thickness is increasing geometrically by their index. As the slices appear farer and farer from the camera itself I need to scale the Z clipping interval [zFar, zNear] down to bring them back near the camera. The upscaling I mentioned in my previous post is the inverse operation.
strook wrote:I don't think that I'm wrong with an easy noise generation method that as you said, too , modifies the terrain nearby the camera.
I think that you want with all your possibilities map the sphere to a map, that can be modified by usual terrain generators.
But if you take the nearest vertex to the camera, take the normal vector from it and generate higher detail for all vertices that have similar normal direction, you need no cube mapping. This was my intention.
You needed just to save the LOD in an added vertex in order to delete it again if the camera gets far away.
I don't know if I understood it right with the normals. Somehow it reminds me of the ROAM or SOAR terrain technique one guy "asimocpp" from gamedev.net implemented: http://www.xwaytoonsoft.com/index.php . I think it is the Lindstorms SOAR. This approach is working more like progressive mesh and doesn't need a heighmap.
I use a wide spreaded quadtree approach, where I divide the terrain into regular patches recursively. All projects I refered above do this. I think the advantage is, that I can use also hardware aided terrain generators very easy (as the guy from Outerra did).
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

As I understood it and read from your code you mentioned a way that the terrain is generated on a MxN array, which it's vertices are got taken from a subdivided voxel or cube where a part of the sphere is mapped upon.
This would be a very difficult task to implement, and I don't know how scaleable the code is. I tried it this way but came to no results.
Also it seems that you work direct on the buffers (you mentioned the z-buffer) of the graphics card.
In vs, there is already a lot of glue code written between the shaders and the meshes.
Also in each vertex there is stored the orthogonal direction of the primitive (a quadstrip), called the normal vector http://de.wikipedia.org/wiki/Normalenvektor.
In vs I have no need to take into account about the clipping distance etc.
From my view there should be no difference if you create a simple planar NxM map of vertices, or a sphere with N stacks x M slices.
You move the subdivision vertices up/downwards the norm vector.
What I think about the hardware acceleration is that the voxel computing can be done by the GPU, (i did already some work on it) but the terrain generation must be done by software I suppose, cause you can't save your planet data from one frame to the next when using the noise function.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
razorjack
Trader
Trader
Posts: 24
Joined: Sun Jan 07, 2007 2:14 am
Location: Germany, Bonn
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by razorjack »

strook wrote:As I understood it and read from your code you mentioned a way that the terrain is generated on a MxN array, which it's vertices are got taken from a subdivided voxel or cube where a part of the sphere is mapped upon.
This would be a very difficult task to implement, and I don't know how scaleable the code is. I tried it this way but came to no results.
This is common used by most heighmap based terrain engines and it is very scalable. A terrain patch is nothing more than a simple mesh. I convert a 2D heighmap into a 3D mesh. Indirectly the conversion happens by applying a cube to sphere projection and a Y displacement (towards sphere normal). Indirectly means, that there are a little workaround, because the 3D points are calculated inside the volume cubes (see TPolarRailSub_OLD::getPointInOctet). But why scalable? A mash is a mesh. You can construct it arbitrarily. Assume, you don't want to generate a mesh from a heighmap but use a voxel based terrain with marching cubes or anything other. Or you want to use geometry shaders or use "render to certex buffer" techniques like the guys from Infinity or Outerra project. You can construct a terrain mesh each way you want. In the code I have it happens in TTerraTerrainContent::initTerrain . That's the function which retrieves a 2D Map from generator and do the conversion.
razorjack wrote:Also it seems that you work direct on the buffers (you mentioned the z-buffer) of the graphics card.
In vs, there is already a lot of glue code written between the shaders and the meshes. [...]

In vs I have no need to take into account about the clipping distance etc.
As far as I know. In Vegastrike there are 3 Z-Stages, which do care about clipping. And is exactly the same multipass rendering thing. From chuck_starchaser I heard that planets are rendered into another stage than near objects to the camera. Fact is the planets are big and need other clipping distances. Honestly, I don't like this solution, because objects are assigned to a fixed stage. I would solve this as follows: There should be more stages for different distances from the camera. And each object should be assigned to one or more stages dynamically, depending on how big it is and how far. For the planets, you will get in trouble really soon if you get closer and closer to the planet surface. If the near geometry don't change their stages you will get clipping artifacts.
strook wrote:Also in each vertex there is stored the orthogonal direction of the primitive (a quadstrip), called the normal vector http://de.wikipedia.org/wiki/Normalenvektor.
This is relevant for shaders.
strook wrote:From my view there should be no difference if you create a simple planar NxM map of vertices, or a sphere with N stacks x M slices. You move the subdivision vertices up/downwards the norm vector.
In result there is no "planar" NxM map of vertices. You can take above what I wrote about the 2D to 3D conversion.
strook wrote:What I think about the hardware acceleration is that the voxel computing can be done by the GPU, (i did already some work on it) but the terrain generation must be done by software I suppose, cause you can't save your planet data from one frame to the next when using the noise function.
You're not right. Everything can be done inside GPU as well as in CPU. And you won't lose any data from one frame to next. Because of two things. First, the GPU doesn't distinguish between frames. A frame change is nothing more than a periodical blitting/swapping from backbuffer to frontbuffer called inside the application. And second, you needn't lose anything. Before terrain generation (through special rendering calls), you can assign a target texture to render to or if you use the modern geometry shaders, you send a target vertex buffer. But, if you don't reassign the same vertex buffer or target texture again next time you make a render call, then nothing gets overwritten and therefore lost.


If you like you can phone me by Skype and we could talk on this very interesting topic.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

For all who ask "what happened with this thread" I'm on it, I have code got supplied from pioneer and simerge.
But I'm on mesh animation right now and after that I'll set up a basic fps map with fps movement.
Then I'll go back to the seamless planetary flight.
I have contact to a developer who has already made it.
Be patient.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

Well I have found out a new way to solve this problem:
I'll post some pseudo code:
first of all, I need a function that gets me the distance to the sphere and computes the position over the ground:
there is already a distance func. This will be enough for high altitudes.
The position could be computed like this:

Code: Select all

for(vertices of sphere)
get those which normal is nearest orthogonal to camerapos.
the sphere will be drawn with approx 8x8 slices&stacks.
The whole search func will run in threads For all normals , will sleep 2secs and call the terrain generation func.
With the normal vectors found, being in a certain orthogonal range, the left both and bottom both vertices will be used to span up a map through getting the uv coords.
The sea level is simply generated through putting a sphere with a certain radius over the sphere, seperating the below sea level to water and leaving the other terrain.
The uv map is then (it needn't be rectangular) used within the shaders where a bump map of generated noise values is laid over.
I think I should split up the whole sphere into parts(in the moment, it consists of slices) of slices whereas every part has a shader registered.
This way, one could define a surface .bfxm part where a base or city is. It needed to be fit into the existing part by rotating it and aligning the heights.
Height alignment I have already previosly done.
Once the distance (altitude) gets lower, subdivision occours.
There is a sphere generation alogithm inside vs; I'll modify it to generate subdivided vertices.
Subdivision occours only over the orthogonal vertices by calling the sphere generation only for this range by extracting the vertexgeneration out of the both for loops and call it as a new func with the approitate func.
Theese vertices will theirself be called by the position alogrithm.
And 'voilà you have your terrain.
There is one thing what isn't clear to me: if you get near to the planet, the planet looks very small in size. Maybe I should resize it by the factor 1000, but I have been warned that I'll get problems with the z-buffer. If it is so I'll use 64 bit values for the vertices.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
calvinthedestroyer
Explorer
Explorer
Posts: 12
Joined: Tue Mar 17, 2009 2:20 am
Contact:

Re: The official "Seamless Planetary Flight" thread

Post by calvinthedestroyer »

You can't have yourself as the center of the game universe. Every time that you move everything will change in relation to you and that's a lot of CPU hogging.

To make it so that you can fly in space, in atmosphere, and walk around on a planet, I think you would need three different game engines, just to cope with the physics alone. Does anyone know how the game engine for GTA works? That might be a good example to follow.

I don't really care that much about the landing part, What I really like is ramming retro ships with my ship and watching them blowup.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

Re: The official "Seamless Planetary Flight" thread

Post by strook »

One mistake did I do: if I tile the terrain, every tile with a shader assiociated, the shape of the terrain will change at every LOD step. I should create a matrix of vertices for every tile to be subdivided and run the standard terrain generators on it, fitting it then into a part of the sphere and save the LOD in it in order to remove certain LOD vertices later.
Bump maps should go only if maximum LOD is reached.
There is another add-on the distance is calculated in the direction where the camera points. Thus the viewport will be LODed.
So far to the theory...
I've found another code that seems to be totally complete and seems to have a very high niveau.
@calvinheaddestroyer: first I'll try to create a planetflight no matter about physics.
If the game shall switch to fps there is a modification to the input devices needed. Switching from spaceship flight to fps moving.
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
Post Reply