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
ultramedia
Halfling
Posts: 62
Joined: Thu Dec 07, 2006 3:02 pm
Location: QLD, Australia
Contact:

Re: ROAM Planet rendering

Post by ultramedia » Fri Aug 06, 2010 11:00 am

*Dude* you're in Queensland Australia???

I'm on the Sunshine Coast (but I teach 3D one night a week at Griffith Uni in Brisbane).

Small world ;)
(Get it? Small wor... nvm)
0 x

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

Re: ROAM Planet rendering

Post by Sovaka » Fri Aug 06, 2010 3:16 pm

ultramedia wrote:*Dude* you're in Queensland Australia???
Yeah, Gold Coast, Surfers Paradise :)
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Sun Aug 08, 2010 3:45 am

G'day guys,

With reference to a previous post ...
DanielSefton wrote:Awesome.

Just one thing... How come the terrain looks so... Dark? It looks like night time (maybe it is?)

Turn up the sunlight, lots, I wanna see it in all its glory :) Some inspiration.
Here you go ...
FullDaylightTerrain.jpg
The Terrain in full daylight, no scattering
This is what it looks like in full sun for those that are interested, There is no scattering or any special effects in this shot, just the raw shader doing its thing.
Those mountains in the distance are around 20 km away I think, maybe more, forgot to look at the res of the map.
I'm working on a few other things at the moment, I'll keep you up to date.

Alex
0 x

DonPheromones

Re: ROAM Planet rendering

Post by DonPheromones » Sun Aug 08, 2010 5:58 am

Very Cool. Any estimates as to when it will be done?
0 x

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

Re: ROAM Planet rendering

Post by Sovaka » Sun Aug 08, 2010 5:59 am

DonPheromones wrote:Very Cool. Any estimates as to when it will be done?
When its done ;)
0 x

User avatar
Xypher
Gremlin
Posts: 180
Joined: Tue Jun 29, 2004 1:35 am
Location: Richmond, IN; USA
Contact:

Re: ROAM Planet rendering

Post by Xypher » Mon Aug 09, 2010 1:12 pm

Good answer! Let the Chef cook. No sense risking salmonella.
0 x
Ubuntu Studio 13.04 64-bit
GCC 4.8.1
Ogre3D 1.8.1
AMD Athlon FX 8120 @4Ghz
16Gb G.Skill Ripjaws (PC3-12800)
EVGA GeForce 560 Ti FTW

http://www.hellbatgames.com

Lord LoriK
Goblin
Posts: 254
Joined: Tue Feb 13, 2007 5:33 am

Re: ROAM Planet rendering

Post by Lord LoriK » Wed Sep 15, 2010 12:10 pm

It's been a month since the last time someone posted here, so this thread disappeared from the first page of the Showcase forum and I wanted to do something about it.

Now, let's get to business: the progress bar at your web has been stuck at 74% for a long time, and the thread has been too quiet. Can you guys give us a new teaser? We know you are working on it, but maybe there is something you can show us without spoiling the surprises you are preparing?
0 x

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

Re: ROAM Planet rendering

Post by ultramedia » Wed Sep 15, 2010 2:14 pm

While I can sympathize with wanting to have access to something nice like this, at the end of the day it's just a huge huge undertaking the guys are doing here and it's just going to take time (and probably a lot of it). I'm pretty confident that if they've managed to make it this far though, that they'll have the wherewithal to see it through to the end.
0 x

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

Re: ROAM Planet rendering

Post by Sovaka » Wed Sep 15, 2010 2:31 pm

The work is still ongoing :)
We are making every effort to ensure that an engine of this magnitude doesn't waste much needed clock cycles.
We have tweaked and tweak and tweaked.... and tweaked... :p
The terrain is a single pass shader so on the ground at the moment, we are seeing around 300fps.

