ROAM Planet rendering

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day guys,

I've been dicking around again, sorry !!!.
This time I have gone one step further with the refining and culling of the triangle mesh management and build system, I needed to do this to accommodate for the fully destructible terrain stuff (we all know that this is what we need in a planet engine, and who wouldn't want that ?).

The reason I went into this is memory bandwidth, Minimizing what I need to send to the GPU to give me a better approximation of the terrain without too much unnecessary wastage, refinibg stuff that isn't really that important in the scheme of things....
Terrain Mesh refinement  at reasonably high altitude
Terrain Mesh refinement at reasonably high altitude
Water Mesh refinement at same height as above.
Water Mesh refinement at same height as above.


As you can see from the above pics, the triangles are allot more tightly packed only where they are needed. Stuff under the water / oceans is left alone more, not needing to go to such a high resolution.
I know, "But look at all those triangles outside of your view, they go all the way around, what's with that ?" you might say. Well, I have noticed that most of the successful games out there allow you to spin pretty fast in a circle to see who is shooting at you, or attacking you from behind, with the nature of ROAM and it's update methods, I need some pre cached triangles in there to accommodate doing a fast spin turn, now you can turn 180 degrees in .25 of a second, and the mesh has time to update enough to give a good approximation of the terrain, and expose only minimal vertex morphing to the players camera, on flatter open areas of the terrain, there is no noticeable morphing at all, in the rugged mountain tops and steep gullies, you still see some, but it is minimal.

You will also notice that the ocean gets clipped off allot better too (second picture), that's thanks to the more refined coastal wave setup, I'll explain that in a tick.

more to come....
Alex
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day again,
Mesh at a lower orbit.
Mesh at a lower orbit.
Water mesh at same altitude as above.
Water mesh at same altitude as above.
At this altitude you can see the stuff that is closer to the camera, you will notice the shore refinement is happening independent from the terrain refinement, I needed this so that when you are on a mountain top close to the coast, if you looked down to the beach, you can still see the waves rolling in, especially if you have a telescopic sight or something like that on a weapon maybe ( all these cosmetics are in there for game play reasons mainly).

You will notice that my refinement frustum is also curved, starting out at right angles to the view vector, and curving back in to something closer to the conventional view frustum in the distance, this is to give me that cache of triangles already refined for the fast movement I mentioned before, and working out that curved frustum is cheaper than working out a straight one (would you believe ?).

A little more to come ...

Alex
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

And Again,
Close to camera terrain refinement pattern.
Close to camera terrain refinement pattern.
Coastal detail refinement and culling pattern.
Coastal detail refinement and culling pattern.
Here we are close enough so you can see the individual triangles closest to the camera as well, these are there (all the way around the camera) to facilitate the Physics mesh for high res contact close to the camera, I'm still yet to implement proper physics in this setup, but those triangles in the finest and secondary ring get added to a list for sending to the physics library (of your choice) already, now the data that gets sent is the final position data, not the morph data, so sometimes you may see the terrain come up to meet the object resting on it (but very rarely).

Now, also, if you look at this structure in the mesh, it lends itself perfectly for a pre lodded Octree sort of setup, that will allow me to create a nice layered fully destructible terrain system, with no T junctions in the mesh, and it will allow something similar to the Overhang Terrain Scene Manger thing. I am still working on this too, as the memory footprint for this was starting to blow out too much for my liking, hence the reason for a more selective mesh refinement system. Plus storing mods for a whole planet, would be a nightmare, but storing modifiers (position based algorithms) is possible.

Alex
Alexiss
Halfling
Posts: 74
Joined: Wed Aug 10, 2011 2:11 pm
x 11

Re: ROAM Planet rendering

Post by Alexiss »

Looking good ! When can we expect something like this ? http://vimeo.com/32001208 :)
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day Alexiss,

Nice video mate !

So now you want me to include the planets Magneto Sphere affects on the atmosphere too ? ( OH MY !!!).

Interesting play of light scattering in that video too, it's the first time I have seen green so prominent in the atmosphere on the darker side of the planet, must be something to do with pollutants and city lights reacting with the scattering of sunlight or something too, or it just could be the lo light cameras CCD over compensating, not sure.

I especially like the lightning in the clouds effect, food for thought there.

Alex
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: ROAM Planet rendering

Post by Jabberwocky »

To me, destructible terrain seems like a somewhat obscure feature given the general scope of planet rendering. Although I'm sure opinions will vary on this.

On the other hand, this:
it will allow something similar to the Overhang Terrain Scene Manger
is a lot more interesting to me. I think being able to break from the traditional heightmap limitations (overhangs, etc) would be a huge selling feature. Are you using tri-planar texturing, or something similar that will work to procedurally uv-map this stuff?

Either way, the terrain mesh refinement screenshots look very cool, and seem like a performance win regardless of how the tech is used.
Image
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: ROAM Planet rendering

Post by Jabberwocky »

Another concern is terrain physics. Presumably you, or other people using your tech will want to do things like walk around on the planet. Adding physics to destructable planet terrain might be pretty tricky. You certainly won't be able to use pre-baked heightmaps or physics tri-meshes. Fast, run-time recalculation of the physics for a vast, destructible terrain might be a major technical challenge.

On the other hand, maybe some games wouldn't bother with terrain physics at all. Some space games that allow planet landings are very simple, you just kinda fly down to a landing pad, and you never get out and walk around. So it's awesome eye-candy, but less interactive. Or maybe there's some middle-ground where you can walk around on certain pre-defined, non-destructable sections of the planet? I could also imagine ignoring "real physics" altogether, and just using graphics-mesh raycasts to position a character on the landscape (or whatever technique you're using to place vegetation on the planet surface). But would this get pretty tricky with overhangs?

