Not logged inOpenClonk Forum
Forum Home Help Search Watchlist Register Login
Up Topic Development / Developer's Corner / Completing lights branch - issues (locked)
1 2 Previous Next  
Parent - - By Newton [de] Date 2014-11-23 19:23 Edited 2015-01-01 16:12
11. If you have several viewports and the light goes out of one viewport, the console is spammed with "GL error 1282: invalid operation"
Parent - By Newton [de] Date 2014-11-25 20:19
Same error message with current version.
Parent - - By Clonk-Karl [de] Date 2014-12-27 17:55
I had a look at this, and noticed that it does not have anything to do with the lighting system, but instead with the particle system. The problem is that for multiple viewports, multiple OpenGL contexts are used. These OpenGL contexts share their state, such as textures, compiled shaders and vertex buffers. However, vertex array objects (VAOs) are explicitly not shared between multiple OpenGL contexts. The particle system uses VAOs, though. The "invalid operation" error message is then generated when the second OpenGL context attempts to use a VAO that was generated by the first.

Basically what this means is that particles are only ever visible in one viewport. This can be easily reproduced also in the master branch: Just start Tests.ocf/Minimal.ocs, open a second viewport, and walk around with the Clonk. You'll see the "puffs" that are generated when the Clonk is walking in only one viewport, but not both. The reason why the error message is showing up only in the lights branch is that only in the lights branch there is a GL error check implemented which reports the last occurred error, but that error is not necessarily generated by the lights GL code.

I'll open a bug in the bugtracker about this, but I don't think it should be a blocker for merging the lights branch, since the problem is not caused by the lights branch.
Parent - By Zapper [de] Date 2014-12-27 19:21
oh..
Parent - By Newton [de] Date 2015-01-01 16:11
Bug is i the bugtracker now.
Parent - - By Newton [de] Date 2014-11-23 19:55
12. Since Peter's commit, sometimes there are little white dots in the light texture. The reason will be that the new triangle fan is drawn as a series of single quads next to each other.
Parent - - By PeterW [de] Date 2014-11-24 11:01
Yeah, I noticed that, too. Puzzling. There must be some sort of rounding going on... After all, it should really be possible to draw quads without overlap or gaps, right?
Parent - - By Newton [de] Date 2014-11-24 19:15
It should. But if they really do not overlap or have gaps, you could simply draw a triangle fan using only tri.nFanL -> tri.fanL -> nextTri.nFanL -> nextTri.fanL -> ...*. It is also faster that way.

*except if nextTri is clipped, then use fanR, nFanR for the last triangle
Parent - - By PeterW [de] Date 2014-11-25 17:32 Edited 2014-11-25 17:36
You mean a triangle strip, right? Not sure though - bright pixels means overlap, so if we draw it as a strip it would go "backwards", which will likely produce the same effect. I would really like to know what the reason behind this is, instead of trying to mask it. This stuff is a bad sign, I must have screwed up somewhere.
Parent - By Newton [de] Date 2014-11-25 18:25
Jupp, strip. Sorry.

In case you are interested in looking into that. There is another thing that is masked by the method of drawing: If you change the method of drawing intermediate fade triangles back to drawing single triangles, you will also notice bright lines when standing in certain angles near cliffs. (Tutorial 1: in front of the hole where you have to hangle)
Parent - - By Newton [de] Date 2014-11-24 20:35 Edited 2014-12-21 11:26
13. There is an assertion error when trying to draw material in the editor mode in C4DrawGL, line 537.
fixed by Sven
Parent - By Clonk-Karl [us] Date 2014-11-24 21:19
I can't reproduce that.
Parent - By Newton [de] Date 2014-11-25 20:15
Now I get another assertion error but when I do the same thing:

   openclonk-debug.exe!CStdGL::PerformMultiTris(C4Surface * sfcTarget, const C4BltVertex * vertices, unsigned int n_vertices, const C4BltTransform * pTransform, C4TexRef * pTex, C4TexRef * pOverlay, C4TexRef * pNormal, unsigned long dwOverlayModClr) Line 508  C++

   openclonk-debug.exe!C4Draw::DrawQuadDw(C4Surface * sfcTarget, float * ipVtx, unsigned long dwClr1, unsigned long dwClr2, unsigned long dwClr3, unsigned long dwClr4) Line 819  C++
   openclonk-debug.exe!C4Draw::DrawBoxFade(C4Surface * sfcDest, float iX, float iY, float iWdt, float iHgt, unsigned long dwClr1, unsigned long dwClr2, unsigned long dwClr3, unsigned long dwClr4, int iBoxOffX, int iBoxOffY) Line 1010  C++
   openclonk-debug.exe!C4Draw::DrawBoxDw(C4Surface * sfcDest, int iX1, int iY1, int iX2, int iY2, unsigned long dwClr) Line 1015  C++
   openclonk-debug.exe!C4ToolsDlg::NeedPreviewUpdate() Line 1043  C++
   openclonk-debug.exe!ToolsDlgProc(HWND__ * hDlg, unsigned int Msg, unsigned __int64 wParam, __int64 lParam) Line 407  C++

