Make OpenGL terrain rendering less demanding on hardware

Bug #939709 reported by Tino on 2012-02-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Nicolai Hähnle

Bug Description

Currently the OpenGL rendering of the terrain in Widelands works with 6 Multitextures via OpenGL 1.3 standard.
Only very potent 1.3 chipsets are able to do more than 4 textures with multitextures.
Many currect graphic chipsets have no higher limit, because they support GLSL and multitexturing is done via shaders. Using the old fixed pipeline is obsolete since OpenGL 2.0.

Desirable would be the following:
- software rendering for hardware without OpenGL support (already implemented)
- OpenGL fixed pipeline rendering for 1.3 supporting chipsets with GL_MAX_TEXTURE_UNITS >=6 (already implemented)
- only fog of war for chipsets with GL_MAX_TEXTURE_UNITS <6 (no edge dithering)
- Dithering edges and fog of ware via GLSL/shaders for chipsets which support OpenGL >= 2.0 to make use of modern hardware

Related branches

tags: added: opengl
Nasenbaer (nasenbaer) on 2012-05-02
Changed in widelands:
status: New → Confirmed
Tino (tino79) wrote :

I've linked nhas current opengl branch. I am not sure if he does use GLSL, but i can confirm that the terrain multitexturing is working with his code on win32.
It looks very good and promising...

SirVer (sirver) wrote :

awesome that you are back at work nicolai!

SirVer (sirver) wrote :

Note that I am currently doing big refactorings which will land soon - if you can avoid it, please do not move too many functions/files around :-)

Nicolai Hähnle (nha) wrote :

re #1: Thanks :-)

I am not using GLSL. Actually, the code in the branch right now uses at most two texture units at a time, and it does the "edge fuzzing" (which I will rename to "edge dithering", I prefer that term now that I've read it) using multiple passes. My rationale for this was that it allows minimizing the number of state changes. All triangles are sorted by terrain type, and then all triangles involving a fixed terrain type are drawn at once using a vertex array.

The downside is that in the worst case, where every pair of adjacent triangles is of a different terrain type, every triangle will be drawn 2.5 times on average.

So using multiple passes can cause more overdraw. However, the GPUs that are limited in terms of framebuffer fill rate are probably the same GPUs that run into limitations doing the 6-stage multi-texturing of the old renderer. I don't think it makes sense to try to reduce the number of passes unless there is really concrete timing evidence in its favour.

As far as this bug is concerned, I believe that my branch will essentially fix the issue once it is done. However, I don't plan to introduce GLSL. I don't think that this is the right time to start using GLSL anyway. It is true that modern OpenGL is GLSL+VBO+etc., but for Widelands I would prefer to just be pragmatic and support the widest possible range of systems while keeping the number of different code paths small. We can talk about it again once we hit a system that supports GLSL without also supporting fixed function (GLES on some mobile device, perhaps?), or consider some feature that really depends on it.

re #3: So far, I haven't actually touched a lot of code. I believe it is mostly limited to this:
1. I split GameView into two different classes, one for minimap rendering and one for the actual view rendering.
2. I added an option to the picture loading code that allows loading GL_INTENSITY textures. I use this for the "edge fuzzing" mask texture (Technically, one could also change the "pics/edge.png" to use an alpha channel; the choice is largely arbitrary - mostly, I didn't feel like opening GIMP - but the texture does require slightly less memory using the approach I have now chosen).
3. I added an "edge_fuzz_layer" option to the Terrain_Descr. This option allows some control over how edges between different terrains are handled. The old renderer had an approach that resulted in some IMO strange and noticeable asymmetries. In the new code, this old approach is only used for different terrains that are on the same layer.

SirVer (sirver) wrote :

I agree with nicolai, it is not the time to switch to cutting edge opengl for widelands.

It is kinda hard to say what to do with this bug. For now it is won't fix, but in the future, we might want to take it on again.

Changed in widelands:
status: Confirmed → In Progress
status: In Progress → Won't Fix
Tino (tino79) wrote :

I totally agree with you. The intent of this bug report was to achieve the same visual style with OpenGL as with SDL on as many hardware configurations as possible. My rather (very limited) research on the issue pointed to GLSL...

But the current solution seems much nicer, because it just don't use multitexturing any longer (or in another way) and is therefore not dependant on the very differtent support for this on older and newer hardware.

So my vote would even go to "Fixed" as long we do not find hardware which does not deliver the same OpenGL style as the SDL Renderer does.

SirVer (sirver) wrote :

I quickly refurbished this bug to match the ongoing work :)

summary: - OpenGL Terrain Rendering with GLSL
+ Make OpenGL terrain rendering less demanding on hardware
Changed in widelands:
status: Won't Fix → In Progress
assignee: nobody → Nicolai Hähnle (nha)
SirVer (sirver) wrote :

Should be fixed in trunk in r6501.

Changed in widelands:
status: In Progress → Fix Committed
SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers