Re: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering

2013-01-11 Thread Tofu Buzzard 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/611/#review1289
---


Anyone?

- Tofu Buzzard


On Dec. 2, 2012, 2:53 a.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/611/
> ---
> 
> (Updated Dec. 2, 2012, 2:53 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Made deferred water use the atmospheric helper shader functions properly, 
> made fog calculation view-relative rather than absolute-position in deferred 
> and non-deferred windlight shaders.
> 
> 
> This addresses bug OPEN-152.
> http://jira.secondlife.com/browse/OPEN-152
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN 
>   indra/newview/llviewershadermgr.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/611/diff/
> 
> 
> Testing
> ---
> 
> Tested with/without deferred rendering, with various sky presets.
> 
> 
> Screenshots
> ---
> 
> before/after comparisons
>   http://codereview.secondlife.com/r/611/s/1/
> 
> 
> 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

Re: [opensource-dev] Review Request: OPEN-152 Fog is broken on water, and extra-broken on water in deferred rendering

2013-01-11 Thread Geenz Spad 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/611/#review1291
---

Ship it!


Looks good to me.

- Geenz Spad


On Dec. 2, 2012, 2:53 a.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/611/
> ---
> 
> (Updated Dec. 2, 2012, 2:53 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Made deferred water use the atmospheric helper shader functions properly, 
> made fog calculation view-relative rather than absolute-position in deferred 
> and non-deferred windlight shaders.
> 
> 
> This addresses bug OPEN-152.
> http://jira.secondlife.com/browse/OPEN-152
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/waterF.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/waterV.glsl UNKNOWN 
>   indra/newview/app_settings/shaders/class1/environment/waterV.glsl UNKNOWN 
>   indra/newview/llviewershadermgr.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/611/diff/
> 
> 
> Testing
> ---
> 
> Tested with/without deferred rendering, with various sky presets.
> 
> 
> Screenshots
> ---
> 
> before/after comparisons
>   http://codereview.secondlife.com/r/611/s/1/
> 
> 
> 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

Re: [opensource-dev] Upcoming server side avatar baking

2013-01-11 Thread Henri Beauchamp 
On Wed, 9 Jan 2013 17:26:51 +0100, Henri Beauchamp wrote:

> The Linux viewer available for download from Sunshine's Wiki page has
> alas been compiled with a way too new glibc end refuse to run on my
> system (Mandriva 2010.2, glibc v2.11.1), aborting with:
> bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6:
> version `GLIBCXX_3.4.15' not found
> (required by bin/do-not-directly-run-secondlife-bin)
> 
> Could we please get a viewer compiled on the same build system as the one
> used for LL's other viewers ?
> 
> Thank you.
> 
> Henri.
> 
> PS: I'm currently testing a server-side baking compatible Cool VL Viewer
> and trying to figure out a COF version missmatch issue (which ressembles
> this one: https://jira.secondlife.com/browse/SUN-3) that could be due
> to the inventory issues on Aditi: without a known, working viewer to
> compare with, it's hard to figure out if it's a bug in my backport or
> a bug in Aditi's inventory server...

Nevermind (though, having a propely built Linux Sunshine-viewer would
still be a good thing), I figured out the bug (race condition between
links creation in COF and rebake requests).

The of the Cool VL Viewer v1.26.7.5  (experimental branch) has been
released today with server-side baking support.

Henri.
___
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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/settings.xml, line 7823
> > 
> >
> > 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?

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.


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl, line 
> > 214
> > 
> >
> > Where's the code where ssao_effect_mat had been constructed? (If it's 
> > not being used, it should probably be taken out too.)

It was being constructed in pipeline.cpp, and the patch includes removal of 
that part.


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 127
> > 
> >
> > 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)

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. :)


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 130
> > 
> >
> > 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)

I'm not sure I follow - but a sample candidate co-incident with the sample 
origin is disregarded.


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 132
> > 
> >
> > 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?)

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.


- Tofu


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/612/#review1288
---


On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/612/
> ---
> 
> (Updated Dec. 2, 2012, 3:49 a.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.  Also, improve comments a 
> bit. :3
> 
> 
> This addr

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Geenz Spad 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 127
> > 
> >
> > 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. :)

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?


- Geenz


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/612/#review1288
---


On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/612/
> ---
> 
> (Updated Dec. 2, 2012, 3:49 a.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.  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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/612/
---

(Updated Jan. 11, 2013, 1:16 p.m.)


Review request for Viewer.


Changes
---

Updated patch with a bunch more comments, made settings reflect what I've 
actually been testing with, reconciled class1 and class2 better, and added a 
new quality improvement (disregard samples which are being taken from outside 
the screen extents - eliminates spurious SSAO fringe at screen edges at some 
angles).


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.  Also, improve comments a 
bit. :3


This addresses bug VWR-29083.
http://jira.secondlife.com/browse/VWR-29083


Diffs (updated)
-

  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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 

---
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 (updated)
---

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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 127
> > 
> >
> > 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?

Added comments which explain diff.z != 0.0 somewhat!


- 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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 127
> > 
> >
> > 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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Tofu Buzzard 

---
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.


Changes
---

Bring shadow settings more (totally!) in line with what I was actually testing 
with.  At worst these reduce variance just for my benefit, at best (I hope) 
they are more finely-tuned for SL's current shadow shaders (given the landing 
of the ternary shadows).


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 (updated)
-

  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

[opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field

2013-01-11 Thread Tofu Buzzard 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/615/
---

Review request for Viewer.


Description
---

This turns on bilinear filtering of the composited screen buffer used as the 
colour source for the depth-of-field effect (and its downscaled version).
This simply means that we can get away with around half as many samples for the 
same quality of bokeh effect.  The samples we do take express the desired 
radius more accurately too, so there aren't such glaring delineations in 
blurredness.

To celebrate being about twice as fast, I've also upped the maximum fatness of 
the bokeh effect for situations of extreme defocus.  So typical cases are 
around twice as fast, and the extreme bokeh situation is around the previous 
speed but with fatter highlights.


This addresses bug OPEN-159.
http://jira.secondlife.com/browse/OPEN-159


Diffs
-

  indra/llrender/llpostprocess.cpp UNKNOWN 
  indra/newview/app_settings/settings.xml UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN 
  indra/newview/pipeline.cpp UNKNOWN 

Diff: http://codereview.secondlife.com/r/615/diff/


Testing
---

Been running like this for a while myself...


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

Re: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field

2013-01-11 Thread Tofu Buzzard 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/615/
---

(Updated Jan. 11, 2013, 2 p.m.)


Review request for Viewer.


Description
---

This turns on bilinear filtering of the composited screen buffer used as the 
colour source for the depth-of-field effect (and its downscaled version).
This simply means that we can get away with around half as many samples for the 
same quality of bokeh effect.  The samples we do take express the desired 
radius more accurately too, so there aren't such glaring delineations in 
blurredness.

To celebrate being about twice as fast, I've also upped the maximum fatness of 
the bokeh effect for situations of extreme defocus.  So typical cases are 
around twice as fast, and the extreme bokeh situation is around the previous 
speed but with fatter highlights.


This addresses bug OPEN-159.
http://jira.secondlife.com/browse/OPEN-159


Diffs
-

  indra/llrender/llpostprocess.cpp UNKNOWN 
  indra/newview/app_settings/settings.xml UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl UNKNOWN 
  indra/newview/pipeline.cpp UNKNOWN 

Diff: http://codereview.secondlife.com/r/615/diff/


Testing
---

Been running like this for a while myself...


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

Re: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field

2013-01-11 Thread Tofu Buzzard 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/615/#review1295
---



indra/llrender/llpostprocess.cpp


Ah, yes.  I added this assert to mark this function as broken because it 
ate some of my time just unobviously doing nothing.


- Tofu Buzzard


On Jan. 11, 2013, 2 p.m., Tofu Buzzard wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/615/
> ---
> 
> (Updated Jan. 11, 2013, 2 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> This turns on bilinear filtering of the composited screen buffer used as the 
> colour source for the depth-of-field effect (and its downscaled version).
> This simply means that we can get away with around half as many samples for 
> the same quality of bokeh effect.  The samples we do take express the desired 
> radius more accurately too, so there aren't such glaring delineations in 
> blurredness.
> 
> To celebrate being about twice as fast, I've also upped the maximum fatness 
> of the bokeh effect for situations of extreme defocus.  So typical cases are 
> around twice as fast, and the extreme bokeh situation is around the previous 
> speed but with fatter highlights.
> 
> 
> This addresses bug OPEN-159.
> http://jira.secondlife.com/browse/OPEN-159
> 
> 
> Diffs
> -
> 
>   indra/llrender/llpostprocess.cpp UNKNOWN 
>   indra/newview/app_settings/settings.xml UNKNOWN 
>   indra/newview/app_settings/shaders/class1/deferred/postDeferredF.glsl 
> UNKNOWN 
>   indra/newview/pipeline.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/615/diff/
> 
> 
> Testing
> ---
> 
> Been running like this for a while myself...
> 
> 
> 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

Re: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field

2013-01-11 Thread Monty Brandenberg 
On 1/11/2013 5:03 PM, Tofu Buzzard wrote:

>   llassert_always(false);
>
> Ah, yes.  I added this assert to mark this function as broken because it ate 
> some of my time just unobviously doing nothing.

http://catb.org/jargon/html/magic-story.html

___
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

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Celierra Darling 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/settings.xml, line 7823
> > 
> >
> > 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
> > 
> >
> > 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
> > 
> >
> > 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
> > 
> >
> > 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 t

Re: [opensource-dev] Review Request: VWR-29083 Make SSAO work better

2013-01-11 Thread Celierra Darling 


> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote:
> > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line 
> > 132
> > 
> >
> > 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.
> 
> Celierra Darling wrote:
> 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?)

Er, to be clearer, the old presumption was that ambient light would be falling 
onto the sample origin equally from all directions if not for the occluders 
that were sampled - thus no use of angrel.  In hindsight, that seems a little 
dumb - to me, the way you're doing it is like using a better prior in the 
Bayesian sense.


- 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

Re: [opensource-dev] Upcoming server side avatar baking

2013-01-11 Thread Latif Khalifa 
On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp  wrote:
> Nevermind (though, having a propely built Linux Sunshine-viewer would
> still be a good thing), I figured out the bug (race condition between
> links creation in COF and rebake requests).

How do you work around that? When I was implementing this in Radegast
it seemed that the service would respond to link creation request and
it would still sometimes fail with COF mismatch as if the baking
service didn't get the message.

> The of the Cool VL Viewer v1.26.7.5  (experimental branch) has been
> released today with server-side baking support.

Great!
___
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