Cool VL Viewer forum

Edit: Had not seen the parts of the thread regarding object-object occlusion. I'll keep this in mind next time I log in.

I booted into Windows 10 for the first time in months and let it do all necessary updates, drivers, etc. I updated the official LL viewer and NiranV's Black Dragon, both of which I had installed to try EEP before it was available for Linux. I installed Cool VL Viewer for the first time under Windows 10, so there was no previous cache or settings, and no Lua automation script. I did not notice the sky issue with LL's viewer at https://maps.secondlife.com/secondlife/Clanis/237/34/52. Upon logging in with Cool VL Viewer at the same location, I cammed around using my avatar as the focus point and saw the flashing in the sky once inventory loaded and the scene had fully rezzed.

As an aside, even if this issue cannot be resolved right away, I still enjoy using the Cool VL Viewer.
______________________________
Cool VL Viewer v1.28.0.2, 64 bits, Jul 11 2020 10:32:18
Release Notes

You are at 256749.4, 262178.4, 52.2 in Clanis located at
sim10115.agni.lindenlab.com (216.82.48.181:13002)
Second Life Server 2020-06-12T19:06:40.543526
Release Notes

CPU: AMD Ryzen 3 1300X Quad-Core Processor (3500 MHz)
Memory: 16336MB
OS version: Microsoft Windows 10 64 bits v10.0 (build 10586.836)
Memory manager: OS native
Graphics card vendor: ATI Technologies Inc.
Graphics card: Radeon RX 580 Series
Windows graphics driver version: 27.20.2001.8002
OpenGL version: 4.2.14736 Compatibility Profile Context 20.7.1 27.20.2001.8002
Detected VRAM: 16339MB
J2C decoder: OpenJPEG: 1.4.0.635f
Audio driver: FMOD Studio v2.01.01
Networking backend: libcurl/7.47.0 OpenSSL/1.0.2l zlib/1.2.8
Embedded browser: CEF3 plugin v74.1.19+gb62bacf+chromium-74.0.3729.157
Packets lost: 4/22218 (0.0%)

Built with: MSVC v1916
Compiler-generated maths: SSE2.

Compile flags used for this build:
/O2 /Oi /MP /DNDEBUG /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /Oy- /GS /fp:fast /TP /W2 /Zc:forScope /Zc:wchar_t- /c /nologo /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0600 /D_WIN32_WINNT=0x0600 /DXML_STATIC /DBOOST_ALL_NO_LIB /DLL_LUA=1 /DLL_FMOD=1 /DAPR_DECLARE_STATIC /DAPU_DECLARE_STATIC /DCURL_STATICLIB=1 /DLIB_NDOF=1

For this test, I reverted LLPipeline::updateCull() to what it was before EEP, regardless of the renderer in use: it does not seem to have ill-effects for me (but would need more serious testing still) and could solve the issue for you.

Please, replace llpipeline.cpp with the attached (gzipped) version, recompile, and see how it fares...

OK, neither the test to remove the extra line for gUseNewShaders nor the entire file (llpipeline.cpp) replacement changed the behavior.

Last test for today with yet another llpipeline.cpp version:

This time, I added a #define (line 102) so that you can test it both without (default) and with (once the define set to 1) force-WL-style culling (recompile each time).

EDIT: Also (last idea before I go to bed): what if you enable the "RenderCullWater" debug setting ?

A quick reply to say that after disabling object-object occlusion, I have not seen sky flashing while driving through many sims in Heterocera, including the locations I posted about earlier.

The new file, in both configurations for LL_FORCE_WL_CULLING, resulted in no change and I was still able to see the issue.

With RenderCullWater set to true, in both the test build with that new file (both configurations) and with the original (from my build on Saturday), the issue does not happen. The sky remains normal at all viewing positions for both regions where I experience the issue.

Well, that explains it all then... I added this setting (and made it default to off) because water culling is (very) detrimental to the frame rate (especially with many neighbouring sims), but all other EE viewers do this kind of culling (without any way to disable it). What is weird is that *water* culling affects *sky* in EE (and with the camera *above* water) !... Probably a bug in LL's renderer.

I will therefore not "fix" the issue (since there is nothing to fix in my code): if you do see the issue happening, just enable this setting. People not seeing it will be able to enjoy a better frame rate with it off.

I might just stick with WL for a while longer then since RenderCullWater drops my frame rate significantly. I had been hopeful that our experiments would identify a bug that could be 'easily' fixed.

RenderCullWater set to FALSE does result in a higher framerate for my system, especially noticeable in a skybox where it might jump from 60 to 80 fps. Enabling object-object occlusion has some benefit, but less than enabling RenderCullWater. I will keep RenderCullWater set to FALSE and object-object occlusion disabled. It seems after some testing that the issue may still occur with object-object occlusion disabled.

Yep, I'm getting lower framerate as well with it on, so am back on WL. I would have hoped LL would be able to improve performance considering these are newly written shaders.