Map Tessellation Testing

[Argh]

Well, my whole feeling on this is that:

1. The implementation of the nVidia stuff from GPU Gems should be finished.

The problem here is just that it was never really finished, not that it's Mission Impossible. This stuff is years old, there's a fairly large amount of sourcecode available for this. Spring's not doing anything really new or radical- the closest we got to new or radical was SM3, which is totally not working atm.

2. If we simply got SMF working the way that it's supposed to work, we'd be happily surprised by the speed boost and beauty improvement that would result. Just slaving the error-correction to the POV should cure one of the biggies, which is that the default camera's not straight up and down, but the current code assumes that it is, and is thus building and shading many thousands of triangles it doesn't even need to- off-screen. Let alone the vast improvement in apparent detail that would result. And that's without improving the error-correction algorithm one bit!

3. If the GLSL-driven stuff that's in GPU Gems is implemented, then we're looking at rendering our terrains at an incredible FPS on all newer GPUs. This builds directly on the first and second parts, and doesn't require a brand-new map format, etc.

IOW... we need to concentrate on making what we have work like it should have in the first place. I'm not at all opposed to some new rocket-science approach, and if somebody shows up with source from another engine and wants to stick it into Spring (there are several engines with much better-looking terrain that we could borrow from legally) that's great, but I have this feeling, backed up by observation, that SMF will run at least 50-100% faster for the same apparent detail, if it's merely fixed for POV... and probably many times that if it's GPU accelerated.

At any rate, if you guys want I'll go look for source from engines we can use. There's a fair amount out there, and I doubt if most of it's terribly hard to port, since most engines are still using heightmaps... just like we are.

[Argh]

1. Blender Game engine is GPL-compatible, fast, and works.

BTW, found this water shader source from a guy working with that, he's giving it away:

http://pin.ic.cz/Water.lua

2. Check this out:

http://demeter.sourceforge.net/

Yes, it's ancient. But it's basically SM3, sans GLSL.

Probably very slow on today's hardware, and it would probably be a real pain getting the shadows to work with it. But shadows are currently screwed up anyhow.

[Argh]

http://apps.sourceforge.net/mediawiki/m ... =Main_Page

Fairly new, uses GPU acceleration, documented (and tutorialized!) here:

http://iqdev.blogspot.com/2008/11/gpu-t ... art-1.html

[AF]

I wonder what would happen then if we point the camera at the sky?

[IllvilJa]

I wonder what would happen then if we point the camera at the sky?

Skip tesselating at all? We don't render the map onscreen anyway at that point so...

[BaNa]

Its strange, when we tested this it showed that you get a performance hit for changing viewdistance, even if you are zoomed all the way in on a small piece of dirt. Shouldnt the things offscreen not get rendered?

[Kloot]

Its strange, when we tested this it showed that you get a performance hit for changing viewdistance, even if you are zoomed all the way in on a small piece of dirt. Shouldnt the things offscreen not get rendered?

That hit has nothing to do with a lack of visibility testing (which does in fact take place, although it could stand to be optimized); it's because Spring creates a reflection cubemap texture every frame which requires drawing the map from six different viewpoints regardless of how far you are zoomed in.

Uh, I gave you the entire presentation about this very topic from nVidia... which included examples and the relevant math, IIRC.

We're all more than capable of looking up links and tutorials ourselves, writing a new renderer doesn't somehow become less work when you post them. You also seem to assume that nobody has considered it before or that everyone was unaware of the SMF drawer's "faults" before you started essaying about them, which you really should drop.

[jK]

Its strange, when we tested this it showed that you get a performance hit for changing viewdistance, even if you are zoomed all the way in on a small piece of dirt. Shouldnt the things offscreen not get rendered?

That hit has nothing to do with a lack of visibility testing (which does in fact take place, although it could stand to be optimized); it's because Spring creates a reflection cubemap texture every frame which requires drawing the map from six different viewpoints regardless of how far you are zoomed in.

reducing map terrain detail for those passes increase the performance a lot:
GroundLODScaleReflection
GroundLODScaleReflraction
GroundLODScaleUnitReflection

PS: there is a bug if you set it too low. (My settings are grounddetail 50, all scales 0.5)

PPS: Yeah kloot is right. Don't think such essays will speed up the development on a new map renderer system ... (and yeah, we have a lot ideas already ourself and read such papers to breakfast ...)

[AF]

What's stopping us halving the detail of the map in the cubemap then running a blur over the edges so it isnt that obvious then doing the other render passes?

And it is possible to point the camera upwards and still see terrain, e.g. cliffs. If your in a valley when you do this or a deep crater....

[Tobi]

What's stopping us halving the detail of the map in the cubemap then running a blur over the edges so it isnt that obvious then doing the other render passes?

Uhm that's exactly what jK is suggesting?

Apart from the blur but I don't think the difference would be visible anyway.

[AF]

Because Im expecting someone to now make a giant uber reflective mirror unit

[Beherith]

In Lurch voice:

You rang?



Behold the world destroyer!

[Argh]

I don't write "these essays" with any purpose but to keep annoying you guys. You know that as well as I do- if nothing else, it's a reminder that stuff's not right yet. And I damn well know that it's not as easy as handing you some papers, etc. It's just... dammit, there are a lot of engines which have gotten these things solved. I know it's possible. It's very frustrating to me, that we're not there yet.

Secondly... why are we updating the cubemap every frame? Surely once every SlowUpdate is more than sufficient, the camera's rarely moving fast enough to create really visible problems, except when you minimap-move. An exception for that case would probably be a good idea.

And +1000 to reducing that level of detail by at least half, if not more. If it's really drawing 6 views, then I'd say quarter it, and then everybody except on the most crappy hardware can run the game with viewdistances of 100+, which would look fabulous!

Thirdly... now that I've seen the difference between cubemap skies and Spring's current sky system, I'd like to propose that the default is to render the skies to 1024 cubemaps during gamestart, instead of doing a lot math per frame. Almost as pretty, and you don't need anything else unless you've turned dynamic clouds on. Which practically nobody does.

And can:

GroundLODScaleReflection
GroundLODScaleReflraction
GroundLODScaleUnitReflection

Be set by Lua? I'd like to see this for myself.

<answer is yes. And quartering it is definitely the right way to go>

[Beherith]

reducing map terrain detail for those passes increase the performance a lot:
GroundLODScaleReflection
GroundLODScaleReflraction
GroundLODScaleUnitReflection

PS: there is a bug if you set it too low. (My settings are grounddetail 50, all scales 0.5)

PPS: Yeah kloot is right. Don't think such essays will speed up the development on a new map renderer system ... (and yeah, we have a lot ideas already ourself and read such papers to breakfast ...)

ALERT!
Normally I get 50 fps on Mearth V4 with a viewradius of 120.

With these three settings i get the following:
1 1 1: 50
0.5 0.5 0.5: 33
0.25 0.25 0.25: 26
4 4 4: 20
8800GT C2D@3.5ghz

[Argh]

I have a stupid but pretty fundamental question to ask. If nomapdamage = true, is the heightmap being stored in a way that allows for faster access to it, or is every pixel getting looked up constantly like in the regular map system? I'm aware I probably got various things mangled in that sentence, but you hopefully know what I mean here. If it's not, changing that could have a fairly large performance benefit, because it could be stored on the GPU.