> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/settings.xml, line 7823 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8132#file8132line7823> > > > > I still think it might be valuable to attenuate (HSV) saturation, but > > since it'd been stuck at 1.0 since forever and it doesn't look like it'll > > be exposed in Environment Settings anytime soon... *shrug* > > > > Used like this, RenderSSAOEffect might be entirely redundant with > > RenderSSAOFactor, if I remember correctly? > > Tofu Buzzard wrote: > I don't think HSV-modulating according to SSAO is valuable (either > aesthetically or physically) - some sort of colour-grading function would be > grand but it shouldn't be tied to SSAO. Only the 'V' part has ever been > enabled (as released) as you say... > RenderSSAOEffect and RenderSSAOFactor are unrelated.
Hmm, there is some effect where saturation (seems to) decrease on AO'd areas, but that can be more illusion than physical. Tweaking it here would be either cancelling it or exaggerating it, and I can see the argument for avoiding it. Though there are real cases of artificial narrow-spectrum direct lighting + fuller-spectrum ambient light, like gas-discharge streetlamps at dusk or the such - thus my selfish lust for it getting exposed in environment settings... :p Looking at your comment, I think -Factor might be being used for something different from when I was using it, so never mind that. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl, line > > 214 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8134#file8134line214> > > > > Where's the code where ssao_effect_mat had been constructed? (If it's > > not being used, it should probably be taken out too.) > > Tofu Buzzard wrote: > It was being constructed in pipeline.cpp, and the patch includes removal > of that part. Whoops, thanks; not sure how I missed it. > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line > > 130 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line130> > > > > Won't using norm.xyz*diff raw like this cause false positives (from > > self-occlusion)? IIRC, that was why the old code used > > dot(samp-0.05*norm-pos, norm). (todo for self: render this for one sample > > to check...) (same for class1) > > Tofu Buzzard wrote: > I'm not sure I follow - but a sample candidate co-incident with the > sample origin is disregarded. 'angrel' and the larger sampling radius seem to have taken care of it. This was referring to the case where, for example, a sample pixel is picked that's 0.01 m away from the origin on the same triangle, and with a little rounding error, the sample ends up looking like a huge occluder. The old code has nothing analogous to 'angrel': there's an assumption that incoming ambient light is falling onto the sample origin equally from all directions. > 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! > > Tofu Buzzard wrote: > And thanks for taking a look! I see I should have been paying closer attention to the changes! :P Sorry if I'm struggling to catch up a bit. The same branch is also in class 1 too, FYI. I'm not sure what the definitions of the classes are these days.... > On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line > > 132 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line132> > > > > Out of curiosity, why a minimum, instead of ex. "(angrel>0) ? distrel : > > 0.0" ? Seems odd in cases of 0 < angrel < distrel. (No longer using the > > sphere assumption?) > > Tofu Buzzard wrote: > The reasoning was that as a sample candidate draws nearer to the sample > origin, the relevancy of its relative angle becomes overshadowed (so to speak > :)), given that it's not really a point but a sampling of something (i.e. the > sphere) with size whose extents are also increasingly blocking off the local > area. Conversely, all distances being equal, the occlusion of the sample > origin is proportional to the directness with which the sample candidate > blocks its normal (the direction from which it *would* otherwise be drawing > the most light). > So the two relevancies modulate either other, the 'correct' mixing of the > two in my head would be sqrt(angrel*distrel) but max(angrel,distrel) seemed a > touch more pleasing and probably quicker. Thanks! You may want to put in that you're not presuming uniform incoming ambient light like the old code was. (Also, you forgot the sqrt in your comment if you were intending it to say the same thing as you said here?) - Celierra ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Jan. 11, 2013, 1:34 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:34 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