Perhaps traditional physics is a near impossibility anyway, given the huge amount of data involved, unless you can somehow stream physics data into a physics lib in the same way you stream graphics data to the gpu.

Have you put much thought into terrain physics at all? Do you plan on being able to walk around on your planets?
Image
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day Jabberwocky,

I can walk around on the planet already, with a kind of raycast setup that gives me a terrain height underfoot no matter where I am on the planets surface.
I have given a great deal of thought to Physics for the planet, albeit localized mainly (out to around 2km) the mesh is structured in a way that allows me to throw / stream the mesh (lo res) to the Physics library without too much difficulty. Stuff that is out in the distance can get away with a simplified physics implementation, but close to the camera, anything but good accurate physics would in my opinion be a NO NO. The overhang handling for the terrain is an interesting one, you can't just look for what is under foot any longer, and have to be able to look at what is above as well (inside caves and such), I'm still working out the finer details, but it shouldn't be a real problem.

As for the fully destructible stuff, that's not a real issue either, when it comes to physics, streaming a few thousand triangles to the library is relatively easy, and the way the effectors modify the terrain, punching holes in the terrain and updating the physics contact mesh with these effected areas is relatively simple as well, my main concern is the storage and retrieval of these effectors. I know I can do it OK because really all I need to do is store a coordinate vector which is an offset inside the current page, and a byte for the effector brush formula, that way I could be able to have 127 different brush formulas, positive numbers for adding to the terrain geometry, and negative numbers use the same formula for positive, but take away from the terrain. lastly another byte for scale, so theoretically I could store a series of effectors with only 1 float vector and 1 int (4 bytes), so I could have allot of effectors per page with minimal amounts of ram used. It's finalizing the brush techniques that is the hard part. I don't see myself using 127 different formulas, so I'll see what I can dream up, and then I will finalize the storage structure.

It's all doable, it's just a matter of implementation that will make all the difference, it will be great to be able to have all this stuff working, but if it makes the thing run like a bag of shit, well, another thing to put on the scrap heap, and man!!! have I put a few on the scrap heap already. I add in these things that look nice, but make the engine run like a bag of shit, so I scrap them, but always keeping them somewhere where maybe when I'm implementing something else, it opens up a new possibility for one of the scrapped routines, that's happened too, more than just once or twice.

Alex
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: ROAM Planet rendering

Post by Jabberwocky »

Cool. I was concerned that landscape physics might be a serious blocker for the overhang/destructable stuff. But it sounds like you've thought it through, at least far enough that it's worth a shot to see how it performs.
Good luck!
Image
palaslet
Halfling
Posts: 61
Joined: Tue May 25, 2010 7:52 am
Location: Fredrikstad, Norway

