PostProc showing really weird behaviour on Mac

[Kieran P]

I'm getting the following when running 0 A.D. ​http://i.imgur.com/RmMfe.jpg

This didn't happen during a game we had leading up to the Alpha 12 release. So whatever has changed happened after that game.

[Raymond]

Works great on:

OS X 10.8.2 on a AMD HD 5670

see screenshot

[historic_bruno]

Replying to k776:

See attached file.

Which package?

[myconid]

Need more info. Which map? What config?

[myconid]

Hold on. This is because of historic_bruno's patch for #1768.

[myconid]

Right, need more info. Is this with postproc on or off?

[historic_bruno]

Replying to raymond:

Works great on:

OS X 10.8.2 on a AMD HD 5670

see screenshot

Your config doesn't appear to have shadows enabled, let alone more advanced GLSL stuff, is that by choice?

[Raymond]

so now I enabled all settings, no problems (12 out of 13 settings are enable in settings, except Developer Overlay)

map: Acropolis I

[historic_bruno]

Ok thanks, good to know :) That's using the 64-bit bundle?

[Raymond]

Replying to historic_bruno:

Ok thanks, good to know :) That's using the 64-bit bundle?

yes, of cause.

[Kieran P]

This is the Mac package Ben built, which includes the patch he made recently, yes.

Here is my local.cfg. The map was the default one I believe (Acropolis 1).

windowed = true
xres = 1280
yres = 700
pauseonfocusloss = false

playername = "k776"

waternormals = true
waterbinormals = true
waterrealdepth = true
waterfoam = true
watercoastalwaves = true
waterrefraction = true
waterreflection = true
watershadows = true

showsky = true

renderpath = shader
preferglsl = true
gentangents = true
gpuskinning = true
smoothlos = true
postproc = true

materialmgr.quality = 10.0
materialmgr.PARALLAX_DIST.max = 150
materialmgr.PARALLAX_HQ_DIST.max = 75
materialmgr.PARALLAX_VHQ_DIST.max = 0

forcealphatest = false

hotkey.profile.toggle = "Alt+P"

The issue isn't prevent on the SVN copy of 0 A.D., so this may be related to Ben's patch, or something to do with the package picking up textures maybe?

[Kieran P]

Issue is still present in 32bit build but release is done, so we'll reupload fixed package later. Pushing to Alpha 13.

[Kieran P]

@myconid: cc'ing you in. Getting this weird behaviour: ​http://i.imgur.com/RmMfe.jpg

It only shows up when postproc setting is enabled in the config. Everything else off, and only postproc on, this issue still occurs.

I've done a complete rebuild (clean-workspaces and update-workspaces) and the issue hasn't gone away.

I've just reverted to the same revision that I played on with historic_bruno and Pureon, and the issue exists in that.

Which makes me think it might be some type of software/graphics update I've applied to the system through Apple's automatic updates. I'll try and track down if I installed anything recently. Till then, any steps I can do to help track down the issue?

[Kieran P]

I've also just tried deleting the cache (~/Libraries/Caches/0ad) which had no effect, the issue as seen at ​​http://i.imgur.com/RmMfe.jpg still exists after rolling back to a last know working revision, doing a complete rebuild, and clearing the cache.

The only recent updates to my Mac system have been an iTunes update and a Digital Camera Compatibility update. Neither should have affected the game.

I also installed AoK recently using a Wineskin (​http://wineskin.urgesoftware.com/tiki-index.php) which may have done something, but shouldn't have since it should be pretty self contained.

I'm out of ideas :-(

[myconid]

I think I've figured out what the problem is. The postproc renders to NPOT textures (to save memory), but calculates bloom by generating mipmaps (to take advantage of hardware filtering). While both features are very portable, it looks like the combination can have issues on some buggy/older drivers/hardware. I'll just get rid of the NPOT textures.

[Kieran P]

Any idea what would have changed in past the few days to cause this? I played a game with the same settings late last week with no problems. Only occurred recently, and can't see any recent commits that changes the postproc...

[myconid]

Maybe someone added a postproc effect to the map you were playing on.

[myconid]

A quick idea: can you please remove the following lines from PostprocManager.cpp (189-193) and recompile

	glBindTexture(GL_TEXTURE_2D, renderedTex);
	pglGenerateMipmapEXT(GL_TEXTURE_2D);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	glBindTexture(GL_TEXTURE_2D, 0);

This removes the hardware filtering, but in theory it should take care of the issue you encountered.

[Kieran P]

Negative. Commenting out those lines and recompiling did not fix the issue.

[Kieran P]

If it's any help, when I try the map we played last week (Boeotian Plains), that one works fine. So do a few other ones. Most of the Acropolis maps display the issue though. So what is Acropolis 1 doing that Boeotian Plains aren't?

[Kieran P]

With help from leper, managed to track it down to this setting in the affected maps:

<PostEffect>hdr</PostEffect>

When commented out, maps with that line return to normal. So the issue lies in HDR...(?).

[myconid]

I'm sure the issue is somewhere in the bloom code (included in the "hdr" effect).

First I'd like to know if this still occurs with POT-sized textures. Try changing the config so the game runs in windowed mode, with a square resolution (e.g. 1024x1024 or 512x512).

A separate thing I'd like you to try is to edit shaders/effects/HQDOF.xml to remove this line

<pass shader="glsl/hdr"/>

then open the "Campaign Test Map" and let me know if you still get the issue.

[Kieran P]

Tried 1024x1024 and had the same issue. Removed the glsl/hdr pass line, same issue. Tried 1024x1024 with removed <pass /> line and still had the issue. Any more ideas?

[myconid]

"patch -p1 -i postfix.diff" in 0ad root directory. Messes a little with the way the results are transferred from the postproc framebuffer to the system framebuffer. I'll be surprised if this fixes it, but it's worth a shot.

Also, ​this unanswered question looks like the same issue.

[Kieran P]

Reverted the previous made changes, and applied that patch and the problem still exists. :-(

[myconid]

Ok, last attempt for now. Revert changes and apply as before.

[Kieran P]

Negative. Still getting the issue with postfix2.diff :-(

[historic_bruno]

For what it's worth, Apple's software renderer supports GLSL and actually looks pretty good with postproc off (though it's painfully slow). With postproc on, I get similar problems to k776. So I can help with testing, if there's anything I can do.

[myconid]

It turns out that Apple's software renderer is actually Mesa's FOSS software renderer (thanks for the idea, historic), so I installed a VM with software GL and thus managed to reproduce the problem.

And, as I already suspected, the problem was with the bloom calculation! Put bloom.fs in shaders/glsl and hopefully the problem should be fixed now.

[historic_bruno]

Works for me, nice job! Hope it works for k776 as well

[Kieran P]

Indeed. It did fix the issue. The bloom is a lot on Acropolis 1. The starting units are almost a white haze because it's too bright. Michael should tweak that a bit... But as far as the rendering issues I got go, awesome work fixing it. Thank you.

[myconid]

Great. :)

As for the bloom being too much, it's because I changed the bloom calculation. I'll also tweak the "hdr" shader to tone it down before committing.

[Kieran P]

myconid, where is this at? Replacing bloom.fs worked a treat, but it's still overly bright on any map that uses it.

[myconid]

Okay, it's committed... though I must say I'm not too happy with how this bloom looks.

[historic_bruno]

I believe this is fixed now, perhaps some maps need their bloom values tweaked, but that's not high priority.