ROAM terrain rendering, help us make spring much faster!
Moderator: Moderators
ROAM terrain rendering, help us make spring much faster!
Hi guys!
In the past few weeks ive been working on turning the current horrible terrain LOD system into something nicer, after failing on a quadtree based attempt (couldnt resolve tearing and couldnt restrict quadtree), I chose a different approach, ROAM.
Here are the current results:
Currently i divide the terrain into bigtexsquare size patches, and ROAM those.
LOD is dynamic and cam distance based.
Tons of stuff is still not done, but if you want you can check it out on:
http://github.com/Beherith/spring/tree/roam
For some reason, CCamera::inView(<box>) is tons slower than CCamera::inView(<sphere>)
Performance:
DSD whole map is rendered at 150-200 fps, with no loss of terrain fidelity.
DSD front is rendered at 500 fps.
Of course this is far from finished, stuff like shadows, reflections and map damage are not done yet. (btw mapdamage is supported, since it rebuilds triangle trees each frame)
So any help is greatly appreciated!
Thanks!
In the past few weeks ive been working on turning the current horrible terrain LOD system into something nicer, after failing on a quadtree based attempt (couldnt resolve tearing and couldnt restrict quadtree), I chose a different approach, ROAM.
Here are the current results:
Currently i divide the terrain into bigtexsquare size patches, and ROAM those.
LOD is dynamic and cam distance based.
Tons of stuff is still not done, but if you want you can check it out on:
http://github.com/Beherith/spring/tree/roam
For some reason, CCamera::inView(<box>) is tons slower than CCamera::inView(<sphere>)
Performance:
DSD whole map is rendered at 150-200 fps, with no loss of terrain fidelity.
DSD front is rendered at 500 fps.
Of course this is far from finished, stuff like shadows, reflections and map damage are not done yet. (btw mapdamage is supported, since it rebuilds triangle trees each frame)
So any help is greatly appreciated!
Thanks!
Last edited by Beherith on 29 Jul 2009, 14:46, edited 2 times in total.
Re: ROAM terrain algorithm implemented!
ok this is awesome. easy suggestion: rebuild tris only when map was actually changed (damaged/terraformed), some maps can't be damaged and some mods don't support terraforming, why punish them? shouldn't be too hard.
Re: ROAM terrain algorithm implemented!
Yay!!!
Now all we need is <cough> normalmap textures in SM2 <cough> and we can do some really breathtaking stuff... without it eating Spring whole.
Now all we need is <cough> normalmap textures in SM2 <cough> and we can do some really breathtaking stuff... without it eating Spring whole.
Last edited by Argh on 28 Jul 2009, 20:32, edited 1 time in total.
Re: ROAM terrain algorithm implemented!
Yes, I could add a hook to not rebuild when its non deformable.
Also, Mearth_v4 runs a constant 200+ fps when looking anywhere, and drops to about 170 when whole map is viewed.
Also, Mearth_v4 runs a constant 200+ fps when looking anywhere, and drops to about 170 when whole map is viewed.
Re: ROAM terrain algorithm implemented!
Please! That would be extra-fricking-awesome!Yes, I could add a hook to not rebuild when its non deformable.
Re: ROAM terrain algorithm implemented!
I think I'm falling for you, Behe.
Re: ROAM terrain algorithm implemented!
while we're at the terrain stuff - next step: do what the essence engine does, ie. make a new map format which stores a different texture map for cliffs so they don't get stretched. how it should work:
- the mapper paints the normal (as in usual) map as usual
- then he goes through steep areas and paints a vertical texture type (not a proper texture, but like in typemaps, a texture id)
- if the steep texture is defined for a given quad and the terrain is in fact steep, don't draw the normal terrain texture, but instead draw the marked one, which won't be stretched. blend at edges of steepness.
a mockup screenshot should be here but i'm a little bit lazy today.
- the mapper paints the normal (as in usual) map as usual
- then he goes through steep areas and paints a vertical texture type (not a proper texture, but like in typemaps, a texture id)
- if the steep texture is defined for a given quad and the terrain is in fact steep, don't draw the normal terrain texture, but instead draw the marked one, which won't be stretched. blend at edges of steepness.
a mockup screenshot should be here but i'm a little bit lazy today.
Last edited by imbaczek on 28 Jul 2009, 20:40, edited 1 time in total.
Re: ROAM terrain algorithm implemented!
Further issues needing optimization:
Currently, each triangle is its own tri strip: bad, we could save alot of GPU on this one.
I cant figure out the inView issue, but it might be needed for total accuracy
Need to add viewradius hook, so ppl can adjust for their own liking.
Baczek:
Im tired of smf mapping, the texture is stupidly limiting. Im planning on sticking this into SM3 as well, in hope that it might spur progress there, as my opengl skills are horribly lacking.
Currently, each triangle is its own tri strip: bad, we could save alot of GPU on this one.
I cant figure out the inView issue, but it might be needed for total accuracy
Need to add viewradius hook, so ppl can adjust for their own liking.
Baczek:
Im tired of smf mapping, the texture is stupidly limiting. Im planning on sticking this into SM3 as well, in hope that it might spur progress there, as my opengl skills are horribly lacking.
Re: ROAM terrain algorithm implemented!
just throwing ideas around, good job so far anyway
Re: ROAM terrain algorithm implemented!
If we have parallax mapping at current texture resolution, which we can afford especially after further optimization... SM2 will look almost real, Behirith. And full-scale normalmaps aren't that big of a deal to make.
But yeah, by all means do this for SM3, too, and we can maybe see what it performs like vs. SM2 with the major suck removed.
Heck, if Tobi gets that crazy LOS thing done... between that and this, I could probably triple the detail of current scenes and still be performing better... thanks much for tackling this issue, it's one of the biggies.
But yeah, by all means do this for SM3, too, and we can maybe see what it performs like vs. SM2 with the major suck removed.
Heck, if Tobi gets that crazy LOS thing done... between that and this, I could probably triple the detail of current scenes and still be performing better... thanks much for tackling this issue, it's one of the biggies.
Re: ROAM terrain algorithm implemented!
Added viewradius support.
Argh: i alread add normal maps to my maps, but I bake them right on with WICed; check Nuclear Winter to see what i mean.
What are the hooks for mapdamaged?
Argh: i alread add normal maps to my maps, but I bake them right on with WICed; check Nuclear Winter to see what i mean.
What are the hooks for mapdamaged?
Re: ROAM terrain algorithm implemented!
I bake lightmaps with L3DT- same process, create normals from high-resolution heightmap light it and bake it.
It's not the same, man. The surface lighting doesn't alter with POV. It's why SM3 looks and feels a lot different than SM2. And SM3, IIRC, is just using normalmapping, not full parallax (though that would be trivial to add, if that's the case- I'll go look at the shader later).
Anyhow... that's another (fairly hefty) step, to make a SM2+, so I'll shut up and enjoy that you've massively improved performance for now. If you're dubious about the benefits, let me know, and I'll make a demo though.
It's not the same, man. The surface lighting doesn't alter with POV. It's why SM3 looks and feels a lot different than SM2. And SM3, IIRC, is just using normalmapping, not full parallax (though that would be trivial to add, if that's the case- I'll go look at the shader later).
Anyhow... that's another (fairly hefty) step, to make a SM2+, so I'll shut up and enjoy that you've massively improved performance for now. If you're dubious about the benefits, let me know, and I'll make a demo though.
Last edited by Argh on 28 Jul 2009, 21:03, edited 1 time in total.
Re: ROAM terrain algorithm implemented!
Current hardcoded limit is 100k tris for map rendering, thats still done at 40fps.
With previous renderer, you could easily hit that 100k tris, and still not look perfect. With 100k tris here, the map looks exactly like it should on a full render.
With previous renderer, you could easily hit that 100k tris, and still not look perfect. With 100k tris here, the map looks exactly like it should on a full render.
Re: ROAM terrain algorithm implemented!
fucking A man.
Re: ROAM terrain algorithm implemented!
where did you get a picture of peet's dinner table?FLOZi wrote:I think I'm falling for you, Behe.
Re: ROAM terrain algorithm implemented!
nah thats some nice Zubrowka and cider.
Btw, it seems that shadowmap and reflection map are rendered just the same as the old terrain is rendered. Maybe these would benefit even more from ROAM, as even less tris are required to get good approximation of terrain...
Btw, it seems that shadowmap and reflection map are rendered just the same as the old terrain is rendered. Maybe these would benefit even more from ROAM, as even less tris are required to get good approximation of terrain...
Re: ROAM terrain algorithm implemented!
What does ROAM stand for (if it stands for anything)?
Re: ROAM terrain algorithm implemented!
real-time optimally adaptive mesh(es)
Beherith: anything in particular you'd like help with?
Beherith: anything in particular you'd like help with?
Re: ROAM terrain algorithm implemented!
Yes, thank you; for starters, what are the fuctions called when heighmap is changed?
And why is inView so much slower when its a bounding box and not a bounding sphere?
And why is inView so much slower when its a bounding box and not a bounding sphere?
Re: ROAM terrain algorithm implemented!
bounding sphere needs just to compute the square radius/distance, while box needs to check each edge if it is visible.Beherith wrote:And why is inView so much slower when its a bounding box and not a bounding sphere?