[PATCH] Water turning red

[brian]

Revision: 15579

RMS: cycladic_archipelago

The water can turn red in several situations, especially in Atlas and when resizing the game view.

[wraitii]

I'm going to assume that you have recompiled the game properly.

I absolutely can't reproduce this, it doesn't happen for me. The red thing is probably because the waves move, incidentally. Also BTW that's not the impassibility grid, but that isn't really important.

Does this happen on all maps? Is it affected by zooming? Is it just moving the camera?

[Stan]

I had the same issue using the last autobuild, by raising the water and making go down in atlas. Some red areas would appear on the shore.

[Tom Brewe]

I had the issue with displaced shore waves when switching to windowed mode, and back to fullscreen. I Fullscreen the Waves were fine. But when in windowed mode (+ resizing the window by hand) the shore waves moved.

[brian]

It happens with both the open source and proprietary drivers (HD 5770, Ubuntu 14.04)

[Josh]

Same problem here (HD 5450, Open Drivers, Ubuntu 14.04, GLSL), I attached a clearer picture of the displacement which changes with zoom and camera location. It seems when the camera is at the same height as the water plane the waves are in the right place, but the more zoomed out the camera is the greater the displacement. I'd guess some confused matrix operations.

[Josh]

Wave displacement

[Josh]

Happening to Gameboy on the forums as well. In January he had a Nvida GeForce GTX 650 on Windows Vista.

[wraitii]

To clarify: there only are problems on HQ water, with waves?

I don't really see how my matrixes could be wrong on Linux and right on OSX but I'll look into it.

[brian]

"To clarify: there only are problems on HQ water, with waves?"

Yes, as soon as I turn off HQ Water, the waves and all the graphics bugs stop.

[wraitii]

Can any of you debug? If so I'd like to know what data gets passed to str_transform in: -renderer/WaterManager.cpp, line 852 -renderer/terrainRenderer.cpp, line 719 -renderer/terrainRenderer.cpp, line 764

[Stan]

What do you need ? I have vs2012 near hand, but don't really know how to use it for that purpose.

[brian]

Ok, got the debugger working, but I wasn't really sure what values you wanted out of the str_transform. Let me know what you need from str_transform and I'll see if I can get it.

(I am a little confused as that variable doesn't seem to be defined anywhere. It also won't show up properly in my variables pane like all the other ones. I can still view some of its values on the little window provided when hovering over it.)

[Stan]

Here is another example just in case.

[wraitii]

Stan: That appeared after you raised the water in Atlas, right?

[Stan]

Nope Just played around with the camera.

[Radagast]

Isn't it too seldom to be a release blocker? If this happens rarely ingame and only occasionally in Atlas, then we should change the release blocker to Must have and Alpha 18.

A17 is great as is, it must not be perfect.

[Stan]

It happens for me each time I do something with atlas.

[brian]

Seems to be fixed for me on RMS: cycladic_archipelago. Current revision is 15712, but I imagine it was fix a little while ago. I think it required updates to individual map scripts.

[Stan]

Not fixed for me at all. I can reproduce the same screenshot than the one above.

[historic_bruno]

Replying to stanislas69:

Not fixed for me at all. I can reproduce the same screenshot than the one above.

Can you attach your system_info.txt here?

[historic_bruno]

Thanks. Both reports are AMD Radeon HDs, one on Linux and one on Windows.