Re: ROAM Planet rendering

Post by palaslet »

Alex,

Are you using a mathematical formula to decide the lod, or do you just go with some preconfigured levels? I can see that your lod edges are quite... well... edgy... :)
"It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away"
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day palaslet,
palaslet wrote:Are you using a mathematical formula to decide the lod, or do you just go with some preconfigured levels?
It's all formula based mate, it's all decided by an error metric (screen space) and distance for the base refinement.
palaslet wrote:I can see that your lod edges are quite... well... edgy...
umm ! what does that mean ?

Firstly I keep the base triangle mesh tessellation based on distance so that I'm always working on a relatively constant triangle size in view space, and if any of the triangle's edges midpoints are too far from the edge axis, I also split them so that they keep the mesh looking truer to the topography of the terrain my formulas are trying to create. If that makes ant sense to you ?

Alex
palaslet
Halfling
Posts: 61
Joined: Tue May 25, 2010 7:52 am
Location: Fredrikstad, Norway

Re: ROAM Planet rendering

Post by palaslet »

Hi Alex,
umm ! what does that mean ?
No criticism intended :)

I just saw the easily identifiable circular borders in the picture bellow, where you got a small inner circle and a larger medium circle, and then you have the large outer circle, all with clearly visible borders.
My reason for asking was that I struggled a bit with my own ROAM implementation because my LOD formula drained a bit too much CPU. Division isn't a CPU's best friend you know ;)

Image
"It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away"
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day again palaslet,
palaslet wrote:I just saw the easily identifiable circular borders in the picture bellow, where you got a small inner circle and a larger medium circle, and then you have the large outer circle, all with clearly visible borders.
OK, like I said, those circles / lod borders are based on distance from the camera, to keep the triangles in view space approximately the same size.
palaslet wrote: Division isn't a CPU's best friend you know
I know this, but just a little hint, "maybe you are trying to do to much per frame" try and break up the update maybe, set a maximum amount to accomplish per iteration of a loop, and only when there has been enough modification, update the buffers on the GPU, that way, your algorithm won't take all of your clock cycles per frame. Update the GPU buffers every 10 or so frames maybe, because if you can get your core CPU running at 200 - 300 frames per second, you can afford to hold back the updates for that long, as 200 fps means update the GPU 20 x a second, plenty fast enough for smooth movement.

Alex
aeongabe
Gnoblar
Posts: 3
Joined: Thu Dec 31, 2009 5:35 am

Re: ROAM Planet rendering

Post by aeongabe »

is something like this ever going to be released so I could play around with this with my geospacial height map tiles?
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day aeongabe,

Yeah, all in good time, all in good time.

How many Gigs of geospacial tiles do you have ?
I gather they are of Earth, Mars or Moon, as they are the most readily available. I do have support for them in there, but that's really not the purpose of this whole system, this system started out as a fully procedural setup (proof of concept), and it's coming along, albeit a little slow for my taste, but life gets in the way allot, I wish I had more time to dedicate to it. If I could earn a living doing this thing, I'd have it up and running in no time at all. Alas, if I have to wait, so do you, sorry.

Alex
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day guys,

