ROAM Planet rendering

[DavlexDesign]

G'day people,

Go to this link for an Executable demo "PlanetDemo.zip"

http://www.titaniumarts.com.au/index.ph ... &Itemid=29


I've been toying around with an old but "I think" very useful terrain system to enable the rendering of whole planetary bodies ...

Planet.jpg

I use a slightly modified version of the ROAM algorithm, To see it in action .... http://www.youtube.com/watch?v=I3_pb6Gq5hs
This algorithm allows me to keep the polygon and vertex count down to a minimum, while keeping the detail up,

as you can see by the next pic ....

PlanetDetail.jpg

As you can see the detail is still quite good even in the far distance.



The algorithm uses a chunking system with no visible seams, while keeping the vertex duplication to a bare minimum,
no use of skirts or other such work-arounds, at the moment I can chunk each of the 6 faces of the geosphere down to 1024 chunks
per face, but I'm still working on this ...

Chunkmap.gif

I also chunk everything that goes with it, Like water and such ....

This is still just a work in progress, I am using no shaders or any thing like that, and the data used is just 4 images ..
1. Detail map, 256x256 pixels for terrain
2. Color map, 1D 256x1 pixels for terrain
3. Color map, 1D 256x1 pixels for water and sky
4. Cloud map, 1024x2048 pixels for the clouds ( pretty lame, but working on a voxel cloud system for this (needs a shader)).

Everything else is generated on the fly with some slightly modified Fractal routines I've come up with.

I'll keep you posted ...

Alex

[xavier]

Nice work. ROAM is a classic, but there is a reason they stand the test of time...

[DavlexDesign]

G'day again,
Here's the chunking system at work, there is only 256 chunks per face, but it can get to 1024 chunks per face,
I haven't implemented any culling as yet, but that is coming, I just wanted it to work without resorting to using
work arounds to fix seams, and this one doesn't use any ....

Chunking256pface.jpg

Catch you next time

Alex

[leonardoaraujo.santos]

Hi man could you share with us this demo code?

[DavlexDesign]

I will, but I'm tidying up the Chunking code at the moment to make the chunking more dynamic, so that you won't be restricted to a set number of chunks per planet. My idea is to have each chunk act as it's own entity, so you can attach anything you want to it, all it needs to know is it's neighbors address (top,bottom,left and right), how its neighbor is configured is up to you, the terrain mesh generation will also be independent, but tie into the neighbor seamlessly, it does this already, I'm quite happy with the way it is going at the moment.

My aim before I release this stuff is to get it to have variable resolution chunks sitting next to each other with no seams, when this is done and I tidy up the code a little to make it readable (with helpful comments) then I will release it.

If you look at the code at the moment, you wouldn't be able to make head nor tail of it, making it useless to you.

regards

Alex

[leonardoaraujo.santos]

Thanks man we're waiting for it!

[DavlexDesign]

Thanks man we're waiting for it!

That's nice to hear, thought no one was interested due to the lack of comments compared to the views.

[Nauk]

Thanks man we're waiting for it!

That's nice to hear, thought no one was interested due to the lack of comments compared to the views.

Definately a cool project and I am interested too

*edit* Just watched the video, very decent framerate aswell - What are your system specs if I may ask?

[DavlexDesign]

*edit* Just watched the video, very decent framerate aswell - What are your system specs if I may ask?

Intel Core 2 Duo, 2.8 Ghz, 2 GB RAM, GForce 9800 GT Video card

Not a real flash machine, but gets the job done

[mariusz.plaskowicki]

Are you going to release demo? I would like to check it on my machine.
This look really nice. Did you thought about licensing? Is this going to be open sourced?

I don't have much time to play with ogre but I would gladly test this lib

Cheers
Mariusz

[leonardoaraujo.santos]

Alex I think that like me the other folks are just so busy with work and stuff and in my current job I handle more with image processing than games That's why normally people just read the threads but don't respond. Anyway your ROAM planet render is very nice (I've already read something about it just don't remember where.)
I currently I have 2 main hobby projects....

1) A space like game (Currently using startrek meshes for ships)
2) A homebrew cpu in FPGA http://code.google.com/p/fpga-magic-1/

Would be so nice to integrate it in my space game......

http://www.ogre3d.org/forums/viewtopic.php?p=304338

Sources included

Come on alex relase it let's add some planets in my space game