And as for the progress bar, its stuck on 74% because we haven't done all that much to warrant a bump in the scale... In terms of what features we want in for the new teaser.
The way we have been working is as follows;
- Insert feature
- Tweak feature
- rewrite feature with tweaks in mind
- Tweak feature
- Break feature ;)
- rewrite feature :p
We haven't broke it all that much, but when you start chucking so much of this together to make it gel. They tend to get temperamental little things.
In regards to the project as a whole, the only setbacks we have had have been finding new ways of doing something that makes it better.
Unfortunately that does push back our progress and slows us down, but I think it is worth while as the engine will benefit overall.

To pass the time a little, I can tell you that I am currently (this very hour) working on the terrain lookup map that we have.
This allows us to have multi-gradient textures and sub-textures splattered/painted across the terrain in a single shader pass.

What else can I tell you?
We have a basic mie scattered'esk atmosphere around the planet now - Yes this was a big task when we are dealing with a true world 1:1 scale. (IE Our planet has a radius of 6.3K KM, the actual size of Earth).
The standard atmosphere shaders out there that people are using, work ONLY with a scale of 1:10000(?) MINIMUM... And it wasn't just a simple matter of scaling up, it breaks and it breaks hard.
So we had to reinvent the wheel on that one... and we are still tweaking it.

Ok here is a big piece of news for you...
What Alex is currently working on is something that all big companies say can't be done, yet we are doing it.
They say that one of the big features of DX11 hardware is Tessellation... I say phewey! We have working tessellation that is running in DX9 people... That means people with older hardware will get the same terrain/model quality as those with DX11 hardware for a little extra cpu work.

Please be patient with us... we are new to this and we are literally learning something new everyday.

Alex will probably kill me for saying it... but we could use a hand from anyone who has excellent knowledge of shaders?
If you have some experience with shader code and would like to slowly help us out ;)
Please drop either of us a PM.

Cheers guys
0 x

Lord LoriK
Goblin
Posts: 254
Joined: Tue Feb 13, 2007 5:33 am

Re: ROAM Planet rendering

Post by Lord LoriK » Thu Sep 16, 2010 12:28 pm

This is great news, and it's just what I wanted: a "heartbeat", something to know the project is in good shape and making progress... Thanks a lot, Sovaka!
0 x

User avatar
Xypher
Gremlin
Posts: 180
Joined: Tue Jun 29, 2004 1:35 am
Location: Richmond, IN; USA
Contact:

Re: ROAM Planet rendering

Post by Xypher » Thu Sep 16, 2010 5:56 pm

Great to hear! Keep tweaking! lol
0 x
Ubuntu Studio 13.04 64-bit
GCC 4.8.1
Ogre3D 1.8.1
AMD Athlon FX 8120 @4Ghz
16Gb G.Skill Ripjaws (PC3-12800)
EVGA GeForce 560 Ti FTW

http://www.hellbatgames.com

systemparadox
Gnoblar
Posts: 7
Joined: Tue Feb 23, 2010 3:10 am

Re: ROAM Planet rendering

Post by systemparadox » Fri Sep 17, 2010 6:31 pm

I am totally looking forward to this, and whatever it is you're making it for. It looks awesome.
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Mon Sep 20, 2010 3:07 am

G'day guys,

Sovaka sort of let one of the cats out of the bag the other day ....
Ok here is a big piece of news for you...
What Alex is currently working on is something that all big companies say can't be done, yet we are doing it.
They say that one of the big features of DX11 hardware is Tessellation... I say phewey! We have working tessellation that is running in DX9 people... That means people with older hardware will get the same terrain/model quality as those with DX11 hardware for a little extra cpu work.
TA mate !!!

And yes it's true, we have a tessellation system functioning that runs under XP and DX9 as well as OpenGL, now I probably wouldn't say the the big companies couldn't do it, but probably didn't find an efficient way to do it maybe, or couldn't be bothered, knowing in advance that DX11 would have that functionality built in.
I on the other hand, thought it would be a good brain exercise to see if it could be done efficiently on such a grand scale. I keep finding myself having to re invent the wheel allot with this thing, because of the scale I'm running at, allot of these systems out there are all designed around 1:1000 scales (valid arguments by Sean O'Niel on that "Matter of Scale") but I Found that working at a resolution of say 1:1 or 1:10 my engine runs allot better, and I don't have the jitter problems when close to the surface of the terrain because I'm actually not getting to the limits of res where it counts, in the thick of the game play areas, the animation is smooth with reduced Gimbal locking in the animation rigs (especially when using physics and ragdoll stuff).