I have an AMD Radeon HD on Windows 7, but so far I haven't seen this bug. It may be I have different drivers or it doesn't affect my card. I found a bug in the new water rendering code (#2784), there's a slight chance that is related, so please test again after that is fixed and a new autobuild occurs.

[Stan]

I got some warnings when loading Azure coast

[Stan]

I believe this is also because of switchable graphics (HD4000/RADEONHD8750M)

[Josh]

I do not have switchable graphics, so that is not the cause.

[historic_bruno]

I noticed this last night while testing a map in-game, but it was much less obvious than the above screenshots. It was maybe 1-2 red tiles along a river, that disappeared after moving the camera and I couldn't find a way to reproduce it after that.

[Stan]

Azure coast is the worst I can make.

[Yves]

We agreed that this problem is important but not severe enough to block the release of Alpha 17.

[Yves]

This happens when you change the resolution (resize the window, enter fullscreen mode etc.). The waves don't adjust correctly to the new resolution. They appear to be rendered several meters above water level. When change the perspective by moving the camera, it's possible to move them above land and they become red.

[Stan]

Don't you want it to be reviewed for next release ? :)

[wraitii]

From the looks of it the solution is good but It'd need to be updated very slightly, I'll try to do it this afternoon. Could someone on a system that allows resizing check if it does fix the issue?

[Niek]

The shore waves are fixed for me, they don't move around anymore.

I still have other issues though (related to water but maybe not exactly the same issue): ​http://i.imgur.com/LKFaam4.jpg ​http://i.imgur.com/f31gOiP.png ​http://i.imgur.com/0ocgary.jpg (this one happens when taking a big screenshot)

I think this particular patch is still worth committing though!

[leper]

Replying to wraitii: Any progress?

[wraitii]

I've thought about it again and there's no reason why it wouldn't work, there's probably a few more places where we could use this resize but I don't have time to check those right now and since this is an important bugfix I'll commit it.

[historic_bruno]

Replying to wraitii:

Could someone on a system that allows resizing check if it does fix the issue?

You can't resize the window on your system? (that's a problem) I remember that happening to me on OS X, but not the exact circumstances. I think switching fullscreen<->windowed would be enough to test though.

[wraitii]

Hm, I actually can. I just remembered the old days when OSX couldn't (pretty sure it was an SDL issue) and never tried again :P .

Definitely fixes the issue for me, so I'll commit right away.

[wraitii]

In 16315:

Add a new function to update the water renderer textures when resizing the renderer window. Patch by pendingchaos.
This fixes #2692 though the same issue might appear in some other cases (possibly Atlas) and those will have to be checked.

[Niek]

I did check it with Atlas.

[Stan]

Does That fixes red water too ? Wind direction and glitches ?

[serveurix]

I still have the bug with the last svn.

small screenshot (in-game) : ​http://pix.toile-libre.org/upload/original/1423662041.jpg big screenshot : ​http://pix.toile-libre.org/upload/original/1423662098.jpg

In the game, it appears when I'm moving the camera very fast towards the water point, or under a low angle. On big screenshots it's quasi-invariable as long as there's a bit of water on the picture.

[Niek]

Replying to serveurix:

I still have the bug with the last svn.

small screenshot (in-game) : ​http://pix.toile-libre.org/upload/original/1423662041.jpg big screenshot : ​http://pix.toile-libre.org/upload/original/1423662098.jpg

In the game, it appears when I'm moving the camera very fast towards the water point, or under a low angle. On big screenshots it's quasi-invariable as long as there's a bit of water on the picture.

That's a different issue. This was about coastal waves.

[wraitii]

This only fixed the issue that resizing (and a variety of actions close to that) led to buggy water. The red water occasionally is a separate problem that shouldn't happen too often in an "in-game" context, though it should be improved someday.

[Itms]

I update the ticket then!

[Niek]

I think the images should be updated too. Look at comment:42, comment:15 and comment:34 for some.

[Niek]

What should I test for (what is your patch supposed to fix)?

[pendingchaos]

Replying to niektb:

What should I test for (what is your patch supposed to fix)?

It fixes the problem mentioned here: ​http://trac.wildfiregames.com/ticket/2692#comment:42

[Stan]

I am moving it to A19, seems like your patch doesn't work for me, I can reproduce the red water like on the above images. If you want to get the same thing, open Atlas, load azure coast, scroll to the water and then open the object tab.

[Niek]

Replying to stanislas69:

I am moving it to A19, seems like your patch doesn't work for me, I can reproduce the red water like on the above images. If you want to get the same thing, open Atlas, load azure coast, scroll to the water and then open the object tab.

That's not what the fix is supposed to fix. It fixes what is mentioned in comment:42.

[Stan]

The ticket is now about red water... And comment 42 is about... red water.

[Niek]

Replying to stanislas69:

The ticket is now about red water... And comment 42 is about... red water.

You did check the images in comment:42? The way you try to reproduce it gives another 'type' of red water (like you showed in comment:15). Not the type this patch is supposed to fix.

[Stan]

Well it looked the same, so... I supposed it was fixing both.

[historic_bruno]

WaterManager should possibly be doing something more involved like PostprocManager, which basically does a full reinitialization on resize. I see this consistently when opening e.g. Azure Coast(2) and going right to the objects tab.