Anyway guys sorry about my english (Is not my native language, I'm from brazil )

[DavlexDesign]

G'day Leo,
Like I said before, I will release it when it is actually useful ( as an alternative terrain plug-in or library), at the moment the engine works, but for an outsider to know how to use it, that would be hard.
It won't be long though, I have become somewhat obsessed with this little project, and work is moving along at a reasonable pace, I do have my day job though, and that tends to put a hold on things every now and then.
I'm currently implementing a dynamic chunking algorithm, and it seem to be functioning to a point, but I'm getting a massive speedup when actually closer to the planet or on the ground, great for shoot em ups and the like, but when farther away, say out in orbit and you can see the whole planet, I'm dropping the frame rate by too much for my liking, I'm trying to keep it running at just over 500 fps so that other game logic can have time to do it's stuff in a real world application (physics, ai logic,.... etc). It's currently running around 200-300 fps from out in space, and around 500 to 800 fps on the ground and low orbit, that's why I'm implementing this new dynamic chunking algorithm, that way it will run like before, as in the video I posted on you tube, albeit a little faster now with the new culling system I've already got in place, I assume that is the reason for the massive speedup on the ground and in low orbit.

Please be patient and when I let it out, it should be quite useful for all you guys out there.

Alex

[Moo_Juice]

Great!

EVE Online might actually be less boring if they employed this kind of tech and let people land on planets and fight it out.

[DavlexDesign]

G'day Moo_Juice,

Yeah that was what I thought, so I started writing this as a start to a new space sim I'm writing for my son, he loves online games, and he's really good at them also. The plan is to put together a MMOL game that lets you fly from system to system checking out other players planets, The planet generator you see here is all created from a single number, if I put in another number the whole planet changes, and that planet will be unique to that number, that way, when people are online, all I have to do is send a single unsigned integer number to the client, and a new planet is born in what ever system they decide to place a new planet.

As for the living content on the planet, The engine can already merge in user created Terrain height maps for where I decide a landing pad or dwelling may be placed, enabling me to create levels of a more conventional nature to be added on to the surface of the planet, that way I don't have to create a whole new tool to create the planets, I can use the stuff that's already out there.

As for the game play, my son is working on that already.

I'll be putting up a demo soon, so you can have a play, only the terrain at the moment, but I will like to get some feedback on any bugs or performance issues the program may have on various different hardware configurations.

Alex

[mathieutozer]

I'm really interested in trying a demo!

[mariusz.plaskowicki]

Looks like yet another Frontier to me, which is veeeery good. I'm waiting to play with the demo

Cheers
Mariusz

[Sovaka]

Davlex, don't be discourage by the lack of posts.

There have been two other notable projects of the same caliber talked about on these forums. Both projects seem to have died off tho I am sure one is still active.

The work you have done so far is very impressive and from what I have seen in the video, you are up there with what others have done.
I'm not sure if you have been watching these forums for all too long before you got stuck into it and tried your hand it but you have done the hard yards.

The main component of getting a visitable planet is done, all that needs to be done now is get a paged terrain system implemented, caelum and hydrax.
Maybe add a Deferred Lighting component too

There are plenty of skilled people here on the forums who would be more then happy to help out!

[trilobite]

I haven't commented in this thread yet, but I am happy to give encouragement.

My exoExplorer app definitely would benefit from this approach. Right now, I separate orbital views and on-planet views. Two completely separate scene managers running in two separate windows. Uninspiring.

Your ROAM planet rendering is beautiful and interesting. Several worries:

1. Implementing physics. All surface motion in my current system is handled by OgreNewt -- which assumes an unchanging gravity vector. But on a sphere, that will change constantly. Perhaps there are ogre physics wrappers that can handle such a thing. Others here would know.
2. Implementing the sky. Right now I use Caelum. It is wonderful. But I had to make many, many mods to it to make it more adaptable to different celestial circumstances on different exoplanets. Frankly, I hacked the thing and I'm not satisfied. I am very interested in SkyX as an alternative to Caelum. Your ROAM planet rendering system would be totally awesome if it could allow the incorporation of separate sky libraries.

Both of these operations seem very, very hard to do.

My wish is for a beautiful planet renderer like yours, with APIs to snap in external physics libraries and external sky libraries.

Thanks, and I hope you keep making progress in this effort...

[stealth977]

Also I would like to integrate it into Ogitor when it is ready to be used, of course if you would like to see it in Ogitor...

ismail,

[DavlexDesign]

G'day guys,
Thank's for the comments and info you gave me, much appreciated.

Work is still progressing with this thing, I've got the paging working, but not as nice as it could be ....

PlanetBB.jpg

As you can see, the chunking is working OK, still not dynamic though, I'm working quite hard to get it paging in and out
at an acceptable rate, it will come.

With regards to hydrax and Caelum, shouldn't be too big a deal to implement them I don't think, I have looked at them
but I will be implementing waves on the coast lines, and clouds that you can fly through and around in the skies, I have
some of these things running on older stuff that I was working on a fair while back (OpenGL and Native DirectX 7), and that's
what was the start of this project, I thought to myself, why not create a full planet for these routines instead of the traditional
skybox and terrain block with hidden boundaries that make the level look bigger than it really is stuff.

With regards to the physics side of things, you will be able to get away with one gravity vector per chunk ( a chunk being several
kilometers in width and length, so on a large planet, the vector change between chunks is quite minimal, so you wouldn't notice too
much on the borders ) which in turn is broken up into pages of more manageable pieces of geometry for LOD and culling
calculations. With a little bit of clever game area and object placement, I think that it shouldn't be a real problem.

With regards to Ogitor, I think it will be a perfect candidate for that, obviously the planet routines will need to be a little nicer than
they are at the moment, but I would certainly like to see it in Ogitor.

Once again, Thank you for the input,

Alex

[kajjjak]

Impressive, this is really cool and useful.

[Trancient]

Hi, I just want state my keen interest in your project also.
Love the vid on youtube,( I'd like to see it with some of JohnJ's paged geometry in action ).

You mention merging user created Terrain Height maps, this sounds very interesting, as one of my main questions would be the creation of unique terrain areas such as deserts, canyons, alpine, mesa's, etc.. even unique / 'alien' geography.
Are you considering some kind of texturing technique for allowing varied terrain styles to exist ( ie: not just height based ) ?

Anyway impressive work so far and I really like the fact you plan to implement some nice end-user features.

[DavlexDesign]

G'day Trancient,
Nice to here you like it so far,
Work is progressing well with this project, I've got allot more done on it and it's getting easier to use and faster to boot,
I'm commenting the code as I go now, to make it easier for you guys to use later on, and for myself, as it's getting more and more
complicated for me to edit and find things to tweak for optimization purposes, (as I add something, I think of something else I can get rid of
because the new piece makes the old redundant, etc).

With regards to just being height based, the Fractal height side of things is only for general topography of the continents, not the actual terrain detail,
I use a different mechanism for the actual detail, it's a mixture of Fractal and DEM, (I'll explain this)

