ROAM terrain rendering, help us make spring much faster!

[Beherith]

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!

[imbaczek]

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.

[Argh]

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.

[Beherith]

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.

[Argh]

Yes, I could add a hook to not rebuild when its non deformable.

Please! That would be extra-fricking-awesome!

[FLOZi]

I think I'm falling for you, Behe.

[imbaczek]

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.

[Beherith]

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.

[imbaczek]

just throwing ideas around, good job so far anyway

[Argh]

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.

[Beherith]

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 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.

[Beherith]

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.

[BaNa]

fucking A man.

[smoth]

I think I'm falling for you, Behe.

where did you get a picture of peet's dinner table?

[Beherith]

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...

[eyu100]

What does ROAM stand for (if it stands for anything)?

[Kloot]

real-time optimally adaptive mesh(es)

Beherith: anything in particular you'd like help with?

[Beherith]

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?

[jK]

And why is inView so much slower when its a bounding box and not a bounding sphere?

bounding sphere needs just to compute the square radius/distance, while box needs to check each edge if it is visible.