ROAM Planet rendering

[trilobite]

Alex:
Nice to hear about your progress. Given the enormous scale of this effort, it seems more than fair that you should get SOME monetary return on it. No doubt you guys have discussed this a lot, as Sovaka indicates.

You know: 1) having a free open source package for hobbyists and enthusiasts (satisfy your "Give Back" gremlin); 2) then a modestly-priced commercial package for indie developers (get some back); 3) then a premium pro package for big studios (get a lot back -- you've earned it).

The reason I say this is that I am afraid that if you don't get some kind of material return on your efforts, you are more likely to abandon the project after its initial release -- and that would be a shame.

I have big plans for your project that will require a substantial amount of work on my end to integrate into my free, open source exoExplorer application. I would need to do much redesign of my app. So, by suggesting you have some sort of commercial plan, I am really looking out for myself here. It is actually better for me if the ROAM library has a bright future of active growth and refinement -- and THAT is more likely if you guys are making money on the deal.

And I hear you on the uni fees...

Best of luck to you.

[DavlexDesign]

G'day trilobite,

Well, thanks for the well thought out feedback, what you say there with those options sounds great, and pretty much sort of what we do have planned in a way.
We will give the source of the planet renderers' basic (but complete) mesh generation away for all to use, with the access interface to pull out all the information from it that you would probably ever need.
For the Indie well, they will get the nicer extra stuff ( destruction, flow simulations, shoreline wave generation, stuff like that, in library form probably), and for the commercial, well, access to the source for all of the nicer extra stuff. Just food for thought, not final yet as how we will break it all up, but to get the engines terrain generation, I feel everybody should have access to that, as I utilized some ideas from others for starters, well, they gave me a starting block anyway, and to keep that from people would seem a crime.

Don't worry about this thing being stopped working on, It has sort of become an obsession now, I don't think I could ever stop working on it. It keeps my brain active, and in my opinion, that's what keeps you young.

Alex

[DavlexDesign]

G'day guys,
Just a little quickie again, been distracting myself from the big project, and started playing with the terrain shader a bit.

Glaciation.jpg

If you look at this shot, you'll see that there is almost a Glaciation happening here, the snow stays longer in the crevasses, I remember a comment about this in a previous post from ( palaslet on page 11 halfway down).

The snow line look pretty linear. That's actually not always wrong, but usually it is . Since erosion will create small valleys down the mountain side, some of the snow will be preserved in almost constant shadow here. Also the snow tend to pile up in these valleys making it harder for the sun to do it's job even if the valley got much sun.

I'm pretty happy with the look now, the shader seems to be doing what it is supposed to, and I've also improved the detail on approach some what too.
One thing I find confusing about this terrain engine though, is it seems the more I add to it, the faster it seems to run, very strange.

The shader is still a one pass shader at the moment, and it still seems to hold its own, I use the same normal mapping shader from outer space to the ground. so there is no need to have some ugly lo res texture out past a certain distance ( I really hate that look ).
I remember reading a post in some other planet engine forum about how our texturing looked really lo res or something, well I think it doesn't any more.

Let me know what you think.

Alex

Alex

[palaslet]

Wow!!

This looks amazing now. It adds lots of realism. Just like the waves did on water level.

Keep it coming!

Any plans for a short demo video to brag more about these new achievements?

PS. If you want to go all the way; the glacier should probably have a small stream or river flowing out of the bottom. I think it would really help to break up the border between the snowy and the temperate zone. (Just to keep you busy)

[palaslet]

Guys,

Another thing just popped into my head when I saw the latest picture:

Have you given any thought to simulation of seasons? Calculating the distance and pitch of the planet in relation to its sun(s), and adjusting temperatures accordingly. Also the temperatures at night might be lower. When taking into account the type of atmosphere you could possibly classify the planets and adjust night and day temperatures. Allowing ice to form on small ponds over night and such. In a game where you can walk the surface you might have to find shelter at night (or day) not to loose health because of the temperature.

Night and day temperatures might not seem like a very important matter, but if we look to the moon where one moon day equals about 29.5 earth days. That means that the moon night lasts for about 14 earth days with temperatures down to 70 Kelvin (-200 Celsius or -330 Fahrenheit) and the day last for about the same time with temperatures up to 390 K (116 Celsius or 242 Fahrenheit). This would of course have enormous impact on equipment and body of any traveler. And any possibility of flora would die before it could evolve at all. Imagine flying from the hot zone into the cold zone in a ship at a couple of hundred miles per hour... Your instruments would go mental

Any plans or thoughts on that?

[Sovaka]

Yes we have.
We've come up with a heat map idea for the planets.
Basically all elements are going to be taken into account; Like distance from the sun, planet rotation speed, planet tilt, planet core.
It's actually a model I came up with to give us reasonable seasonal changes.
In coordination with our wind sim, our heat map should be dynamic enough to give us what we need.
Desert's, tropical rain forest's, tundra's... If the planet supports that of course.
We may end up with planets like Tattoine.

There isn't much we haven't thought about.

But it is these nice extra's that wont be given away in the Open Source planet engine.

[palaslet]

There isn't much we haven't thought about.

I believe you, It's quite exiting to follow your work.

I saw you mentioned your own game some posts back... Do you plan to blog or post about the development of that game. I'd really like to follow that work as well, and I'm sure I'm not alone when it comes to that. Can you tell us anything about the plot for the game? I know it's kind of "off topic", so I will nag you only once about it... ...On this thread anyway

[DavlexDesign]

G'day guys,

Just frigging around, wasting time looking at how the terrain detail is working and came across this view.

High_Altitude.jpg

I'm pretty happy with the distant detail now, it seems to be getting better all the time.

And here's a shot from nearly on the ground, with a little detail in there

On-the-ground.jpg

The lighting is still a little harsh on the props, but I'm working on it, and also note the frame rates in these shots, I'm pretty happy about that also.
I'm trying to keep the whole thing running at above 120 fps, so that it will handle true 3D, that way you will be able to feel the real scale of this thing.

Alex

[LordBaal]

unsurprisingly awesome!

[ems1965]

Alex,

I just discovered this Thread on in spherical terrain and I just spent a lot of time reading over this... It is amazing... I have been after this for a long time, not having the knowledge myself I started to ask around and most programmers said that their projects were dead but were unwilling to share their code. I'm looking to generate a Planet that I can land on... Simple as that... When are you going to release or sell your products?

Thanks and Best Regards,
Eric

[Jabberwocky]

The latest landscape screenshot is looking pretty cool. I definitely get the sense that I'm gazing out across an alien planet.

Once you guys get to the point that you can start investing in some alien-looking foliage, I think the "close-to-planet-surface" shots will look equally impressive. You probably don't have the cash to throw at it yet, but I'd love to see what could be done with speedtree on your terrain. Toss in a good speedtree artist with an affinity for making freaky alien plants, and you'd be golden.

[jacmoe]

Woody is a great alternative with an excellent (low) price tag.

[Sovaka]

Well we are aiming to have SpeedTree in there, OgreSpeedTree but as stated, we don't have that kind of funds to throw at it yet.

jac, what's Woody?

[Sheen]

Sovaka, it's amazing real-time 3d tree engine for an amazing price. Check this out - http://woody3d.com
And here's topic about using it with Ogre - http://www.ogre3d.org/forums/viewtopic.php?f=1&t=64962

[DavlexDesign]

G'day Sheen,

In the post about Woody Integration, that url to the code doesn't work, pitty, could have given me a good heads up on the integration.
Anyway, Yeah we are looking at Speed Tree and Steve's Ogre Integration but I am not willing to output that kind of money just yet.
I like the sound of Woody too, looks promising, I've downloaded the Eval' API SDK, so I'll have a look see.

I'm currently getting the procedural river systems up and running, I'm really close, but working out the formula to pick where the rivers are meant to be, without knowing about the heights around the current vertex was really fun, I do have it working, but it sort of creates too many rivers and lakes, so I'm making it work as a probability flag with priority, so in theory, I can now place an emitter anywhere on the planet, and following the flow is a piece of cake, as the river curve can just follow the higher priority vertices, very simple, and no extra cost to the mesh generation, still getting 300-500 fps, so I'm happy about that too.

OH yeah, nearly forgot, I've come up with a really cheap new Hemispherical lighting algorithm for the planet, that will allow me to get the right horizon colors very simply, and actually color the atmospherics to match, so I get a better mix at the horizon, plus the ambient lighting will be more in tune with the surroundings, so the lighting will look allot more real, and not so harsh. And another side effect of this is that I will be able to get variable colored scattering, and ground fog density, as well as simplifying my cloud lighting.

Anyway, I'll keep you posted on stuff, and hopefully I'll get a new video up shortly, I didn't want to just put up another mesh demo, I want this one to look nice.

Alex

[Sheen]

Alex,
I have some code here - http://sheen.me/ogre/WoodyToMesh.zip
It's not compile-ready, but has all Ogre related stuff (*.wdmesh loader & material scripts) and I hope it'll help you.

[DavlexDesign]

G'day Sheen,
Thanks for the link, I grabbed the stuff and had a look, I'll have a go at the Woody Tree integration soon.

I was just playing around with the rivers again, and cleaned them up a bit, still not right though, It's a real brain teaser, trying to get them clean on approach to the planet, as well as getting them down to a realistic size.

RiverShot01.jpg

If you look at this shot, they are not too bad, but average several kilometers across, as in allot of km, Also don't worry about the crappy coloring, that is only for me to see what's going on, I am still debugging it, plus the placements aren't exactly correct, they aren't exactly following the topology correctly. Like I said, a real brain teaser. I could solve the whole problem by doing a pre pass and calculating the curves and caching the results in a bezier curve definition file maybe, but then the first time you load the planet engine, there will be a delay of maybe up to a minute to calculate the paths, but that would only be for the first time you view it, then that definition will stay with the planet until you modify the terrain fractals.

Do you guys think that would be acceptable or not ?

Alex

[palaslet]

Alex,

I've been following this thread for over a year now, and I thought the whole idea was to have a seamless approach with no in-game loading, minimal storage, excellent framerate and little memory usage. All so that the game developers could use all the juice for a good gaming experience. How will this preloading interfere with those goals? What if you construct a universe like EVE-Online and need to pre-load all planets? With this engine the universes can potentially contain millions of planets. That would pre-loading do to such game environment?

Maybe you could try to explain how you calculate the paths now, and some of us might post something that is either a better way, or at least inspire you to tweak the solution you have in the right way.

If it's not top secret that is.

PS. On the pictures the rivers seems to contain constant amounts of water. I can see rivers split into more rivers, and other joining without it affecting the width. Any comments on that?

[DavlexDesign]

G'day Palaslet,

Yeah, those river systems you see in that pic, are pretty crap, It was done using a fractal to build up the path, not what I'm actually doing, just wanted to show you guys I was working on it. The newest ones actually generate from the topology makeup of the terrain, but through an internal formula.
What I mean by that is ...

I get my base terrain topology with one set of fractals, but that set of fractals are split as such, so I get my separate layers, and from those layers, I do an internal build of the actual resulting terrain height at that point, but with the heights separated like that (for the one point on the planets' surface) I'm roughing out the probability that this point may potentially be a river bed. It does work ok, but not to a fine enough detail for me, the problem I'm having is the lower altitude terrain areas are working with very small fractions of numbers in the range of -1.0 to 1.0, I then multiply that out to the maximum height for the planet, approximately +-8 km, so when I'm in the sub 1,000 m, it gets tougher to work out if this point is a gully or a rise. Up higher in the hilly / mountainous regions, the algorithm solves quite well, but still the rivers and creeks are too wide nothing less than say 100m across. I am still working on it.

As for the preload, well, I can generate the heights and textures and normal maps in a flash, but seeing that the planets and moons and stuff a relatively far apart, when the camera starts to move out of a bodies zone of influence, and into another bodies', I can do the calculation over time, so by the time you get close enough, the systems are in place for the current active body. I did say in my previous post, about storing the bezier curves in a file for the planet, that doesn't mean I will have millions of bezier config files, I would only have one for current planetary body (if it has flowing water on the surface). So it wouldn't be a problem in game, as you wouldn't be flying around at stupid speeds (like in the current simulation) in the atmosphere, and on approach, so there would probably be plenty of time to generate the relevant information on the fly, in the background. I should have been more clear in the previous post.

The reason for the question at the end was for the initial simulation, when you first start the application, we are already inside the influence zone of the current planet, and the simulation would have to go through a prebuild, before you would see anything.

In game, because you have come to the current planet from out in deep space, and have left the initial planet you just left (or asteroid field ,space station, etc) the new planets' data would already be built while on approach overwriting the old data with the new for the current planet. This way, having millions of planets will not mean you need terrabites of data stored for places you would probably not go back to for months. Also if you leave the application while inside a planet's zone of influence, the prebuilt cache files would already be there, so it wouldn't have to go through the process again for the next time when you come back into the simulation at the point where you left. I have thought about this stuff, working on ways to make this thing as seamless as possible for the player, Sovaka has allot of great ideas in respect too gameplay and seamless experiences for the player( all parts of a major wishlist he has given me), and I'm in the middle of granting him all his wishes. The beauty is, that Sovaka is an experienced game player (like my son Matthew) and has thought allot about the short comings and benefits of allot of the more popular games out there, so If I can pull off just some of the stuff in that wishlist, you guys are gonna be in for a treat (game play wise, and visually).

Hope this clears up some concerns for you.

Alex

[palaslet]

I totally see your point about sensible speeds towards a planet and such. And after thinking it through one more time I completely understand the need to precalculate the river paths. But 1 minute? What if you in a multiplayer stargate gameworld are approaching a stargate (already dialed in, so you can't hide the precalculation in the dial process) in a fast veichle (a couple of hundred kph). Then you have to start the precalculation way up front. And with that taking up your CPU, the AI and terrain generation must suffer. Right? So then the quest must be to do the calculation as effective as possible.

You said you use bezier curves for storage of river paths. Any possibility to use bezier surfaces to represent the topography during calculation? Because then it should be fairly easy and a low cost operation to scan that surface for lowpoints for the river to flow.
But... since you are using fractals for topography and bezier surfaces is almost impossible to render correctly in a 3d world without using huge amounts of processing power (so fractals is the best way to go when it comes to rendering), I suppose the conversion between meshes and bezier surface would eat any gain you get from using bezier as calculation reference...

Or is your underlying topography calculation of the sort that might easily transfer into bezier surfaces?

[DavlexDesign]

G'day Palaslet,

1 Minute was a pretty shitty estimate, I can render up 6 or so 1024x1024 height maps including normal maps per second, add in the diffuse map and that would probably take another few milliseconds, so the pre-calculation really isn't a huge problem for the topography, as for the bezier curves, they would take a little longer as I have to do allot more taps into ram, I'm still working on the river idea, and the bezier curve idea was just a throw out there idea, I'm not actually using beziers, but I may have to, I have a few more tricks up my sleeve before I resort to that one.

For the stargate idea, there is still that nifty whoosh scene where you would be flying past stars and through solar systems, that would have to last 2 - 5 seconds, so that would probably be plenty of time, maybe.
As for a fast vehicle, a couple of hundred kmph, When I fly around the planet at low altitude (just below the clouds) the camera is moving at around 4,000 to 6,000 kmph (while holding down shift), if I go any slower now, it drives me crazy, because it takes me too long to go look anywhere otherwise, and even at those speeds, the morphing is now down to a bare minimum.

I don't like the bezier idea, due to the cost of such a calculation as well, that's why it will be a last resort, as for the topology being bezier friendly, well, the terrain mesh is pretty friendly for any calculation / lookup, I have a nifty little re index routine in there that takes the global vertex cache and triangle list, and order it into a GPU cache friendly triangle list for the pages of the terrain, not to mention distance sorted on the fly triangles in CPU RAM per page, so finding triangles and vertices is a piece of cake too, I can access any vertex structure as an array pointer as well, so if I push any integer indexes into a list for special processing, I can access each vertex structure with just one lookup anywhere on the planets surface, and then I can reference any piece of that structure from that structure pointer, another thing I always go by when it comes to coding is "Calculate Once, Use many times", hence the speed I can achieve with this Paged ROAM thing. With the vertex structures, I tend to use a little more RAM than necessary, but hay! what's a meg or two now days, if it keeps the thing humming along nicely, why not use a tiny bit more.

You know something, I should make a new video of the way this thing travels now, just to show you what I mean about the morphing, it's not too bad, also you can turn on the spot relatively quickly while on the ground now too, and you don't notice any serious morphing too, even without trees and grass to hide it. I might do that, before I show all the nice bits, just so you can see the difference between before and after.

regards

Alex

[DavlexDesign]

G'day again guys,

Just been mucking around with the terrain shader again, It's still single pass, but I think it is starting to come up nice now.

PureTexturingShot.jpg

I added in a lighting only mode so that I can get an accurate look at how the lighting in the engine is going.

PureLightingShot.jpg

What I did was replace the diffuse atlas with just a pure white texture, and left the normal, AO and spec maps in place.
You'll also notice, that I have enhanced the details in the distance (20km or so in this shot) some what too, hasn't hurt the performance any either, which surprised me.

The reason for this is so that with the new spherical lighting setup I'm working on, I can see exactly what is going on in the engine.
Hope you like it.

Alex

[DanielSefton]

The shader does look better.

Will the spherical lighting you speak of make the landscape brighter? I mean bright like: http://www.infinity-universe.com/Infini ... ain_41.jpg In fact, your debug shot seems a lot brighter than the actual render.

Also, your screenshots seem really low quality and compressed, you should upload high res PNGs or something

But great work as usual, always look forward to seeing progress on this.

[DavlexDesign]

Here you go DanielSefton,

These shots are taken with the sun almost directly above the area in question.
OH yeah, took ages to find this damned spot again, do you guys realize just how big this frigging planet is.

PureTexturingShot2.jpg

Don't worry about the red patches in the shot, they are actually red numbers that are placed in the atlas in the center of each tile, so I could see if the tile look up was actually fetching the right tiles.
And now for the lighting shot.

PureLightingShot2.jpg

OH, and this pic shows the lod blending of the textures, because this shader has to work from outer space to ground level in a single pass, I needed it to blend in the Diffuse, Normals, AO and Spec properly, otherwise the data looked crap when you got close to the ground. I'm using just 256x256 tiles inside a 1024x1024 atlas, I made up a 2048x2048 atlas, with 512x512 tiles in it, and it looks a hell of allot better, but for the moment, these will do, until I want to make it really pretty.

Diffuse_Lod_Blending.jpg

Hope that satisfies you mate.

Alex

[DavlexDesign]

G'day again guys,

Just been flying around making sure the lighting worked right on the other side of the planet, and I found this spot.

Mountain_Scenery.jpg

I'm getting really happy with the fractals now, they are starting to really come into their own now, producing relatively realistic mountain formations.

What do you guys think ?

Alex