The only thing that is slowing me down a little now, is getting my hi res fractals working EXACTLY THE SAME on the GPU as well. I'm currently fixing my stuff so that I can implement a spacial displacement factor into the mix, so the res of the fractals (floats on GPUs) can deal with the accuracy of the numbers and get finer and finer the closer I get to the actual location on the surface. On the CPU I am currently using double precision numbers in the fractal calculations, to give me that subtle eroded look on the terrain, nice river banks and stuff like that, but what I'm doing now is reverting the CPU stuff to exactly the same as the GPU.
I've actually made a vector definition so that in the C++ code I can use float4,float3 and float2 assignments as well as swizzle operators (float3().xzy) so I can write the routines in one environment, and literally paste it into the other with a minimum of fuss, it's almost like writing in shader code for the CPU.

OH, and another thing, this tessellation system will handle any mesh you throw at it too, so standard entities can use it as well, I have to figure out a way to be able to allow the artist / coder to nominate an edge to be a sharp edge easily first though, as at the moment it doesn't allow that, so it will always have rounded corners, albeit relatively sharp, just needs good normal maps to keep the detail nice, but for sharp edges, well, I haven't figured that one out yet, but give me time.

Anyway, I've rabbled on enough about that, I'll try and keep you posted a little more often from now on.

Alex
0 x

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

Re: ROAM Planet rendering

Post by Sovaka » Wed Oct 13, 2010 3:58 am

Good afternoon all,

It has been a while since we have posted any progress information... As indicated by how many pages behind this thread is :)
Anyway, we have been hard at work on tweaking the terrain to point where I don't think there is much left to tweak.
Yes there is just a few minor adjustments that needs to be made, but as you will see from the following screenshots... We are almost done playing with the terrain :D

Click HERE for the screenshots.

And just to tease;
Image
Image

Alex will be posting a follow up momentarily so he can tell you in more detail what it is that we are doing.
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Wed Oct 13, 2010 8:22 am

G'day guys,
Just an update on the newest meshing algorithms I've got implemented now.
I've managed to get this Hybrid ROAM algorithm singing I think, I still have a few little things to go, namely the dynamic paging and proper batching, but for the moment I'm pretty happy with the efficiency of this algorithm, as I am running this thing on a 2.2GHz Core2 Duo with 4gb ram ( actually 3 gb ) XP doesn't see past that) and an Nvidia 9800 GT 512 video card, so it's pretty mediocre in stats.
Heres a picture from outer space on this machine .....
outer_space.jpg
Outer space shot
As you can see in this shot the batch count is pretty high, but that will be sorted out very soon, hence the frame rate.

This next shot is from lower in orbit, and you can see already, the vast speed up because of the batch counts dropping even though the triangle count has nearly tripled ( crazy hay !!! Goes to show you, that batching really matters )....
lower_orbit.jpg
lower in orbit on approach to the planet
Now this next shot is from exactly the same point in space above the planet, but I've turned off the shader, so as to show the detail that this algorithm can pull off now ( only Ogre's default no material texture here ) .......
LO_no_texture.jpg
No texuring on this shot, just shows static pipeline lighting
As you can see here, there is a ton of detail in this mesh and it is updated on the fly, with morphing but still manages to reach around 250 - 350 fps on approach. The thing with this is that it was quite an effort to get it to keep the normals nice and morph them with the mesh vertices as well.

more to come .... Gotta go make tea for the family.
0 x

User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK
Contact:

Re: ROAM Planet rendering

Post by SpannerMan » Wed Oct 13, 2010 8:53 am

Let them starve, there are worlds to be made!!!

Awesome stuff guys :shock:
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Wed Oct 13, 2010 10:36 am

OK, I'm back.

I can't take all the credit for this stuff, Sovaka has this uncanny ability to ask little questions, and throw in "what ifs", and with these little tidbits, gets me thinking in different lines of thought when tackling a problem I or he may have when working with this thing. "THANKS MATE! couldn't do it without you".