In C4ConsoleWin32.cpp C4ToolsDlg::NeedPreviewUpdate() a new C4Surface(iPrvWdt,iPrvHgt) is created and drawn using pDraw->DrawBoxDw. However, there is an assertion that the C4Surface must return true on IsRenderTarget, which it doesn't.
- - By Maikel Date 2014-11-21 09:46
I just wanted to point out this thing I have noticed about liquids, in terms of lightning they seem to behave like tunnel material, is this true? If yes, we could introduce an additional damping for liquids so that light does not travel as far is in tunnels.
Parent - By Newton [de] Date 2014-11-21 12:13
Not sure how to implement this. I think it is not worth the effort and complexity to do this.
Parent - By PeterW [de] Date 2014-11-21 15:40
Possible, but not trivial. We'd essentially have to track per beam how much water it has passed through. That becomes a bit messy if we have beams that enter the surface from the "side". Maybe we could split the beam up when it touches water (minimum 5 px?), then track for the left and right side how much water it has passed through. Then end the beam once it gets to a certain threshold.

Should be workable, but let's think about this again once we have understood the whole system a bit better...
- - By Maikel Date 2014-11-23 20:52
I found a new issue while scaling a bit with the clonk, it sometimes happens (my guess) that there is a material pixel at the clonks centre, which makes the screen go black completely.

And I found some strange artefact like circles in the attached picture.
Parent - By Newton [de] Date 2014-11-23 20:56
The screenshot is the same bug as 12.
- - By PeterW [de] Date 2014-11-25 19:33 Edited 2014-12-12 23:41
Oh, Newton is declaring the work on shadows finished while bashing my code? It's a challenge!

16.Overlap.png

My interpretation is that the intermediate fade point ends up overlapping the fan, therefore causing extra brightness there. No, not caused by my commit, this already happened before.
Fixed.

15.

No idea what is happening here. I blame Newton and his antiquated code style.

Seriously though, I'd investigate myself, but am a bit short on time until next weekend. Just wanted to put this here so it doesn't get lost. I am 90% sure that neither of these happened before the great refactoring.
Attachment: Overlap.png (269k)
Parent - - By Newton [de] Date 2014-11-25 19:54 Edited 2014-11-25 20:06
Are you sure you updated to the latest version? Both things look very familiar, but in the current version I cannot reproduce them anymore.

>My interpretation is that the intermediate fade point ends up overlapping the fan, therefore causing extra brightness there.


I think so as well. This was a common sight before the change to render the intermediate fade triangles as a triangle fan. The underlying bug has not been fixed. I spent some time debugging this but couldn't find the root of the problem. You can try to debug it by opening a second viewport and zooming in to the maximum, then enable the debug rendering and have a look at the triangles. Perhaps change the draw strategy to only draw intermediate fade triangles.

> No idea what is happening here


This is how it looked like since this and until this commit, when I deleted zero-size beams. Edit: I can reproduce it with a current version. It occurs when the ray should hit something but it is not within the viewport.
Parent - - By PeterW [de] Date 2014-11-25 20:15 Edited 2014-11-25 20:17
Yeah, I updated to the newest version before testing it again - had to fix some minor segfault to get there. I assumed you were aware and possibly had fixed it already, which is why I posted the screenshots only now. I mean, this is sort-of your turf now, I don't want to get into the way too much.
Parent - By Newton [de] Date 2014-11-25 21:19
As said, I have no clue about those bugs yet. I changed some of the overall architectural structure of the raytracing and rendering code, but it should still do the same as before. If not, this was a mistake that had been introduced through the refactor but by no means an implementation of something new that has a bug now. So I can't even imagine why you think you'd get into the way if you busy yourself with the code again. On the contrary, you are still the one with the most knowledge about the code and the highest chance to understand the the calculations made in the algorithms there.
When I busy myself with finding the cause of any bug, I will post beforehand in the forum, so we won't get into each other's "turf" here. But also, not before next weekend.
Parent - - By Newton [de] Date 2014-12-02 21:34

> My interpretation is that the intermediate fade point ends up overlapping the fan, therefore causing extra brightness there. No, not caused by my commit, this already happened before.


I have an idea about this. I am on it.
Parent - By Newton [de] Date 2014-12-06 01:49
done.
- By Newton [de] Date 2014-12-12 23:46 Edited 2014-12-12 23:54
After some more debugging, it looks like the error that causes #16 and #15 may be found in CalculateFanMaxed:

On ridges, the fanMaxed quads start earlier then they should, possibly causing overlaps. In the attached screenshot, only the fanMaxed quads are drawn.

If instead the quads are drawn as a triangle fan, there are some really odd effects I cannot explain at all, like dark sections, double-lighted sections and even double-lighted sections that are orthogonal to the normal rays etc. The latter seems to be an indication that the FanMaxed triangle calculation might have something to do with #15 since those sections pop up exactly at those positions. Overall, it is an indication that the calculated points are not (always) in the order and position we assume them to be because otherwise a triangle fan wouldn't look like that.
- By Newton [de] Date 2015-01-01 16:12
Closing this topic. Lets put everything else in the bugtracker now.
Up Topic Development / Developer's Corner / Completing lights branch - issues (locked)
1 2 Previous Next  

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill