[PATCH] Water reflections bug on Mac w/ Intel HD 3000 graphics

[vls]

Black border of rect move with camera. Disappear after off water reflection.

HW: Macbook pro 13" 2011 year. Latest Mac OS

[Kieran P]

Hey vladislav. I had the exact same thing and let Philip know. I didn't bother making a ticket for it at the time because I thought it might have just been my computer. Sad to hear it isn't just me :-(

I'll update this to a release blocker in Alpha 10, but no guarantees it'll actually be fixed before release.

[historic_bruno]

Hi, I'd like to request your system_info.txt from the Mac :) You can find it in ~/Library/Application\ Support/0ad/logs/system_info.txt. Unfortunately it's hard to troubleshoot this without more information and most of our devs don't have access to a Mac.

Are you using one of our app bundles, which one?

[wraitii]

I get this one too, on a MacBook Air 13" (last generation iirc)... But not permanently, it appears/disappears when moving/zoominh, on every version since Alpha 8.

I did not find it a huge nuisance, but it is there, moving with the camera (though, again, it depends on the zoom …) To be more precise on the problem: it moves much like if it was an object "behind" the map, so it moves on the screen (imagine a starfield moving behind, for example). It also gets bigger when you move from the left side corner to the far right corner of the map. Perfect rectangle, which leads me to think it's some sort of zBuffer problem. It's especially prominent when zoomed out. Revealing the map changes strictly nothing. it still happens when rotating, and it moves in a consistent way, albeit fairly unpredictable. It happens in wireframe mode too.

It appears on any map that has water, including maps that are only water, but I failed to have it on exclusively land maps (such as the demo wall test RM). It may come from a problem with the water rendering.

[historic_bruno]

Replying to wraitii:

I get this one too, on a MacBook Air 13" (last generation iirc)... But not permanently, it appears/disappears when moving/zoominh, on every version since Alpha 8.

Can you attach your system_info.txt file per the above instructions? Which version of the game are you using? Do you get any OpenGL errors during the game (or in the logs, ~/Library/Application\ Support/0ad/logs/interestinglog.html)?

[wraitii]

System info: ​http://pastebin.com/nArAAMmy. It happened on every version of the game I used since Alpha 8, and I'm currently up-to-date with SVN. No error of any kind, as far as openGL is concerned. I'm going to try changing some of the settings to see if I can pinpoint the problem.

[wraitii]

Allright, further progress: it only happens for me when "fancywater=true", ie the games uses the fancy water shaders. it also happens using "renderpath=fixed", using preferglsl=true, and the other settings don't seem to change anything either.

So I think it's linked with the presence of advanced water.

[Kieran P]

k776's System Info

[historic_bruno]

Weren't there water rendering problems with Intel HD graphics on other OSes too? I don't know if they still exist or have been fixed.

(We could disable fancy water with that card on Macs if nothing else.)

[wraitii]

That's possible... I have an iMac at home, I'll report this WE.

[wraitii]

Confirmed: this does not happen on my iMac, so it might be a problem with the Intel HD 3100 of the MacBook Air. I'd advise against disabling fancy water, but not enabling it by default (and warning of compatibility issues) is an idea if it can't be fixed. However, as non-fancy water is so ugly, I really find it hard to play with it disabled.

[historic_bruno]

In fact there's an unresolved ticket for it: #966

[myconid]

I'm not entirely sure what's being described, but if it's a black thing that appears in the reflection in the water, it could be the reflection camera cutting off the skybox because it's too far away.

Maybe try setting the view.far value in the config to something larger.

[dialectric]

In reply to myconid, the artifact is black lines on the screen. The lines can be either horizonal or vertical, sometimes, as in the screenshot at the top, two sides of a rectangle. The lines are only a few pixels wide. They can appear even when there is no water on the screen, as long as the map has water on it.

I am also using a newer macbook air and have encountered this bug in the Sept 2012 build. As described above, turning off 'enable water reflections' eliminates this issue.

[wraitii]

This has been reported by k776 has being fixed with my changes to the water shader. Any confirmation?

[Kieran P]

Still haven't seen this since the water changes. Marking as fixed for this release.

[wraitii]

Re-opening since it still happened on my MacBook Air (mid-11 with Intel HD 3000 on 10.8.2).

I have a patch, attached. It's extremely simple and fixes the issue, but I want to make sure it doesn't break other systems, as it basically shortcuts the scissor test. I think the scissor test wasn't wide enough or something, and since water reflections/refractions are rendered before anything else the scissor test for clearing shouldn't really be necessary so I just removed it.

The patch also fixes a bug: the reflections were rendered when the refractions and the reflections were disabled.

[wraitii]

The patch doesn't change anything on my iMac which didn't have the issue in the first place, so if someone else reports it as working I'd say we commit.

[Kieran P]

Removing code that has been there for some time is always risky. I'm including myconid into the conversation since he is familiar with the renderer as well. To both of you:

What does GL_SCISSOR_TEST do? If it fixed the Mac, will it break Linux/Windows instead? What was the original reason to use GL_SCISSOR_TEST? Is this no longer the case?

[myconid]

GL_SCISSOR_TEST is used for masking out part of a buffer.

Reflections/refractions use parts of the main screen buffers for rendering, then copy the result to a texture, then clear the buffers. As an optimisation, instead of clearing the entire buffers, they use a scissor test to clear just the parts that they used.

It looks like on the Macbook something goes wrong and a few pixels of either the depth or stencil buffers are left uncleared. Since the problem only occurs on the Macbook, that suggests a driver or hardware glitch rather than a bug in our code.

The patch works around the issue by removing the optimisation and clearing everything in the buffers. The downside is that it makes the fancywater slightly slower for everyone.

[Kieran P]

Ok, doesn't sound like an acceptable approach to remove the scissor test then. Moving this to Alpha 13 so we have time to work out a proper solution.

[wraitii]

I have no idea how it works, but maybe OpenGL is actually faster at clearing the whole buffers as clearing a specific part, it should be checked. Anyway, this is indeed what the patch did, and I agree with Myconid on the issue. i'll give a shot at clearing a small margin more, but I doubt it'll work. In case it indeed doesn't, perhaps there could a specific handling of this case.

[wraitii]

This would be fixed by using framebuffers for water rendering, which we should just do anyhow. I think I haven't yet because some graphic cards didn't support them but they're basically too slow to live anyhow.

[wraitii]

Above patch switches to framebuffers (for now there's a basic check that probably should be removed) and fixes the issue.

[historic_bruno]

glDeleteFramebuffers should be pglDeleteFramebuffersEXT, that's a build error in MSVC. You probably shouldn't be storing -1 in a GLuint (signed/unsigned mismatch build warning).

I haven't closely reviewed the patch, someone with more GL expertise should do that, but it seems to run fine on Windows with an AMD Radeon HD 6850. I guess the real test will be with Intel HD graphics.

[wraitii]

Updated version fixing the build error (not the -1 stuff, forgot about that.) The setting to -1 may actually be buggy for the next frame in case of errors, I'll have to check. It works just fine on my Intel HD Graphics 3000 384 Mo, but that's a fairly "high-end" intel HD.

Getting proper configurations would be somewhat of a requirement for proper handling of water, but we can't really do that until we've centralized settings a bit.

[wraitii]

Fixed by using FrameBuffer Objects (verified on my MBA).