Anyway, back to the topic at hand.
As you could see from the previous post, that the mesh seems to have quite a bit of detail in it even at that altitude, and no, there is no hardware tessellation going on here ( YET !!! ), I wanted to see how far I could push this thing without that, and keep up a reasonable frame rate.
Well now I'm going to show you the actual structure of the underlying mesh ....
LO_meshview.jpg
Mesh structure generated by this Hybrid ROAM algorithm.
As you can see in this little picture, that the mesh is denser where the detail is needed, to the point that some places it looks almost solid, and if you look really close, you can see the partitions between pages, those skirts are purely dynamic in nature, when the mesh res changes, so does the skirt resolution, and there is no perceivable seams when running around on the ground ( unless the textures are crappy and aren't seamless of course ). I went to great pains earlier on to get these dynamic skirts working, and the earlier algorithm worked, but I found that I was doubling up on allot of vertices I didn't need to, so I went to work on the re indexing algorithm, to reduce the vertex count to its bare minimum, and doubling up on nothing ( per Page ). The other hard part was getting the mesh into some nice order for sending to the GPU, without having the mesh indexing jump all over the place, makes for a very inefficient render path for the GPU to work with, so I managed to sort of order things on the fly, due to the nature of the updating of this algorithm, it can put a new polygon anywhere in the map, at any time, and that was an interesting solve, but I did manage it to the point that this thing gives really nice interactive frame rates, even on medium grade hardware.
Here's another interesting picture too ....
LO_Oceans_clipping.jpg
The mesh showing the ocean mesh clipping against the terrain.
This picture shows the ocean mesh interacting with the terrain mesh, and clipping itself to the terrain where needed. I included that shot because I thought it looked nice, and shows that the ROAM actually reduces priority of the mesh while under the water. But, when you get close to going under the water, the mesh regains the priority a little, and still gives very nice terrain while under the ocean surface.

more to come ....
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Wed Oct 13, 2010 11:07 am

OK, g'day again,
Here are a couple of shots at a closer orbit, I'm putting these in to emphasize the importance of batching, well, with these it's actually not batching, but it's culling off pages that are no longer of importance to the viewer, but still, when removing the outer pages from the scene, the batch count is reduced enough to show you the incredible difference it makes in efficiency to the rendering algorithm, even though the vertex / triangle count remains pretty steady.....
C_Orbit_coloured.jpg
The same mountain in full colour
I removed the clouds from this shot to give a clearer view of the terrain, but ! notice the frame rate with regards to the batch count, while it's still relatively high in detail (for this machine).
C_Orbit_default.jpg
The same shot with just static pipeline lighting, no normal maps or anything fancy
In this shot, it really shows the cost of the shader I have written for this thing, if you look at the previous shot, and look at the frame rate compared to this one, you will see there is quite a heavy price to make it look pretty.
C_Orbit_mesh.jpg
The same shot again, showing the mesh at this altitude
This shot shows the underlying mesh structure at this height, quite a complex mesh and all of this fits inside 30mb of CPU ram only, doesn't sound right does it ? but it's true !!! all of this is completely dynamic in nature, fare enough It uses around 70mb of GPU ram to show this scene including water and clouds etc, but still, for what it is doing, I think that it's OK.

more to come ....
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Wed Oct 13, 2010 11:53 am

G'day again,
This next shot sort of shows allot of what I've been talking about, in the past few posts ....
Dynamic_Skirts.jpg
Close up od the skirts and water mesh clipping
If you look at the mesh structure ( I froze the update at ground level so that you could see this ) you will notice how the skirts match the resolution of the mesh precisely, and if you look really close, you can see that the water mesh is only rendering itself, where it can be seen plus a small bit.
GL_MtnTops.jpg
Standing on the tops of the mountains in the previous shots
This shot shows the mountain tops from ground level, and shows the shader doing its thing too, normal mapping and stuff like that.
GL_Scenery.jpg
Nice scenery shot with mountains in the distance
This shot was taken not far from the first in this post, just shows off the scattering a little ( well, I think it is nice anyway ).
As you can see, even at ground level this engine is still maintaining quite interactive frame rates considering you can see nearly 50-70 km away (distant mountain) and still maintaining quite a high degree of detail.
I and Sovaka hope you like our progress with the mesh generation, and look forward to showing you some really nice stuff shortly.

Alex
0 x

User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK
Contact:

Re: ROAM Planet rendering

Post by SpannerMan » Wed Oct 13, 2010 12:30 pm

Wow man, really fantastic.
DavlexDesign wrote:...shows that the ROAM actually reduces priority of the mesh while under the water.
Hehe that is awesome attention to detail!
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Thu Oct 14, 2010 7:43 am

Thanks SpannerMan,
Here's a video to see it working live ... http://www.youtube.com/user/davlexdesign

Recording this thing really hit the machine hard, but it still gives you a good idea of what it looks like now.

Hope you guys like it

Alex
0 x

Lord LoriK
Goblin
Posts: 254
Joined: Tue Feb 13, 2007 5:33 am

Re: ROAM Planet rendering

Post by Lord LoriK » Thu Oct 14, 2010 12:57 pm

The video is great! The whole thing looks very polished and is worth all the time we've been waiting so far! Congratulations for putting so much awesomeness together.

Now, my curiosity sprang with some stuff I saw, so I got some questions:

1) You mentioned that the batch count was very high for orbital views, and indeed, at 500+ batches it seems a bit too much. How are you planning to bring that number down, and what kind of improvement can be expected from that approach?

2) Are all the subsystems (terrain generation per-se, tesselation, atmosphere, rendering, etc.) strongly tied one another? What subsystems can be replaced, and which ones cannot? Are you planning any further subdivision?

3) Are you working on a physics plugin? If you are, which library are you working with? (assuming you're not using something homegrown, of course)

4) What's that "update mode"? It seems to change automatically at 1:39 and 3:06, and then again at 5:00. I suppose it's related to the tesselation, and the changes appear to be triggered when the distance to the surface crosses a threshold. Why is it important enough to be displayed in the debug overlay?

That's all I've got so far. I'm sure more questions will come up, so I'll give others a chance, too. :D

Thanks a lot for all your amazing work!
0 x

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

Re: ROAM Planet rendering

Post by Sovaka » Thu Oct 14, 2010 1:49 pm

Lord LoriK wrote:The video is great! The whole thing looks very polished and is worth all the time we've been waiting so far! Congratulations for putting so much awesomeness together.

Now, my curiosity sprang with some stuff I saw, so I got some questions:

1) You mentioned that the batch count was very high for orbital views, and indeed, at 500+ batches it seems a bit too much. How are you planning to bring that number down, and what kind of improvement can be expected from that approach?

2) Are all the subsystems (terrain generation per-se, tesselation, atmosphere, rendering, etc.) strongly tied one another? What subsystems can be replaced, and which ones cannot? Are you planning any further subdivision?

3) Are you working on a physics plugin? If you are, which library are you working with? (assuming you're not using something homegrown, of course)

4) What's that "update mode"? It seems to change automatically at 1:39 and 3:06, and then again at 5:00. I suppose it's related to the tesselation, and the changes appear to be triggered when the distance to the surface crosses a threshold. Why is it important enough to be displayed in the debug overlay?

That's all I've got so far. I'm sure more questions will come up, so I'll give others a chance, too. :D

Thanks a lot for all your amazing work!
1) I'll let Alex get technical on that one :)
2) We are trying to keep everything as modular as possible. So that those who want to use their own terrain system, they can. However, heavy optimization has gone into this and those optimizations won't be carried across. So you will be dealing with a potential FPS hit that may be unbearable if you change to a different terrain system that isn't made by you.
Our atmosphere will be separate, however once we are done with it, there is no other Atmo shader/code out there that will be pluggable into our engine. Just for the basic fact that all those other shaders are based on a much SMALLER scale and will NOT scale to our engine. We've tried with the Sean ONeil one... it didn't like being scaled at all.
And Tessellation, won't be tied down at all... Our tessellation will not only work with the terrain, but models that are in the scene as well.
With all these, we are making the parameters as tweakable as possible, so that you get the most out of it without changing it out for a different program.
3) At the moment we are going with Bullet. However we have also been looking at Havok and PhysX.
4) That is a mode Alex developed that allows us to tell the engine how often it sends the terrain calculations to the CPU and GPU to get more detail. During Flight, we will set it to Full to prevent as much morphing as possible (reduced FPS), and while on ground (walking) it will revert to Partial. At the slower speeds, Full does not offer any quality increase for the performance hit.

