ROAM terrain rendering, help us make spring much faster!

ROAM terrain rendering, help us make spring much faster!

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

ROAM terrain rendering, help us make spring much faster!

Post by 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:
Image

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.
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: ROAM terrain algorithm implemented!

Post by 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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ROAM terrain algorithm implemented!

Post by 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.
Last edited by Argh on 28 Jul 2009, 20:32, edited 1 time in total.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ROAM terrain algorithm implemented!

Post by Argh »

Yes, I could add a hook to not rebuild when its non deformable.
Please! That would be extra-fricking-awesome!
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: ROAM terrain algorithm implemented!

Post by FLOZi »

I think I'm falling for you, Behe.

Image
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: ROAM terrain algorithm implemented!

Post by 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.
Last edited by imbaczek on 28 Jul 2009, 20:40, edited 1 time in total.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: ROAM terrain algorithm implemented!

Post by imbaczek »

just throwing ideas around, good job so far anyway 8)
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ROAM terrain algorithm implemented!

Post by 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.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: ROAM terrain algorithm implemented!

Post by 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.
Last edited by Argh on 28 Jul 2009, 21:03, edited 1 time in total.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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
Posts: 1562
Joined: 09 Sep 2007, 21:05

Re: ROAM terrain algorithm implemented!

Post by BaNa »

fucking A man.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: ROAM terrain algorithm implemented!

Post by smoth »

FLOZi wrote:I think I'm falling for you, Behe.

Image
where did you get a picture of peet's dinner table?
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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
Posts: 182
Joined: 05 Jul 2008, 04:10

Re: ROAM terrain algorithm implemented!

Post by eyu100 »

What does ROAM stand for (if it stands for anything)?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: ROAM terrain algorithm implemented!

Post by Kloot »

real-time optimally adaptive mesh(es)

Beherith: anything in particular you'd like help with?
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: ROAM terrain algorithm implemented!

Post by 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?
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: ROAM terrain algorithm implemented!

Post by jK »

Beherith wrote: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.
Post Reply

Return to “Engine”