[historic_bruno]

Disabling camera constraints and moving the camera around (under the water plane or through terrain) also causes the red water bug, even without window resizing. I don't think that should happen, even if it's atypical conditions. Maybe it's possible to move the camera in a way that breaks things with camera constraints?

[Stan]

I can't find any trivial way to do that... Or maybe play with water level and wind angle.

[pendingchaos]

red_water_bug2.diff​ did not fix the bug, it only made it appear less. I have submitted a patch (red_water_patch2.diff) that should fix it. It also stops the water being incorrectly culled in some situations (caused by lines 583 and 584 in TerrainRenderer.cpp). The patch does not fix the red water in Azure Coast, it seems to be a different bug.

[Stan]

Hey, nice job on it, it's nearly fixed, I can still reproduce the bug the way I stated in comment:50 now this autofix itself when switching to another tab, maybe something doesn't go right on first initialization, keep it up !

[Stan]

I think both this and #3048 should be commited ( since it´s the same patch)

It greatly reduce the bug to the specific case of comment:50

So create a new ticket for (I can do it if you want).

A note to comment:60 After changing tab (from object to anything bug is fixed but if you rotate the camera to be parallel to the water fish´s texture alpha turn red.)

[Philip Taylor]

I think the problem with the object tab is that AtlasUI calls ActorViewer::SetWaterEnabled, which calls CCmpWaterManager::SetWaterLevel in the secondary simulation instance that's used just for the actor viewer. But CCmpWaterManager updates the single global g_Renderer.GetWaterManager()->m_WaterHeight, which is then used when rendering the primary simulation instance. (In particular it's used to compute the culling for the refraction texture, and if the water height is lowered then too much will be culled, and the refraction texture will contain unfilled red regions.)

Probably the right solution is to make WaterManager not a singleton. It contains persistent state that depends on the simulation state, so those stateful parts should be owned by the simulation (maybe CCmpWaterManager) or by CTerrain - that'll let us safely have multiple simulations with independent water states (main game and actor viewer, or multiple instances of the game, etc) and avoid this kind of interference.

[ben]

In 16378:

Disables water in actor viewer, as a temporary workaround for the "red water" bug, see #2692 for proper fix

[Philip Taylor]

What is the reasoning behind red_water_patch2.diff?

I'm not sure what the reason for the extra complexity in the current ScissorWater function was, compared to what the patch changes it too, but I assume there was one. So I think it'd be valuable to know whether the original code was actually fundamentally wrong, or was right when it was written but was invalidated by later changes to the water renderer, or if it's mostly correct and just a bit buggy; and whether the patch's version is fundamentally more correct or not.

(The danger is that the patch might be scissoring too conservatively - it could fix the rendering errors but hurt performance by rendering much more than it needs to, and it would be much harder to track down that problem later than to make sure it's correct now when changing the code.)

[pendingchaos]

A potential fix for the red water bug (c comment 4 details)

[pendingchaos]

Potential fix for the red water issue. This seems to fix the issue any red water issues that I can find. The only concern that I have is that scissor rectangle is rather big in some situations although it is still correct in some situations. I think the reason for the large size is because it works per patch and not per tile. As per leper on IRC posting the patch for review, feedback and discussion.

Regards

[Stan]

Any update on this ?

[mimo]

pushing it as no activity

[Stan]

@pendingchaos I tried your patch today and couldn't see any difference. If you still want to work on it could you please take a good screenshot before and after the patch so we can see what changed.

Anyway thanks for working on it.

[Vladislav Belov]

REFRACTION: enabled vs disabled

Light ray goes away from the refraction bounds. You could see repeatative terrain under water.

[Vladislav Belov]

Refractions: before/disabled/after

There was the problem, because the checking was only for a top face of a water patch BB, but if user looks from a side then this bug could appear.

If someone has this issue before, the test the last patch.

[elexis]

Dont forget to bump the year of that file.

[wraitii]

Attached patch does not seem to fix the issue. The refraction map still sometimes lag behind the camera weirdly.

[gameboy]

@vladislavbelov: Could you please tell me what map you are using? What is the name of the map?

[elexis]

Backlogging due to lack of progress.

[Vladislav Belov]

Fixed in r25440.