The Fractal gives a finer height detail, down near the coastlines it tends to flatten the terrain a little so as to allow cities and the like to have a reasonably
flat ground to be placed on, where in the mountains it tends to jag (roughen) it up to mimick mountainous terrain (rocky), while in between the low and the high
it produces a mixture of the two, plenty of reasonably flat terrain for towns and such, and gullies and hills for interest.

The DEM is a small section of data (1024 x 256 DEM File (does not have to be this size)) that the engine uses as a modifier to the height data produced by the Fractals, what it does, is take the height and samples the DEM to get the topology around that height, and influences the Fractal height accordingly, that way I am getting the look of DEM data across the whole surface of the planet while only using a small sample of DEM Data. (if you change the DEM data, the terrain changes its look, so if you assign a different sample of DEM data for a certain chunk of the landscape, you can get a whole new look for that chunk (desert, rocky, riverbed ... anything you like)).

SampleDEMData.jpg

Which ends up looking like this ...

topography.jpg

You still have the option to put your own data for chunks or pages, but with a little clever DEM Editing you can get away with just about anything, while using only a very small amount of data. The fractal routines and DEM access routines a very tightly integrated with the paging system , so as to allow blending with user created data so that edges are(at the moment) almost seamless(I'm working on this to get it perfect). The reason for this stuff is that I don't think anybody expects to create height data for a whole planet, that wouldn't be easy (at a resolution of 12756 x 12756 km per cube face down to 0.5 meters even Blue Ray disks wouldn't hold that much data), but with this system you can have only areas of interest using your data (city streets, etc) while the rest of the planet can look interesting and take on any topography you like (Mars or Moon type terrain maybe).

The planet looks a little nicer from outer space now ...

FromOutrSpace.jpg

Hope this clears some things up for you.

regards
Alex

[DanielSefton]

Nice! The DEM system sounds awesome

Not sure if you already saw this, but HexiDave ported an atmospheric scattering shader which you might find useful:

http://www.ogre3d.org/forums/viewtopic.php?f=11&t=37072

[jtarbox]

DavlexDesign,

First and foremost, awesome work!

I am just recently getting back into game dev coding and was hoping to start fresh on the space game I had always had in my head. I really look forward to this addon. I had in the past toyed around with planet rendering (mostly based off of Sean O'neil's work), but never managed to get farther then a basic LOD mesh before I had to stop coding for a while.

I'm new to Ogre itself (ex-CrystalSpace dev), so forgive me if any of this is already obvious to a veteran Ogre developer. One thing that I was having issues wrapping my head around was the scale conversion for movement/location/etc as you're shifting LOD the closer you got. Example, say that your perspective is flying around space and you want to slowly move into the atmosphere and effectively get to ground level. Some questions that immediately pop into my head are, how do I scale drawing and placement of buildings and units on the planet vs in space? How do you scale the perspective movement down as it gets closer to ground level of the planet? Or is all this being handled by the engine itself?

Now in Sean's work, he's just demoing how to render a planetary object, not how to incorporate scaling from a astrometric unit level to say a meter level. I'm looking more into how to incorporate this into an application.

I'm going to be delving more into Ogre samples tonight as a learning session. I know it's a scenegraph based engine from my past attempts to toy with it, but I've not really gone much deeper.

-jtarbox