I will also be putting up a 720p video soon so that you can see the detail a little better.

Hope this has answered your questions and piqued your interests as well :)

.: EDIT :.

Oh by the way... Tessellation hasn't been turned on yet ;)
0 x

User avatar
DavlexDesign
Gnome
Posts: 397
Joined: Thu Apr 23, 2009 7:23 am
Location: Australia
Contact:

Re: ROAM Planet rendering

Post by DavlexDesign » Thu Oct 14, 2010 11:45 pm

G'day Lord Lorik,

Sovaka has pretty much explained some of those questions, but with regards to the first one ...
1) You mentioned that the batch count was very high for orbital views, and indeed, at 500+ batches it seems a bit too much. How are you planning to bring that number down, and what kind of improvement can be expected from that approach?
Don't quote me on this, but I think with the batching side of things, I noticed that the less the number of Batches the faster the system runs, I say it has to do with the state changes in the GPU, Reloading materials and things like that, that really seems to hit the cards hard. I had a look in the Performance HUD to see how the rendering worked on a Batch by Batch basis, and it seemed to need to reload and setup for each page of the terrain separately, so if I can get it to not need to do that setup repeatedly for one type of material in one frame, the better I think. It seems to be more of a problem on older generation cards more than the newer generation ones, as you will see when Sovaka puts up his video, he is getting incredible fps on his machine, 400 - 600 fps, but, out in space he gets high 100s to low 200s, allot better than mine, but still, quite a performance hit.

I hope that sort of answers that question for you, I'm no engineer as such, I'm just going on what I can see and deduce from the Performance Hud thingy.

As for the improvement, well I would imagine that the improvement will be immense, If I run my planet engine with only one page per Unit cube face, it runs like the original video, 300 - 500 fps, big improvement, but not friendly to shadows and the like, or culling and memory efficiency.

To fix it, I will be working on my re indexing thingy a little more, and get it to pool the pages into one batch per grouping, so I should see at least a 1/3rd increase in efficiency.

As for Question 4 .....
4) What's that "update mode"? It seems to change automatically at 1:39 and 3:06, and then again at 5:00. I suppose it's related to the tesselation, and the changes appear to be triggered when the distance to the surface crosses a threshold. Why is it important enough to be displayed in the debug overlay?
That is there so I can see if I'm doing it right and it is kicking in at the right time, at the moment I'm operating it manually in the video so you actually see some points where I forgot to switch, and then you will see the morphing quite pronounced relatively close to the viewer, the reason I'm doing it manually, is so I can get a better idea of what I need to do to implement an automatic switching system.

OK Why do I need it ?
Well, the ROAM Algorithm in its very recursive nature tends to spend allot of time in spots you don't want it to, so I found that when only partially updating the map to a time slice, I found the map tends to lag behind the camera a little, concentrating its efforts in non important parts of the map ( just outside of view and stuff like that ), So when it switches to FULL Update, it actually does a complete traversal of the pages that are active, and re prioritizes the mesh update to the camera a little better.

Actually creating that video taught me quite a bit about that Update Mode, because of the frame hit that the recorder inflicted on my machine, I could see the morphs allot more, and it tended to emphasize the update problems when dealing with such a high res mesh, so I think I may have the algorithm worked out in my head already.

Hope that helped a little.

Alex
0 x

User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK
Contact:

Re: ROAM Planet rendering

Post by SpannerMan » Fri Oct 15, 2010 12:08 am

Just watched the video - amazing stuff!

So do you guys have a game idea lined up ready to use this tech yet?
0 x

Post Reply