> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line > > 127 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line127> > > > > The 'if' here might be problematic.. I remember some cards were choking > > on branches, thus the convoluted lines that looked like new = old + > > int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying > > what the non-mangled math originally was (a la the old > > softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the > target class). I don't strictly remember removing comments on the original > maths, but the weighting (the only mathy part of this affair really) has > changed radically at least twice since the original inline explanation, and > should be simple enough to follow procedurally lately. :) > > Geenz Spad wrote: > However, a general rule of thumb is if you can save a branch in a shader, > then you should do so. My personal preference is to try and keep it to > branches that have defined ARB instructions that a vendor's GLSL compiler > will likely optimize to (which is limited to less than and greater than > unfortunately). Though you're right, it's not much of a problem on class 2 > hardware that can handle deferred. > > That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > > 0.0? > > Tofu Buzzard wrote: > Added comments which explain diff.z != 0.0 somewhat!
And thanks for taking a look! - Tofu ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:22 p.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2013, 1:22 p.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is > applied, fix a bug in the screen-space shadow/ssao smoothing offset where the > 'checkerboard' stipple had been refactored incorrectly, change some default > settings in line with the resulting visual changes. Disregard samples which > are being taken from outside the screen extents - eliminates spurious SSAO > fringe at screen edges at some angles. Micro-optimize the shadow co-ord > calculation. Also, improve comments a bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl > UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux > only. > > > Thanks, > > Tofu Buzzard > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
