Opened 10 years ago
Closed 2 years ago
#2692 closed defect (fixed)
[PATCH] Water turning red
Reported by: | brian | Owned by: | Vladislav Belov |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 25 |
Component: | Core engine | Keywords: | patch |
Cc: | wraitii | Patch: |
Description (last modified by )
Attachments (14)
Change History (92)
by , 10 years ago
Attachment: | screenshot0015.jpg added |
---|
by , 10 years ago
Attachment: | screenshot0016.jpg added |
---|
by , 10 years ago
Attachment: | system_info.txt added |
---|
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
comment:3 by , 10 years ago
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.
comment:4 by , 10 years ago
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.
comment:5 by , 10 years ago
It happens with both the open source and proprietary drivers (HD 5770, Ubuntu 14.04)
comment:6 by , 10 years ago
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.
comment:8 by , 10 years ago
Owner: | set to |
---|---|
Priority: | Must Have → Release Blocker |
Happening to Gameboy on the forums as well. In January he had a Nvida GeForce GTX 650 on Windows Vista.
comment:9 by , 10 years ago
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.
comment:10 by , 10 years ago
"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.
comment:11 by , 10 years ago
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
comment:12 by , 10 years ago
What do you need ? I have vs2012 near hand, but don't really know how to use it for that purpose.
comment:13 by , 10 years ago
Description: | modified (diff) |
---|
comment:14 by , 10 years ago
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.)
comment:15 by , 10 years ago
comment:18 by , 10 years ago
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.
comment:20 by , 10 years ago
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.
follow-up: 22 comment:21 by , 10 years ago
Not fixed for me at all. I can reproduce the same screenshot than the one above.
comment:22 by , 10 years ago
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?
by , 10 years ago
Attachment: | system_info.2.txt added |
---|
comment:23 by , 10 years ago
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.
by , 10 years ago
Attachment: | interestinglog.html added |
---|
I got some warnings when loading Azure coast
by , 10 years ago
Attachment: | screenshot0214.png added |
---|
comment:24 by , 10 years ago
I believe this is also because of switchable graphics (HD4000/RADEONHD8750M)
comment:26 by , 10 years ago
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.
comment:28 by , 10 years ago
Priority: | Release Blocker → Must Have |
---|
We agreed that this problem is important but not severe enough to block the release of Alpha 17.
comment:29 by , 10 years ago
Milestone: | Alpha 17 → Alpha 18 |
---|
comment:30 by , 10 years ago
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.
by , 9 years ago
Attachment: | red_water_patch.diff added |
---|
comment:31 by , 9 years ago
Keywords: | review patch added |
---|---|
Milestone: | Alpha 18 → Alpha 19 |
Summary: | Waves uncovering red grid → [PATCH] Waves uncovering red grid |
comment:32 by , 9 years ago
Milestone: | Alpha 19 → Alpha 18 |
---|
Don't you want it to be reviewed for next release ? :)
follow-ups: 35 37 comment:33 by , 9 years ago
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?
comment:34 by , 9 years ago
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!
comment:36 by , 9 years ago
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.
comment:37 by , 9 years ago
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.
comment:38 by , 9 years ago
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.
follow-up: 43 comment:42 by , 9 years ago
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.
comment:43 by , 9 years ago
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.
comment:44 by , 9 years ago
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.
comment:45 by , 9 years ago
Description: | modified (diff) |
---|---|
Keywords: | review patch removed |
Milestone: | Alpha 18 → Backlog |
Priority: | Must Have → Should Have |
Resolution: | fixed |
Status: | closed → reopened |
Summary: | [PATCH] Waves uncovering red grid → Water turning red |
I update the ticket then!
comment:46 by , 9 years ago
I think the images should be updated too. Look at comment:42, comment:15 and comment:34 for some.
comment:47 by , 9 years ago
Keywords: | review patch added |
---|---|
Milestone: | Backlog → Alpha 18 |
Summary: | Water turning red → [PATCH] Water turning red |
by , 9 years ago
Attachment: | red_water_bug2.diff added |
---|
follow-up: 49 comment:48 by , 9 years ago
What should I test for (what is your patch supposed to fix)?
comment:49 by , 9 years ago
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
follow-up: 51 comment:50 by , 9 years ago
Keywords: | review removed |
---|---|
Milestone: | Alpha 18 → Alpha 19 |
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.
comment:51 by , 9 years ago
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.
follow-up: 53 comment:52 by , 9 years ago
The ticket is now about red water... And comment 42 is about... red water.
comment:53 by , 9 years ago
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.
comment:55 by , 9 years ago
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.
comment:56 by , 9 years ago
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?
comment:57 by , 9 years ago
I can't find any trivial way to do that... Or maybe play with water level and wind angle.
comment:58 by , 9 years ago
Keywords: | review added |
---|---|
Milestone: | Alpha 19 → Alpha 18 |
by , 9 years ago
Attachment: | red_water_patch2.diff added |
---|
comment:59 by , 9 years ago
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.
comment:60 by , 9 years ago
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 !
comment:61 by , 9 years ago
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.)
comment:62 by , 9 years ago
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.
comment:64 by , 9 years ago
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.)
comment:65 by , 9 years ago
Milestone: | Alpha 18 → Alpha 19 |
---|
by , 9 years ago
Attachment: | potential fix.diff added |
---|
A potential fix for the red water bug (c comment 4 details)
comment:66 by , 9 years ago
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
comment:69 by , 9 years ago
Keywords: | patch review removed |
---|---|
Milestone: | Alpha 20 → Backlog |
Owner: | removed |
Status: | reopened → new |
Summary: | [PATCH] Water turning red → Water turning red |
@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.
by , 8 years ago
Attachment: | reflections.png added |
---|
comment:70 by , 8 years ago
REFRACTION: enabled vs disabled
Light ray goes away from the refraction bounds. You could see repeatative terrain under water.
by , 8 years ago
Attachment: | refractions.png added |
---|
by , 8 years ago
Attachment: | TerrainRenderer.cpp.patch added |
---|
comment:71 by , 8 years ago
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.
comment:72 by , 8 years ago
Keywords: | patch review added |
---|---|
Summary: | Water turning red → [PATCH] Water turning red |
comment:73 by , 8 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:74 by , 8 years ago
Milestone: | Backlog → Alpha 21 |
---|
Dont forget to bump the year of that file.
comment:75 by , 8 years ago
Keywords: | review removed |
---|
Attached patch does not seem to fix the issue. The refraction map still sometimes lag behind the camera weirdly.
comment:76 by , 8 years ago
@vladislavbelov: Could you please tell me what map you are using? What is the name of the map?
comment:78 by , 2 years ago
Description: | modified (diff) |
---|---|
Milestone: | Backlog → Alpha 25 |
Resolution: | → fixed |
Status: | assigned → closed |
Fixed in r25440.
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?