Been doing some number crunching on this little proof of concept planet, because it will be fully populated in the next few weeks (well it's nearly there, just have to do some weirdness to get it to run smooth) but ....

Even with a little radius of 667544.2144301 meters I worked out the surface area of this sphere (without heights in the mix) and that gave me 5,599,766.737521977 kms squared in total, worked out with (sphere surface area = 4 * PI * (radius * radius)), I think that is right.

Now take away 60% for surface area covered by water and I'm left with around 1,903,920.44 kms squared to populate. This was a little more than I expected, but hay, if I can achieve a Pandora type populated planet, and have it run smoothly, This thing should be able to handle anything I can throw at it.

Just some food for thought there.

Alex
ultramedia
Halfling
Posts: 62
Joined: Thu Dec 07, 2006 3:02 pm
Location: QLD, Australia
x 2
Contact:

Re: ROAM Planet rendering

Post by ultramedia »

WANT
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day guys,

Just a little update on how this thing is going.

I have managed to setup a zoning system that is planet wide now, actually uses only a couple of hundred Kb for the zone boundaries to be stored (proceduraly) and has caused no frame hit whatsoever. The boundaries go out to around 8 km or so in around 120 meter or so square zones in a circle around the player, these zones and distances are configurable, so we can tune them to what works best ( I will have to experiment with this a little ), the zones on the very outskirts of the boundary will be left alone so they can be created and destroyed very quickly (allows the player to fly pretty fast over the terrain at reasonably low altitudes), but inside that boundary the more stable zones will get Prepared for display, and inside that boundary they will start to show their content to the player.

I know this all sounds familiar for people who have played with the PagedGeometry library, I like the idea of Page Loaders and layers of data per zone, and seeing that most of the mainstream Ogre Editors use PagedGeometry for some of their stuff, I thought I should make this thing pretty much compatible with that library, the base Class will be a little different for initialization, but all the page loaders and things should be interchangeable, I'll see how I go, but hopefully I can make this thing useful for other configurations (never ending flat terrains) too.

I'll keep you guys informed of my progress as I go.

Alex
User avatar
aguru
Goblin
Posts: 236
Joined: Tue Feb 26, 2008 5:48 pm
x 3

Re: ROAM Planet rendering

Post by aguru »

Thanks for the update! Great to hear about your progress.
ultramedia
Halfling
Posts: 62
Joined: Thu Dec 07, 2006 3:02 pm
Location: QLD, Australia
x 2
Contact:

Re: ROAM Planet rendering

Post by ultramedia »

Awesome work Alex, just keep pluggin away and you'll get there :)
HeadClot
Gnoblar
Posts: 10
Joined: Sat Jan 08, 2011 5:50 pm

Re: ROAM Planet rendering

Post by HeadClot »

Hey, Sorry for the thread necromancy

But is ROAM available for download?

I am very curious to see how this ticks from the inside :)

Also would this code be able to work with other game engines? ( CryENGINE 3, Unreal, etc )

Since I have not seen the code yet I might as well ask.

Thank you for your time -

Ben Stanley
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day HeadClot,

(interesting nick name !!!)

Anyway ....
HeadClot wrote:But is ROAM available for download?
Not yet mate, sorry, if you look around on the web, there are a ton of implementations of ROAM out there that you can get your head around if you want to understand how ROAM works, it's not a new algorithm, as for my implementation, it's not all that different, I run a Merge and a Split loop like the others, I use Midpoint displacement like the others across the longest edge, so, it really isn't that different.

What I do with the data supplied by the ROAM algorithm is another thing, but that will come, I'm not completely satisfied with it yet, I know I can get it to do better.

Alex
nikolai
Gnoblar
Posts: 3
Joined: Sun Apr 03, 2011 2:54 pm

Re: ROAM Planet rendering

Post by nikolai »

G'day Alex,

I love the work you've been doing on OgrePlanet! Do you think you'll ever write a paper or dev journal detailing the concepts behind your engine, and the solutions to the many problems you came across developing it? Judging by what I've read since following this thread for the last year or so, you are quite good at explaining concepts in a way a novice like myself can understand.

Keep up the good work!

Nik
User avatar
DavlexDesign
Orc
Posts: 400
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
x 19
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign »

G'day nikolai,
nikolai wrote: Judging by what I've read since following this thread for the last year or so, you are quite good at explaining concepts in a way a novice like myself can understand.
Thank you very much for that, I was wondering if I was getting some of my points across.
nikolai wrote: Do you think you'll ever write a paper or dev journal detailing the concepts behind your engine, and the solutions to the many problems you came across developing it?
I most definitely will, once I have got this thing looking like something that people would really like, and iron out a few of the not so friendly bugs (meaning some of the hard coded hacks I have in there for concept development), then I will start a dev blog, that will have a ton of info in it.
I warn you though, my explanations can get pretty long winded, just ask sovaka, I've been boring him with my long winded rantings for over a year now.

Alex
User avatar
Sovaka
Greenskin
Posts: 109
Joined: Sat Dec 20, 2008 6:26 am
Location: QLD, Australia
x 3
Contact:

Re: ROAM Planet rendering

Post by Sovaka »

Isn't it more like 2 years now mate? ;)
Post Reply