After a user spend three days trying to find out why certain
textures looked red (as if they had alpha and you pressed
control-alt-T, but not all of them were like that); and nothing
helped, not relogging, not clearing cache, not even reinstalling
the viewer... I decided to take this bug serious. Note that,
according to Shyotl, there have been more users every now and
then that reported this problem.
The problem (after doing a research for 1 hour) turned out
to be that she had beacons on, highlighting prims with scripts.
The immediate bug is, of course, that this was persistent over
a relog. Upon further investigation, this bug exists because
a Debug Setting had a double meaning: it meant both "beacon
floater is visible", which you want to be persistent, and it
was later renamed and given the meaning "Keep beacons when
closing the floater". Digging deeper it turned out that there
was a REAL mess with regard to the beacons: A non-finished
floater with immature comments (called "dingdong floater") was
half-created and replaced the original floater which, according
to the comment was "so fucked over and over" (== commented out
in several places), but then everything was commented out and
replaced with a menu (because they couldn't get it to work?).
The floater simply didn't exist anymore! That reduced the
meaning of the Debug Setting to "Show beacons", although you
now could only set it in the menu by clicking on "Beacons Always On"
where 'Always' refers to also on when the floater isn't there.
I nuked the immature dingdong code, brought back the original
floater as it was in snowglobe (and still is in Imprudence),
fixed it up a bit with a nicer layout (indentation and spacing)
and disabling (graying out) when needed, and added a new checkbox
that will allow people to still keep/see the beacons after closing
the floater.
In the end this requires THREE Debug Setting variables:
ShowBeaconsFloater : TRUE when the floater is visible, FALSE when not.
This is persistent, so the floater is still
there if you relog with the floater open.
BeaconsKeepVisible : TRUE when the new checkbox is checked.
Also persistent.
BeaconsVisible : TRUE when the beacons are rendered, FALSE otherwise.
This is NOT persistent: we don't want unsuspecting
users to try and get rid of the weird 'red prims'
by relogging and failing at that.
Don't enable AA in deferred/ui/etc unless AA is actually enabled via setting
Standard c array instead of silly vector, since the size is knowable at compile.
This makes sound beacons green when playing at
full volume, yellow when playing at a lower volume
and red when they are muted (aka, in another parcel
that you can't hear the sounds of).
Originally this was a debug patch as muted sound
sources used to be implemented by setting the volume
to zero, which happens to use like three times more
CPU: so, having a lot of muted sound source caused
the audio thread to never release a mutex anymore
(cause it was never idle anymore), causing the main
loop to hang, waiting on that mutex - dropping the
FPS drastically. Hence it was necessary to see which
sound sources were muted for debugging purposes.
(Since VWR-14914, muted source source are not played
at all anymore, so they do not take extra CPU).
It's still fun to see this extra information though,
now the patch exists anyway.
It now is disabled if:
-Lacking hardware support for FBOs
-RenderDeferred not permitted in gpu feature table
-RenderAvatarVP not permitted in gpu feature table
-VertexShaderEnable is enabled and permitted in gpu feature table
-WindLightUseAtmosShaders is enabled and permitted in gpu feature table
Enabling deferred now requires WindLightUseAtmosShaders to be on beforehand, instead of blindly enabling it.
LL has since removed high-res snapshots using render targets. I find this change to be favorable, as rendertargets were very finicky to get working with anti-aliasing. Also, deferred rendering uses many rendertargets that depend on screen resolution. Changing resolution every screenshot is.. not very awesome.
There is some deviation from LL's viewer. I've kept the old tiled glow pass enabled for non-deferred, as it fixes issues with tile edges truncating glow propogation. However, this does no work with deferred yet. I need to pin down why. I assume using binding one of the RenderTargets is required for deferred.
Additionally, the usage of a RenderTarget for snapshots is what prevented me from fully enabling my supersampling settings. Now that that hurdle is gone, I consider including this new setting by default to be safe enough.
And a note: Do not remove the 'tiling' variable when merging with v2 changes, as singu's glow pass is 'special'. There are other fixes absent from LL's viewer that require knowing if the render is tiled or not. (water reflections/cloud freezing)
Need to test:
localassetbrowser
preview related floaters
hgfloatertexteditor
maps
media textures! Currently very hacky
web browser
alpha masks on avatars
bumpmaps
Are all sky components appearing?
LLViewerDynamicTexture (texture baking, browser, animated textures, anim previews, etc)
Snapshot related features
Customize avatar
vfs floater
UI textures in general
Texture priority issues
Deferred fastalpha behaves a bit better.
Pulled over patch for https://jira.secondlife.com/browse/STORM-336 and https://jira.secondlife.com/browse/STORM-1011 from linden repo
Sky rendered using new LL method. Assuming this fixes issues on AMD cards(works on cat 11.2)
Added a few things missed related to spatial-parition updating.
Added 'SkipReflectOcclusionUpdates' setting that prevents occlusion updates for reflection pass. Less taxing on CPU.
