from:"Geenz Spad"

Re: [opensource-dev] Mesh support current status???

2011-04-17 Thread Geenz Spad

I think you're referring to their announcement that they were shifting focus
to iOS, not MacOS.  They have never announced Mac support for Blue Mars, and
they still support the PC all the same.

On Sun, Apr 17, 2011 at 11:59 AM, Brandon Husbands  wrote:

> There was an announcement t hey wold only be supporting mac a few months
> ago.
>
>
> On Sun, Apr 17, 2011 at 11:50 AM, Laurent Bechir <
> laurent.bec...@madonie.org> wrote:
>
>>
>> Le 17 avr. 2011 à 17:05, Brandon Husbands a écrit :
>>
>> > as soon as blue mars decided to go mac only the mesh project went into
>> hibernation..
>> > No more competition... so no need for it to progress..
>>
>> Where have you eard that Blue Mars would work on Mac ? I see nothing on
>> their website.
>>
>> ___
>> 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
>>
>
>
>
> --
>
> ---
> This email is a private and confidential communication. Any use of email
> may be subject to the laws and regulations of the United States. You may not
> Repost, Distribute nor reproduce any content of this message.
>
> ---
>
> ---
>
> ___
> 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
>
___
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] ATI vs NV vs OSX

2011-05-11 Thread Geenz Spad

Everything (including shadows and deferred rendering) seems to work under
the latest version of OS X (10.6.7 here).  It also works under the latest
10.7 developer preview.  I'm using a GeForce GTX 285 on my end.

On Wed, May 11, 2011 at 10:57 AM, Mysty Saunders
wrote:

> Every time I've tried a hackntosh build I couldn't get sl to open getting
> an error of "Could not create opengl context window". That was with Nvidia
> 9800gtx+ and gtx285 with 10.5.x havent tried 10.6 yet.
>
>
>
> On Wed, May 11, 2011 at 7:18 AM, Francesco "Sythos" wrote:
>
>> Oh, my fault, i mean full HW support, tweaking via software there are some
>> way, but the performance loss is sensible...
>>
>> --
>> Sent by iPhone
>>
>> Il giorno 11/mag/2011, alle ore 11:38, "Francesco \"Sythos\"" <
>> syt...@gmail.com> ha scritto:
>>
>> On snow Leopard no
>>
>> --
>> Sent by iPhone
>>
>> Il giorno 11/mag/2011, alle ore 10:13, Marc Adored
>>  ha scritto:
>>
>> So does that mean no shadows no matter the card in osx?
>>
>>
>> On Wed, May 11, 2011 at 3:57 AM, Francesco "Sythos" 
>> wrote:
>>
>> Lion (next macosx release) have OpenGL upgraded from 2.1 to 3.1 and
>>
>> Apple have enabled GL_ARB_shadow &C. (already in 2.1 but disabled for
>>
>> Apple decision), this mean by *theory* all OpenGL glsl can work on Mac
>>
>> too (imho, never checked deeply inside glsl of the viewer)
>>
>>
>> --
>>
>> Sent by iPhone
>>
>>
>> Il giorno 11/mag/2011, alle ore 09:20, Marc Adored
>>
>>  ha scritto:
>>
>>
>> So I am building a machine we shall call it a haxintosh... It will be
>>
>> running OSX I was just wondering if ATI or Nvidia was better supported
>>
>> for SecondLife on OSX? I know OSX chose ATI for there machines but
>>
>> does SL support it or would I be better off to get Nvidia anyways? I
>>
>>  really want everything shadows lighting all that. Ive seen issues on
>>
>> OSX for some people but I dont know if its ATI or SL's problems with
>>
>> the os directly. I know this is the opensource dev list but I figured
>>
>> you guys would know this stuff better then anyone being in the
>>
>> trenches and all :P
>>
>> ___
>>
>> 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
>>
>>
>> ___
>> 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
>>
>>
>> ___
>> 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
>>
>
>
> ___
> 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
>
___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-21 Thread Geenz Spad


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

Review request for Viewer.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs
-

  indra/newview/app_settings/settings.xml 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/settings.xml 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  doc/contributions.txt 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/llviewercontrol.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.h 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 

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


Testing
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-21 Thread Geenz Spad


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

(Updated March 21, 2012, 10:42 a.m.)


Review request for Viewer.


Changes
---

Added a link to the latest builds of these changes.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs
-

  indra/newview/app_settings/settings.xml 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/settings.xml 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  doc/contributions.txt 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/llviewercontrol.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.h 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 
  indra/newview/pipeline.cpp 51b2fd52e36aab8f670e0874e7e1472434ec4b4a 

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


Testing (updated)
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-21 Thread Geenz Spad


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

(Updated March 21, 2012, 1:01 p.m.)


Review request for Viewer.


Changes
---

Updated the diff to generally be cleaner, consolidating all changes into a 
single diff.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs (updated)
-

  doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/settings.xml 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 

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


Testing
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-25 Thread Geenz Spad


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

(Updated March 25, 2012, 2:07 p.m.)


Review request for Viewer and David Parks.


Changes
---

Added more information as to why we multiply in our shaders, and why we're 
scaling our results by (1.f / 6) in our LUT creation.
Also renamed handleReleaseLUTBufferChanged to handleLUTBufferChanged, per 
Tofu's request.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs (updated)
-

  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 

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


Testing
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-25 Thread Geenz Spad



> On March 25, 2012, 2:55 a.m., Tofu Buzzard wrote:
> > I'd like to see the mis-named handleReleaseLUTBufferChanged be called 
> > handleLUTBufferChanged, and ideally I'd like some comment (probably in the 
> > LUT creation) about why the results of lookups should be multiplied by 4 
> > (to avoid saturation in the LUT?).
> > Otherwise, I reckon this is great.
> 
> Oz Linden wrote:
> I concur with both of these comments, and have asked for a review from 
> Dave.

The reasoning for doing this is basically just as you said, to avoid saturation 
in the LUT since most energy conserving specular models tend to exceed a 
floating point range of 0 to 1, something that should be accounted for when 
storing the results in an R8 LUT.
Granted, one could just use a floating point LUT instead, but driver support 
can be a bit spotty for R16F and R32F.  However, storing in an R16F LUT is 
something to look into in the future regardless if only to reduce banding.
Scaling by 6 allows us to get a bit more of a higher range (same scale used by 
RGBM encoding), though whether or not it's really necessary is something 
potentially worth investigating.


- Geenz


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


On March 25, 2012, 2:07 p.m., Geenz Spad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/565/
> ---
> 
> (Updated March 25, 2012, 2:07 p.m.)
> 
> 
> Review request for Viewer and David Parks.
> 
> 
> Description
> ---
> 
> For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
> looking specular model, as opposed to other platforms which try to go for 
> more physically accurate looking models, such as blinn-phong and similar.
> 
> This feature changes the specular model to a technique called normalized 
> blinn-phong. The specular model applies the usual blinn-phong term (assume 
> NdotV to the power of n), multiplied by a normalization function of:
> ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
> Where n is the specular exponent.
> 
> Gamma correction is also applied to the result to bring the visual results 
> more in line with what you see in high end game engines such as Unreal Engine 
> 3 and Frostbite 2, and stored in a lookup texture.
> 
> Test plan can be found in the JIRA.
> Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp
> 
> 
> This addresses bug STORM-1823.
> http://jira.secondlife.com/browse/STORM-1823
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
> 
> Diff: http://codereview.secondlife.com/r/565/diff/diff
> 
> 
> Testing
> ---
> 
> * Tested performance characteristics - both Normalized Blinn-Phong and the 
> previous model seem to have the same performance
> * Checked the perceived "brightness" of the new highlights vs. the old ones - 
> new ones seem much brighter at higher shiny values than the old ones, and 
> seem much less "cartoonish" as such
> * Checked the impact on different bumpiness values at the test rig at Hippo 
> Hollow - noticeable visual improvement across all objects (though low shiny 
> seems to have a much more subtle light reflectance term - this is expected 
> for normalized blinn-phong)
> * Tested different LUT resolutions - best looking seems to be 512x128 with 
> seemingly no measurable decrease in performance
> 
> You can find the latest build here: 
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html
> 
> 
> Thanks,
> 
> Geenz Spad
> 
>

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-25 Thread Geenz Spad



> On March 25, 2012, 2:56 p.m., Argent Stonecutter wrote:
> > Could we see some examples of SL scenes using the two models, particularly 
> > with avatars in them, because there have been a number of changes to the SL 
> > renderer over the years... and the main effect of increasing the "realism" 
> > of the renderer has been to throw the deficiencies of the SL avatar mesh 
> > into sharp relief. The current specular model was a deliberate compromise 
> > between the older even-toonier renderer and a more "realistic" model that 
> > made avatars look horrible.

Avatars are only ever effected if they're using attachments that make sure of 
the shiny attribute.

The diffuse shading on avatars remains unaffected.  I think the "compromise" 
you're thinking of is the environment map that typically gets applied in 
classic forward rendering, which was later re-added to the deferred renderer to 
mitigate content breakage that resulted when it was removed, which hasn't been 
changed with my modifications.

As I had mentioned previously, there are comparison pictures posted on the JIRA 
that everyone can see, and I would also very much appreciate it if people could 
post their own comparisons, and identify any in-world content breakage that 
relied on the previous model that was used.


- Geenz


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


On March 25, 2012, 2:07 p.m., Geenz Spad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/565/
> ---
> 
> (Updated March 25, 2012, 2:07 p.m.)
> 
> 
> Review request for Viewer and David Parks.
> 
> 
> Description
> ---
> 
> For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
> looking specular model, as opposed to other platforms which try to go for 
> more physically accurate looking models, such as blinn-phong and similar.
> 
> This feature changes the specular model to a technique called normalized 
> blinn-phong. The specular model applies the usual blinn-phong term (assume 
> NdotV to the power of n), multiplied by a normalization function of:
> ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
> Where n is the specular exponent.
> 
> Gamma correction is also applied to the result to bring the visual results 
> more in line with what you see in high end game engines such as Unreal Engine 
> 3 and Frostbite 2, and stored in a lookup texture.
> 
> Test plan can be found in the JIRA.
> Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp
> 
> 
> This addresses bug STORM-1823.
> http://jira.secondlife.com/browse/STORM-1823
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
> 
> Diff: http://codereview.secondlife.com/r/565/diff/diff
> 
> 
> Testing
> ---
> 
> * Tested performance characteristics - both Normalized Blinn-Phong and the 
> previous model seem to have the same performance
> * Checked the perceived "brightness" of the new highlights vs. the old ones - 
> new ones seem much brighter at higher shiny values than the old ones, and 
> seem much less "cartoonish" as such
> * Checked the impact on different bumpiness values at the test rig at Hippo 
> Hollow - noticeable visual improvement across all objects (though low shiny 
> seems to have a much more subtle light reflectance term - this is expected 
> for normalized blinn-phong)
> * Tested different LUT resolutions - best looking seems to be 512x128 with 
> seemingly no measurable decrease in performance
> 
> You can find the latest build here: 
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html
> 
> 
> Thanks,
> 
> Geenz Spad
> 
>

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-25 Thread Geenz Spad



> On March 25, 2012, 3:39 p.m., Tofu Buzzard wrote:
> > 4 -> 6 is a bit of a last-minute change... :3  But ship it.

Mostly just using an idea I got from reading up on RGBM encoding, and why they 
scale by 6 as well (though really, in theory you could scale by pretty much any 
value so long as both the encode and decode use the same scales).  Seems to 
work quite well, especially since medium shiny seems to have slightly less 
saturation induced artifacting. :3


- Geenz


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


On March 25, 2012, 2:07 p.m., Geenz Spad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/565/
> ---
> 
> (Updated March 25, 2012, 2:07 p.m.)
> 
> 
> Review request for Viewer and David Parks.
> 
> 
> Description
> ---
> 
> For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
> looking specular model, as opposed to other platforms which try to go for 
> more physically accurate looking models, such as blinn-phong and similar.
> 
> This feature changes the specular model to a technique called normalized 
> blinn-phong. The specular model applies the usual blinn-phong term (assume 
> NdotV to the power of n), multiplied by a normalization function of:
> ((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
> Where n is the specular exponent.
> 
> Gamma correction is also applied to the result to bring the visual results 
> more in line with what you see in high end game engines such as Unreal Engine 
> 3 and Frostbite 2, and stored in a lookup texture.
> 
> Test plan can be found in the JIRA.
> Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp
> 
> 
> This addresses bug STORM-1823.
> http://jira.secondlife.com/browse/STORM-1823
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
> b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
>   indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
> 
> Diff: http://codereview.secondlife.com/r/565/diff/diff
> 
> 
> Testing
> ---
> 
> * Tested performance characteristics - both Normalized Blinn-Phong and the 
> previous model seem to have the same performance
> * Checked the perceived "brightness" of the new highlights vs. the old ones - 
> new ones seem much brighter at higher shiny values than the old ones, and 
> seem much less "cartoonish" as such
> * Checked the impact on different bumpiness values at the test rig at Hippo 
> Hollow - noticeable visual improvement across all objects (though low shiny 
> seems to have a much more subtle light reflectance term - this is expected 
> for normalized blinn-phong)
> * Tested different LUT resolutions - best looking seems to be 512x128 with 
> seemingly no measurable decrease in performance
> 
> You can find the latest build here: 
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html
> 
> 
> Thanks,
> 
> Geenz Spad
> 
>

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-26 Thread Geenz Spad


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

(Updated March 26, 2012, 10:46 a.m.)


Review request for Viewer and David Parks.


Changes
---

Added the change that Oz requested, also updated contributions.txt while I was 
at it.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs (updated)
-

  doc/contributions.txt b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/settings.xml 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl 
b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/llviewercontrol.cpp b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/pipeline.h b32595c5170f92ac2dbab635955b1b86634f1475 
  indra/newview/pipeline.cpp b32595c5170f92ac2dbab635955b1b86634f1475 

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


Testing
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-26 Thread Geenz Spad


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

(Updated March 26, 2012, 5:24 p.m.)


Review request for Viewer and David Parks.


Changes
---

Reduce the overall glow amount from the sun to a quarter of its original 
strength.  This helps prevent specular highlights with glow applied from being 
too bright when compared to the previous specular model.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs (updated)
-

  doc/contributions.txt UNKNOWN 
  indra/newview/app_settings/settings.xml UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN 
  indra/newview/llviewercontrol.cpp UNKNOWN 
  indra/newview/pipeline.h UNKNOWN 
  indra/newview/pipeline.cpp UNKNOWN 

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


Testing
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/rev/251711/index.html


Thanks,

Geenz Spad

___
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: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

2012-03-27 Thread Geenz Spad


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

(Updated March 27, 2012, 9:54 a.m.)


Review request for Viewer and David Parks.


Changes
---

Updated build link.


Description
---

For a while now, Second Life's deferred renderer has had a somewhat "toonish" 
looking specular model, as opposed to other platforms which try to go for more 
physically accurate looking models, such as blinn-phong and similar.

This feature changes the specular model to a technique called normalized 
blinn-phong. The specular model applies the usual blinn-phong term (assume 
NdotV to the power of n), multiplied by a normalization function of:
((n + 2) * (n + 4)) / (8 * PI * (powf(2, -n/2) + n))
Where n is the specular exponent.

Gamma correction is also applied to the result to bring the visual results more 
in line with what you see in high end game engines such as Unreal Engine 3 and 
Frostbite 2, and stored in a lookup texture.

Test plan can be found in the JIRA.
Repository can be found here: https://bitbucket.org/Geenz/viewer-nbp


This addresses bug STORM-1823.
http://jira.secondlife.com/browse/STORM-1823


Diffs
-

  doc/contributions.txt UNKNOWN 
  indra/newview/app_settings/settings.xml UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/multiPointLightF.glsl 
UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/pointLightF.glsl UNKNOWN 
  indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl UNKNOWN 
  indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl UNKNOWN 
  indra/newview/llviewercontrol.cpp UNKNOWN 
  indra/newview/pipeline.h UNKNOWN 
  indra/newview/pipeline.cpp UNKNOWN 

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


Testing (updated)
---

* Tested performance characteristics - both Normalized Blinn-Phong and the 
previous model seem to have the same performance
* Checked the perceived "brightness" of the new highlights vs. the old ones - 
new ones seem much brighter at higher shiny values than the old ones, and seem 
much less "cartoonish" as such
* Checked the impact on different bumpiness values at the test rig at Hippo 
Hollow - noticeable visual improvement across all objects (though low shiny 
seems to have a much more subtle light reflectance term - this is expected for 
normalized blinn-phong)
* Tested different LUT resolutions - best looking seems to be 512x128 with 
seemingly no measurable decrease in performance

You can find the latest build here: 
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-8/latest.html


Thanks,

Geenz Spad

___
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: STORM-1819: Graded Shadows

2012-04-22 Thread Geenz Spad


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


How does the performance look with this on some older hardware (i.e., GeForce 8 
an 9 series)?

- Geenz Spad


On April 21, 2012, 2:54 p.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/577/
> ---
> 
> (Updated April 21, 2012, 2:54 p.m.)
> 
> 
> Review request for Viewer and David Parks.
> 
> 
> Description
> ---
> 
> Posted for Tofu Buzzard.
> 
> Translucent objects case lower-density shadows.
> 
> 
> This addresses bug STORM-1819.
> http://jira.secondlife.com/browse/STORM-1819
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt f7ff29ea84ed 
>   indra/llrender/llshadermgr.h f7ff29ea84ed 
>   indra/llrender/llshadermgr.cpp f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class1/deferred/shadowAlphaMaskF.glsl 
> f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class1/deferred/shadowAlphaMaskV.glsl 
> f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class2/deferred/alphaF.glsl f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class2/deferred/alphaNonIndexedF.glsl 
> f7ff29ea84ed 
>   
> indra/newview/app_settings/shaders/class2/deferred/alphaNonIndexedNoColorF.glsl
>  f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class2/deferred/sunLightF.glsl 
> f7ff29ea84ed 
>   indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl 
> f7ff29ea84ed 
>   indra/newview/pipeline.h f7ff29ea84ed 
>   indra/newview/pipeline.cpp f7ff29ea84ed 
> 
> Diff: http://codereview.secondlife.com/r/577/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Oz Linden
> 
>

___
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] Autobuild hell

2012-05-22 Thread Geenz Spad

So, in the process of setting up a new build environment on OS X, I seem to 
have come across a little problem that I've never encountered before with 
regards to setting up autobuild. 

Assuming I've added autobuild to my PATH variable, I always tend to get the 
following error regardless of where autobuild is executed (i.e., whether it's a 
directory containing proper autobuild packages or not), and the parameters 
given to it (such as build, clean, etc.):

Geenzs-MacBook-Pro:~ geenz$ autobuild
WARNING:autobuild.common:extracting from llbase-0.2.0-darwin-20100225.tar.bz2
Traceback (most recent call last):
  File "/Users/geenz/Devel/autobuild/bin/autobuild", line 38, in 
from autobuild import autobuild_main
  File "/Users/geenz/Devel/autobuild/autobuild/autobuild_main.py", line 25, in 

import common
  File "/Users/geenz/Devel/autobuild/autobuild/common.py", line 647, in 
Bootstrap()
  File "/Users/geenz/Devel/autobuild/autobuild/common.py", line 642, in __init__
raise AutobuildError("invalid 'pathcheck' setting for '%s'" % name)
autobuild.common.AutobuildError: invalid 'pathcheck' setting for 'llbase'


The same error crops up regardless of python version.  Any ideas on what's 
causing this, and how it can be fixed?  First glance seems to suggest that it's 
attempting to extract things from an archive that may not even exist.
-- 
Geenz Spad
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

___
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] Anyone else having this issue uploading meshes?

2012-06-03 Thread Geenz Spad

Have you attempted this on both pathfinding and non-pathfinding regions?  Seems 
to manifest primarily on pathfinding regions for me. 

-- 
Geenz Spad
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Sunday, June 3, 2012 at 4:08 PM, Ricky wrote:

> Interesting hypothesis.  However, I've now attempted this on both a Friday 
> and a Sunday with the same results. :)  Also, as the status code is an HTTP 
> 500 "Internal Server Error" instead of, for instance, SH-3055's 408 "Request 
> Timeout" I'm leaning more towards a bug in the server than a timing issue - 
> though it's certainly possible that the latter could induce the former!
> 
> Thanks for the response!
> Ricky
> Cron Stardust
> 
> On Sun, Jun 3, 2012 at 12:47 PM, Nicky Perian  (mailto:nickyper...@yahoo.com)> wrote:
> > I have an unproven theory. It is Sunday with lots of stau on the inet. Now 
> > to my theory. Let's you have your data *.dae files on a network drive or 
> > worse yet in dropbox folder. The write back of the *.slm file is now taking 
> > a bit longer because of inet traffic and the normal latency for obtaining 
> > file locks and the LAN overhead involved of obtaining exclusive control of 
> > the file open, lock, write, unlock and close processes.  
> > 
> > I had this failure on aditi a couple Sundays ago, next morning and after 
> > moving the files to the *.dae local file system everything worked fine 
> > using the same exact files. 
> > 
> > However, I was using an hacd library in the system.
> >  
> > 
> > > From: Ricky mailto:kf6...@gmail.com)>
> > > To: opensource-dev@lists.secondlife.com 
> > > (mailto:opensource-dev@lists.secondlife.com) 
> > > Sent: Sunday, June 3, 2012 12:43 PM
> > > Subject: [opensource-dev] Anyone else having this issue uploading meshes?
> > > 
> > > Just a ping to see if the problem is limited to my combination of viewer 
> > > and mesh. The error pops up as a floater when I press "Calculate Weights 
> > > & Fees" and states the following:
> > > > Mesh failed to upload: Unable to upload asset.
> > > > Upload_ServerError
> > > > 
> > > > See the log file for details.
> > > 
> > > The log shows the following:
> > > > 2012-06-03T17:07:08Z WARNING: completed: fee request failed
> > > > 
> > > > 2012-06-03T17:07:08Z WARNING: log_upload_error: stage: fee http status: 
> > > > 500
> > > > 
> > > > 2012-06-03T17:07:08Z WARNING: log_upload_error: err: 
> > > > {'identifier':'Upload_ServerError','message':'Unable to upload asset.'}
> > > > 
> > > > 2012-06-03T17:07:08Z WARNING: log_upload_error: mesh upload failed, 
> > > > stage 'fee' error '', message 'Unable to upload asset.', id 
> > > > 'Upload_ServerError'
> > > > 
> > > > 2012-06-03T17:07:08Z WARNING: setModelPhysicsFeeErrorStatus: 
> > > > LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(500 : )
> > > > 
> > > > 2012-06-03T17:07:08Z WARNING: LLToastAlertPanel::LLToastAlertPanel: 
> > > > Alert: Mesh failed to upload: Unable to upload asset. 
> > > > Upload_ServerError 
> > > > 
> > > 
> > > 
> > > If you can or cannot repo, let me know at 
> > > https://jira.secondlife.com/browse/SVC-7978 or via private email, thanks! 
> > > 
> > > Ricky
> > > Cron Stardust
> > > 
> > > PS: I've tested with multiple viewers, using 3.3.1, 3.3.2, and 
> > > 3.3.4.258391 vintages, involving Pathfinding, viewer-dev, and release - 
> > > all show the error.  So I think it's either a serverside issue, or a 
> > > problem with my mesh - though why a mesh would cause a 500 Internal 
> > > Server Error response 
> > > 
> > > PPS: As an aside, the latest VD I tried 
> > > (http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/integration_viewer-development/rev/258391/index.html
> > >  ) crashed on login on Mac OSX Lion, but seems to run on Snow Leopard. 
> > > ___
> > > 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
> > > 
> 
> ___
> 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
> 
> 


___
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] Anyone else having this issue uploading meshes?

2012-06-04 Thread Geenz Spad

I'm doubt that it has anything to do with convex decomposition, not unless they 
recently changed the format in which the server expects the hulls.  Though even 
if they did, I'd think they'd include those changes as part of the pathfinding 
viewer. 

-- 
Geenz Spad
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Monday, June 4, 2012 at 8:14 AM, Nicky Perian wrote:

> Would opensim server logs be of value?
> 
> > From: Nicky D.  > (mailto:sl.nicky...@googlemail.com)>
> > To: Nicky Perian mailto:nickyper...@yahoo.com)> 
> > Cc: Ricky mailto:kf6...@gmail.com)>; 
> > "opensource-dev@lists.secondlife.com 
> > (mailto:opensource-dev@lists.secondlife.com)" 
> >  > (mailto:opensource-dev@lists.secondlife.com)> 
> > Sent: Monday, June 4, 2012 6:26 AM
> > Subject: Re: [opensource-dev] Anyone else having this issue uploading 
> > meshes?
> > 
> > On Sun, Jun 3, 2012 at 9:47 PM, Nicky Perian  > (mailto:nickyper...@yahoo.com)> wrote:
> > > I have an unproven theory. It is Sunday with lots of stau on the inet. Now
> > > to my theory. Let's you have your data *.dae files on a network drive or
> > > worse yet in dropbox folder. The write back of the *.slm file is now 
> > > taking
> > > a bit longer because of inet traffic and the normal latency for obtaining
> > > file locks and the LAN overhead involved of obtaining exclusive control of
> > > the file open, lock, write, unlock and close processes.
> > >
> > 
> > It does not matter if your file is on DropBox, your HDD or a floppy disk.
> > The dae loading takes places long before even any communication with the
> > server takes places. Writing the slm is done before the hulls etc are 
> > uploaded.
> > Even if the slm writing has higher latency in some cases, it won't influence
> > neither decoding nor upload.
> > 
> > For the real cause, and to know why sometimes client and server disagree
> > if a convex decomposition is valid we would need to have access to the 
> > server
> > (logs). Sometimes I am sure won't happen anytime soon :)
> > 
> > Regards,
> >   Nicky
> > 
> > 
> ___
> 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
> 
> 


___
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] Content Creation Improvement UG - Morph Target Discussion

2012-07-16 Thread Geenz Spad

Hello everyone!

Recently at the Content Creation Improvement meetings, we've been discussing 
morph targets and what they would mean for content creators on the grid.  Thus 
far the conversation's focused on how this could benefit clothing designers; 
e.g., what level of control would this give them, and why it would be 
beneficial for them to have this feature.

Thus far, there hasn't been too much developer feedback on the feature.  Siana 
Gearz has of course posted some possibilities in the comments on 
http://blog.nalates.net/2012/07/10/the-consensus/, and does have a valid point 
that there are some technical hurdles that will need to be overcome with 
whatever approach that is taken.

Before I get into what should be discussed, a little definition of what a morph 
target is:
A morph target, also known as a blend shape or shape key in some 3D modeling 
packages, is something that defines how the surface of an object should 
"deform" when a value is applied.  You could say that the Second Life avatar 
mesh makes use of morph targets to define the overall shape of an avatar as an 
example of a morph target.  Video games now days tend to use them to define 
facial animation, and other animated properties that would just be far too 
difficult to animate using bones.  In this context, we're primarily looking at 
them to define how rigged meshes deform, however, that being said, other 
general applications being discussed wouldn't be bad either.  But please focus 
on how we can improve clothing design with such a feature as a primary goal, 
with other applications being a secondary goal.

I'm extending the discussion to the open source dev mailing list, in the hopes 
to get more developer discussion going on the matter.

Currently, there are a few things that need to be established through these 
discussions:
• What can morph targets do that existing tools can't (Qarl's deformer included)
• What problems can they solve that existing tools can't, or otherwise are 
difficult to solve with existing tools (Qarl's deformer included)
• What can they generally be used for, from various view points
• Ways they can be implemented
• Ways the bandwidth cost can be mitigated for those implementations

Just as a note with regards to Qarl's deformer, and where this may eventually 
go:
Qarl's deformer comes first.  Thus far, it is the closest solution to making 
mesh clothing fit better, and it requires very little work on the content 
creator's behalf outside of modeling around the default "Ruth" shape.  As such, 
morph targets are not intended to be a competitor to the mesh deformer, it's 
intended moreso to complement what the mesh deformer is capable of doing as a 
more advanced toolset in the context of clothing.

Qarl's deformer has the highest likelihood of being released before the end of 
the year in a final form, and morph targets may not even be seriously 
considered by the lab until sometime next year.  On top of that, having both 
would have benefits for content creators; some content creators may not want to 
learn how to use morph targets and are content with modeling clothing around 
Ruth, and many may want to learn how to use morph targets "later on" while they 
focus on more immediate results in the interim with the intention of further 
customizing how their clothing deforms later.  So really, this should be seen 
as more of an advanced tool for content creators that wish to have further 
control over the final outcome of the clothing they design.

These discussions will be brought up at the CCI meetings over the coming weeks, 
and it's my hope to see more developers who participate on the list pop in and 
contribute things to the meetings, or even just sit in and watch the 
discussion, as I'm sure there's other things being discussed that would be of 
interest to developers being brought up at the meetings.

An additional note is necessary here: these discussions are informal.  Because 
we discuss this, does not mean it will be implemented by the lab.  However, we 
can organize things in such a way to produce a proposal to the lab, and 
(eventually) prototypes for consideration with LL's permission once a clear 
vision has been established for the feature, and its associated goals.  From 
there, it'll be up to LL to decide if a feature is worth having, and allotting 
the resources to make these things possible as needed on their side potentially 
with open source developers contributing to the final viewer that will make use 
of these features.  The hope is, this will increase the chances of new 
functionality and other improvements regarding content creation being added to 
Second Life.

You can find the agenda for the meetings, and other information relating to 
them, here:
https://wiki.secondlife.com/w/index.php?title=Content_Creation_Improvement_Informal_User_Group

[opensource-dev] Review Request: As Gatekeeper, I like binaries downloaded through a web browser to be signed

2012-07-23 Thread Geenz Spad


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

Review request for Viewer.


Description
---

OS X 10.8 brings with it a new feature named "Gatekeeper" that checks 
downloaded applications obtained through popular web browsers for an Apple 
issued Developer ID certificate.  If an application was not signed with one of 
these certificates, then Gatekeeper will prevent its execution.

Test plan is on the JIRA.


This addresses bug STORM-1900.
https://jira.secondlife.com/browse/STORM-1900


Diffs
-

  doc/contributions.txt 4d9106153407f9228f426091f3e84061dbd837ed 
  indra/cmake/Variables.cmake 4d9106153407f9228f426091f3e84061dbd837ed 
  indra/lib/python/indra/util/llmanifest.py 
4d9106153407f9228f426091f3e84061dbd837ed 
  indra/newview/CMakeLists.txt 4d9106153407f9228f426091f3e84061dbd837ed 
  indra/newview/viewer_manifest.py 4d9106153407f9228f426091f3e84061dbd837ed 

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


Testing
---

I've already tested to ensure that the viewer builds with these changes in 
place, and the resulting .app package executes without problems on OS X 10.8 
when downloaded through Safari.


Thanks,

Geenz Spad

___
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] Mercurial repository webpage layout

2012-08-29 Thread Geenz Spad

That's bitbucket in general.  Everyone's profile pages got switched to the new 
layout.

======
Geenz Spad
ge...@exodusviewer.com




On Aug 29, 2012, at 5:03 PM, Henri Beauchamp  wrote:

> Greetings,
> 
> The layout of LL's mercurial repository (http://hg.secondlife.com/)
> recently changed, and for the worst... The old layout allowed to see
> with a single glance what/when things last changed in each repository
> (the list on the right gave the last change's date), while now you
> must click on *each* repository link in the short list to open the
> commits page and see whether anything changed or not (the "recent
> activity" on the left not reflecting commits activity at all).
> 
> Could this annoying layout be reverted back to the good old one,
> please ?...
> 
> Every minute lost browsing pages for nothing is not spend coding and
> is lost time...
> 
> Regards,
> 
> 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

___
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] OSX 10.8 / Xcode 4.5 compile support (wasReview Request: patch potential memory leak in llgl.h)

2012-09-19 Thread Geenz Spad

It's possible that they're building with an older version of Xcode that still 
supported the 10.6 SDK that doesn't do a version check under 10.8.  There's 
also a method to install Xcode 3.2.6 and compile with autobuild using it.  To 
successfully compile with Xcode 4.5, you pretty much need to rewrite certain 
portions of the viewer to not use deprecated functionality and to instead have 
Objective-C implementations of different things (i.e., windowing and event 
handling); that's not an easy task (and in fact quite time consuming).

==
Geenz Spad
ge...@exodusviewer.com

On Sep 19, 2012, at 5:39 PM, Arrehn Oberlander  wrote:

> On Wed, Sep 19, 2012 at 11:58 AM, gistya eusebio  wrote:
>> 
>> I did compile this with OS X 10.8 as a build target successfully.
>> 
> 
> 
> I couldn't help but notice this blurb at the end. Did you need to make
> any adjustments to base viewer-dev dependent packages / cmake /. other
> in order to build with XCode 4.5.x?
> ___
> 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

___
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] OSX 10.8 / Xcode 4.5 compile support (wasReview Request: patch potential memory leak in llgl.h)

2012-09-20 Thread Geenz Spad

The patch still uses Carbon functionality that could be removed in an SDK 
update, just functionality that hasn't been removed as of yet (creating HIViews 
that use Cocoa views, for example).  So while it works now, there's no 
guarantee that it'll work under the next OS X version, which is likely due out 
next year now that Apple's committed to annual OS X updates.

I'd be interested to hear about the legacy OpenGL hacks that you're trying to 
remove however!  That part I find fairly interesting.

==
Geenz Spad
ge...@exodusviewer.com




On Sep 20, 2012, at 3:06 AM, gistya gmail  wrote:

> On Sep 19, 2012, at 2:39 PM, Arrehn Oberlander  wrote:
>> I couldn't help but notice this blurb at the end. Did you need to make
>> any adjustments to base viewer-dev dependent packages / cmake /. other
>> in order to build with XCode 4.5.x?
> 
> I found this diff to patch llWindow to compile with a 10.7 or 10.8 target:
> http://paste.kathar.in/raw/107/
> That fixes all the deprecated stuff in llWindow :D
> 
> Meanwhile in the indra/cmake/Variables.cmake of course, change the 
> CMAKE_OSX_DEPLOYMENT_TARGET to 10.8 and the SDK root has to be 
> /Applications/Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
> 
> As for media_plugin_quicktime, I don't have a patch to make it compile with 
> 10.8 target. Instead you download the 10.6 SDK here:
> http://www.jamesgeorge.org/uploads/MacOSX10.6.sdk.zip
> Then install that into:
> /Applications/Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk
> Then in Xcode, set the deployment target and the SDK for 
> media_plugin_quicktime to be 10.6 (rest of project remains 10.8). You must 
> also use LLVM compiler for media_plugin_quicktime, although the rest of the 
> project remains GCC for the compiler. 
> 
> I also got warnings about a broken linker flag in several media_plugin_XXX 
> targets, which simply involved editing the flags: I had to put quotation 
> marks around the text of the bad flag, and fix a carriage return that had 
> snuck in there, by combining two lines into one removing the return. 
> 
> There was also a build error because saying media_plugin_base.exp could not 
> be found; that's just because the path was wrong, which I was able to edit 
> also in Xcode to the correct path. This was also in the media_plugin_XXX 
> targets.
> 
> Other minor quibbles like the LLVM won't use -mlong branch, so just remove 
> that flag for media_plugin_quicktime if it gripes. And if Xcode warns you 
> about using GCC, click the warning and uncheck all boxes then hit "done." If 
> it warns you again, bad news, delete the whole build folder and build again 
> with autobuild (nuke the site from orbit). 
> 
> I *think* that was everything I had to do, to finally get it to compile. I 
> have been messing around with removing a lot of the legacy Darwin OpenGL 
> hacks to see what might have been fixed in 10.8's drivers. So far I've 
> doubled the viewer FPS on my Mac, but it's still buggy, so I'm not posting 
> any code revisions just yet.
> 
> I also tried compiling in 64-bit, but hahhahaha no.
> 
> -G
> 
> 
> ___
> 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

___
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: BUG-540: Math updates by Moon Metty. Reviewed by Chieron Tenk.

2012-10-24 Thread Geenz Spad

Question: I noticed that at least one item on the Firestorm JIRA had listed
instruction count differences, however I'd be more interested in seeing
actual execution time measurement differences between the two.  Has the
execution time between the originals and modified versions of the code been
measured?

On Wed, Oct 24, 2012 at 11:32 AM, Liny Odell
wrote:

> On Wed, Oct 24, 2012 at 12:45 AM, Henri Beauchamp  wrote:
> > On Wed, 24 Oct 2012 07:22:27 -, MartinRJ Fayray wrote:
> >
> >> This addresses bug BUG-540.
> >> https://jira.secondlife.com/browse/BUG-540
> >> .../...
> >> Testing
> >> ---
> >>
> >> Please go to https://jira.secondlife.com/browse/BUG-540
> >
> > "Permission Violation"
> >
> > Gotta love the crippled JIRA... :-(
> >
> > 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
>
> Try these links:see http://jira.phoenixviewer.com/browse/FIRE-7989
> and http://jira.phoenixviewer.com/browse/FIRE-7997
> ___
> 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
>
___
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] 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] Cocoa Project Viewer

2013-02-24 Thread Geenz Spad

The minimum size for the window (as defined in SecondLife.xib) is 1024x768.
 This is largely to prevent any odd cases where UI elements end up getting
clipped by the window inadvertently (though this is largely only a problem
with the width of the window, not the height).

I'll see about making the minimum size for the height of the window smaller.

On Sun, Feb 24, 2013 at 6:44 PM, Argent Stonecutter  wrote:

> Where should I report bugs in the Cocoa Project Viewer?
>
> On a MBP running Snow Leopard with an 800 pixel high display, the window
> is taller than the screen and can't be shrunk, even by editing the NS
> window size settings in the .plist file. This makes it unusable on that
> laptop.
>
> Other than that, I hope some of the TPVs bring in that code base for their
> Mac versions, because it's wicked fast.
> ___
> 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
>
___
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] new viewer

2013-07-23 Thread Geenz Spad

Vanilla Snowglobe 1.5 doesn't support server-side baking, meaning your avatar 
(and those around you) will not appear correctly pretty soon once the old 
protocols for baked textures go dark.

On Jul 23, 2013, at 9:28 PM, a...@skyhighway.com wrote:

> hey guys!  i was just wondering if somebody here could tell me what will
> happen for real if i don't upgrade my viewer?  i'm still using snowglobe
> 1.5.  i won't bore you with the long, teary story of why.  It's just
> upgrading my viewer for a while more isn't going to happen.  Like, not
> even possible.  "a while" means like, maybe months.  So, if i stay chill
> about what i do and don't ask for much, will i still be able to go in SL
> and not mess up my avi or inventory or anything like that?  i've got a
> premium membership in case that matters.
> 
> Thx so much for telling me anything you can!  Sorry to spam the list with
> a dumb, probably obnoxious question,
> 
> ___
> 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

___
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] Rebrand Mac build

2013-12-01 Thread Geenz Spad

Here’s the general overview:

Open SecondLife.xib in newview with Xcode
Rename the main window from Second Life to whatever you’d like to name it
Open the terminal, cd to newview and run the following: ibtool SecondLife.xib 
—compile SecondLife.nib

If you know a bit of Objective-C and the NSWindow API on OS X, you can also 
pragmatically change the window title as well through NSWindow’s setTitle 
method.

On Dec 1, 2013, at 5:21 PM, Nicky Perian  wrote:

> How is the SecondLife.nib file edited / changed to reflect a rebranded viewer?
> 
> ___
> 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

___
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] Mac OS X Metal support

2015-12-13 Thread Geenz Spad

Additionally, effective OpenGL != effective Metal.  In order to really take 
advantage of Metal, you would be looking at a massive rewrite of the viewer's 
rendering code to fit within the "Metal mindset" making a number of Metal 
specific optimizations along the way, and optimizations may not entirely fit 
within how the viewer currently does things today (for example, Metal tends to 
work best when you're submitting commands from multiple threads into a command 
buffer instead of everything happening on a single thread).  You could have 
better performance yes, but it would take a lot of work to port the viewer over 
to Metal in a way that would yield substantially better performance.

It's a lot like Direct3D 9 vs. Direct3D 10 and the supposed gains you could get 
with Direct3D 10 - they were only really there if you tailored your renderer to 
DX10, otherwise direct ports between APIs would frequently result in slower 
performance at worse, the same performance at best.

> On Dec 13, 2015, at 10:10 PM, Cinder Roxley  > wrote:
> 
> MetalGL is an OpenGL ES 2.0 implementation that uses the Metal framework, so 
> you’d be trading off performance and rewriting a pretty big chunk of the 
> rendering code for not much gain. Furthermore, MetalGL’s license is 
> incompatible with the LGPL.
> 
> -- 
> Cinder Roxley
> Sent with Airmail
> 
> On December 13, 2015 at 7:41:02 PM, Gistya Eusebio (gis...@gmail.com 
> ) wrote:
> 
>> I heard that there is a project called MetalGL that aims to compile OpenGL 
>> shaders using Metal... might make a port easier. Either way it would be 
>> awesome to see an SL client written from the ground up in Swift running 
>> Metal ... :D Maybe for SL 2 eh?
>> 
>> On Fri, Oct 30, 2015 at 6:43 PM, Oz Linden (Scott Lawrence) 
>> mailto:o...@lindenlab.com>> wrote:
>> On 2015-10-24 05:14 , Laurent Bechir wrote:
>>> Hello
>>> 
>>> Do you have some plan concerning the support of Metal in the viewer ?
>>> 
>> Not at this time.
>> 
>> --
>> Oz Linden (Scott Lawrence) | Engineering Director, Second Life
>> Email or Hangouts o...@lindenlab.com  | Second 
>> Life Oz Linden 
>> Linden Lab | Makers of Shared Creative Spaces 
>> Check out what we're working on! 
>> ___
>> 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
>> 
>> ___
>> 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
> ___
> 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

___
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] Mac OS X Metal support

2015-12-13 Thread Geenz Spad

Additionally, effective OpenGL != effective Metal.  In order to really take 
advantage of Metal, you would be looking at a massive rewrite of the viewer's 
rendering code to fit within the "Metal mindset" making a number of Metal 
specific optimizations along the way, and optimizations may not entirely fit 
within how the viewer currently does things today (for example, Metal tends to 
work best when you're submitting commands from multiple threads into a command 
buffer instead of everything happening on a single thread).  You could have 
better performance yes, but it would take a lot of work to port the viewer over 
to Metal in a way that would yield substantially better performance.

It's a lot like Direct3D 9 vs. Direct3D 10 and the supposed gains you could get 
with Direct3D 10 - they were only really there if you tailored your renderer to 
DX10, otherwise direct ports between APIs would frequently result in slower 
performance at worse, the same performance at best.

> On Dec 13, 2015, at 10:10 PM, Cinder Roxley  wrote:
> 
> MetalGL is an OpenGL ES 2.0 implementation that uses the Metal framework, so 
> you’d be trading off performance and rewriting a pretty big chunk of the 
> rendering code for not much gain. Furthermore, MetalGL’s license is 
> incompatible with the LGPL.
> 
> -- 
> Cinder Roxley
> Sent with Airmail
> 
> On December 13, 2015 at 7:41:02 PM, Gistya Eusebio (gis...@gmail.com 
> ) wrote:
> 
>> I heard that there is a project called MetalGL that aims to compile OpenGL 
>> shaders using Metal... might make a port easier. Either way it would be 
>> awesome to see an SL client written from the ground up in Swift running 
>> Metal ... :D Maybe for SL 2 eh?
>> 
>> On Fri, Oct 30, 2015 at 6:43 PM, Oz Linden (Scott Lawrence) 
>> mailto:o...@lindenlab.com>> wrote:
>> On 2015-10-24 05:14 , Laurent Bechir wrote:
>>> Hello
>>> 
>>> Do you have some plan concerning the support of Metal in the viewer ?
>>> 
>> Not at this time.
>> 
>> --
>> Oz Linden (Scott Lawrence) | Engineering Director, Second Life
>> Email or Hangouts o...@lindenlab.com  | Second 
>> Life Oz Linden 
>> Linden Lab | Makers of Shared Creative Spaces 
>> Check out what we're working on! 
>> ___
>> 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
>> 
>> ___
>> 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
> ___
> 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

___
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] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

2016-07-08 Thread Geenz Spad

https://xkcd.com/386/ 

With that out of the way, autorelease pools don't have much to do with garbage 
collection - in fact the document that you've linked to specifically outlines 
the following with regards to autorelease pools and GC:
> In a garbage-collected environment, there is no need for autorelease pools. 
> You may, however, write a framework that is designed to work in both a 
> garbage-collected and reference-counted environment. In this case, you can 
> use autorelease pools to hint to the collector that collection may be 
> appropriate.

There isn't anything functionally wrong with the code that you have specified, 
unless you count not letting the compiler decide what should be done there as 
being a functional problem (that's how ARC actually works - it's just telling 
the compiler to generate the necessary pools, retains, releases, deallocs, and 
so on as it finds cases where it's needed).  It wouldn't even work under a GC 
or otherwise trigger the GC to do much of anything unless I drained the pool - 
at best it would provide a hint to the GC, and at worst it would no-op.  Even 
then, the viewer still doesn't use GC.  Instead I had it manually allocate and 
deallocate objects as needed, with the exception of the occasional autorelease 
pool.  To my knowledge, manual memory management is still supported under OS X 
10.12, and ARC is still opt-in (or opt-out, depending on what version of Xcode 
you created the project with).  A few tests on my end still show that 
NSAutoreleasePool is still valid, as is autorelease and autorelease blocks, 
when using the latest beta of macOS 10.12 and Xcode.

Now!  That being said, at the time that the code was written ARC wasn't well 
supported under OS X 10.6, which was the viewer's minimum target at the time.  
Of course as time has went on, the viewer's minimum requirements have changed.  
It wouldn't be the worst idea to revisit it, especially since my own coding 
style and skills have improved since I wrote the original code for the Obj-C 
port of the viewer's frontend, but at the same time it doesn't really add much 
value given that you're basically talking about making the compiler do 
something that's already being done manually.  You won't see any massive 
performance gains.  You won't see the viewer magically shed tens of megabytes 
off of its memory footprint.  Sure you could argue that if Apple decides to 
make ARC the law of the land with no MRR being permitted in sight there could 
be some value there, but there's no indication of that happening.  You would be 
doing it literally to future proof something where there's no indication of 
there being a need to do so, and only for any Objective-C objects - C++ objects 
are untouched by ARC.

If you'd like to continue debating how memory management works under 
Objective-C, and NSAutoreleasePool, release, retain, and dealloc's place in it, 
by all means!  Feel free to email me directly, though I'd recommend reading 
this first 
.
  Though I doubt there's much interest on this list in watching such a thing.
> On July 8, 2016 at 3:13:44 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
> ) wrote:
> 
>> I cannot see there is anything “advanced”  MRR (manual retain-release) going 
>> on in:
>> 
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
>> 
>> insert your viewer code here
>> 
>> [pool release];
>> 
>> 
>> That can’t be handled with @autoreleasepool,
>> if you even need to handle it outside the main thread
>> autoreleasepool
>> 
>> 
>> In fact the above is a classic example of the old garbage collector in 
>> action. 
>> 
>> 
>> Geir, 
>> 
>> 
>>> On 8. jul. 2016, at 21.47, Geir Nøklebye >> > wrote:
>>> 
 Cinder Roxley said:
>>> 
 The viewer has never used the garbage collector so it?s not an issue.
>>> 
>>> 
>>> 
>>> Why is it that in llopenglview-objc.mm, as en example, we have statement 
>>> like:
>>> 
>>> NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
>>> initWithAttributes:attrs] autorelease];
>>> 
>>> or 
>>> 
>>> - (void)dealloc
>>> {
>>> [[NSNotificationCenter defaultCenter] removeObserver:self];
>>> [super dealloc];
>>> }
>>> 
>>> while Apples ARC migration guidelines states:
>>> 
>>> You cannot explicitly invoke dealloc, or implement or invoke retain, 
>>> release, retainCount, or autorelease.
>>> 
>>> You can’t invoke dealloc.
>>> 
>>> Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
>>> actually results in a compiler error). The chaining to super is automated 
>>> and enforced by the compiler.
>>> 
>>> 
>>> Or in llwindowmacosx-objc.mm we have code such as:
>>> 
>>> bool copyToPBoard(const unsigned short *str, unsigned int len)
>>> {
>>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
>>> NSPasteboard *pboard = [

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

2016-07-09 Thread Geenz Spad

Literally all this does is enable ARC.  Don't forget that Apple still allows 
opt-out on a file by file basis for situations where ARC is not desired (such 
as cases where the compiler isn't doing something that you want WRT retaining 
objects outside of autorelease pools).  This does not change the fact that the 
viewer utilizes MRR and manual reference counting.  NSAutoreleasePool is not 
deprecated under this model, but it would largely need to be transitioned to 
@autoreleasepool blocks instead which enables the compiler to decide how to 
manage the pool, not the programmer when it comes to ARC or MRR.  Additionally, 
a couple of autoreleases would need to be removed, but that's only if you 
intend to change from MRR+MRC to ARC.

It seems like you are complaining literally because "Apple made it the default 
for new projects, so you should too!"  Either way, MRR is here to stay.  I 
don't think anyone ever really disputed whether or not the viewer will or won't 
compile with ARC enabled.  Additionally, expanding upon your previous example, 
the following function would not work in the garbage collector as it would 
under MRR, nor would it function under ARC:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init]; // This is 
unnecessary under GC, as the GC will collect objects automatically, whether 
they're in a pool or not.  It's not valid under ARC simply because the 
compiler's job is to figure out how to manipulate a pool for you when it's 
enabled.
// Any object allocated here under MRR that is not retained will be 
released when the pool is either drained or released.  See below for the 
difference between the two.
[pool release];  // This is a no-op under GC, however 'drain' provides 
a hint to the GC.  Under MRR patterns, release will message any receiving 
objects to dealloc "when their reference count reaches zero" - drain does the 
same without the GC.  ARC-enabled compilers like Clang will insert this for you 
where necessary.

tl;dr, sure it'll fail to compile under ARC.  It also won't really work with 
the long deprecated GC either.  But then, the code wasn't written with either 
of these things in mind.  Just the standard MRR and reference counting 
environment of its time.  I doubt anyone would complain if someone transitioned 
from manual reference counting to automatic reference counting in the macOS 
frontend, however - there shouldn't really be anything that would run afoul of 
it that I'm aware of.

And before there's an argument over MRC vs. ARC - Obj-C's MRR with autorelease 
pools still function on top of reference counting - just it's done manually by 
the programmer (thus "Manual Retain-Release"), not automatically by the 
compiler.

> On Jul 9, 2016, at 3:36 AM, Geir Nøklebye  wrote:
> 
> -fobjc-arcflag

___
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] Mesh rendering: What does indicesp provide?

2010-06-03 Thread Geenz Spad

I'm sure it wouldn't hurt to ask Eric Lengyel if one could create their own
LGPL implementation of Voxel terrain LOD based off of his paper.  He'll
usually only ever say no in the event that it involves distributing code to
one of his commercial products (such as the C4 Engine).  Since in this case,
it involves a paper that he distributes freely, I doubt he'll have any
problem.  He writes these papers with the intention of people implementing
them in their own projects.  He responds to emails fairly quickly.

On Thu, Jun 3, 2010 at 5:55 PM, Rob Nelson wrote:

> It may be quite fast, but I don't think it's GPL, so I can't really use
> it.  I'll have to come up with my own MacGyver'd implementation of LOD
> and stitching after I finish the initial implementation.
>
> Rob
> On Thu, 2010-06-03 at 11:42 -0500, Jonathan Goodman wrote:
> > It may be a bit late for this, but I would actually like to point out
> > a paper that was recently released that details the construction of
> > terrain from voxels in the C4 Game Engine (1.5.9, and the LOD
> > algorithms introduced in C4 2.0 that was released a few days ago).
> >  The implementation in place in C4 is quite fast, to the point it's
> > quite suitable for realtime deformations of terrain.  It details the
> > construction, Level of Detail, material handling for per-pixel
> > lighting, and to some extent the editing tools available in C4 for
> > voxel terrain editing.
> > http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
> > ___
> > 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
>
>
>
___
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] Project-MESH viewer

2010-10-16 Thread Geenz Spad

Shiny does work with the deferred renderer (or Lighting and Shadows as it's
now called in the Mesh viewer).  It's simply handled differently; it
reflects light in the form of what's known as specular reflectance, instead
of reflecting the sky environment (at one point it reflected both around
2008 and 2009).  Different shiny settings effects the overall brightness and
distribution of the specular exponent.

On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole wrote:

> Are you planning to enable shine on prims with lighting/shadows on or is
> full lighting effects disable shininess something we need to accept as
> permanent and texture around? (Note that lighting in Kirstens also disables
> shine)
>
> --
> *From:* Oz Linden (Scott Lawrence) 
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Sat, October 16, 2010 11:01:38 AM
> *Subject:* Re: [opensource-dev] Project-MESH viewer
>
>   On 2010-10-15 18:00, Trilo Byte wrote:
> > But on the flipside, the Project MESH viewer has working shadows for
> nVidia GPU's on Mac (never happened before on any known config), and
> anti-aliasing's fixed.  If we could get that bit out of the mesh viewer and
> into the 2.2 pipeline, we'd really be in great shape IMO.
>
> The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about
> the other (since I don't know which change that was).
>
> ___
> 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
>
>
> ___
> 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
>
___
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] Reflections in SL. Re: Project-MESH viewer

2010-10-17 Thread Geenz Spad

I could see the new "Shiny" (in reality, they should be called specular 
highlights) breaking content that relied on the darkening properties of 
the classic Shiny shader.  Which is why I've modified the deferred shiny 
shader to "darken" the object's diffuse shading depending on the shiny 
value, without resorting to silly environment maps to make things "Shiny".

http://www.flickr.com/photos/50275...@n04/5088357599/in/photostream/

Argent Stonecutter wrote:

On 2010-10-16, at 22:09, Tateru Nino wrote:

A year or two ago, I was treated to a demonstration of working mirrors
in SL. It was an override of Shiny, and I had to install a custom shader
file to my SL viewer installation directory. As far as I know, the
project died because - in order to work - it needs a bit or a texture
property flag from Linden lab on the server-side, otherwise it is
"surprising or unexpected" functionality that potentially breaks
content, and thus is a no-no under the TPVP.


The original mirror project back in SL 1.13 was an override of shiny too.

It was optional.

So long as it's optional I don't see why it would violate the TPVP.
___
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
___
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] Dynamic shadows and ATI

2010-11-18 Thread Geenz Spad

Your best bet is to complain directly to Apple with a repro case.  The mesh
beta viewer seems  to fix the FBO issues on OS X.  AFAIK, AMD only writes
the hardware drivers for their cards on OS X, Apple handles the OpenGL bits
and pieces across both AMD and Nvidia hardware.

On Thu, Nov 18, 2010 at 10:01 AM, Laurent Bechir  wrote:

>
>
> Dave Booth a écrit :
>
> On 11/13/2010 06:04, Laurent Bechir wrote:
>
>  Is it a hardware problem of ATI or just a software problem that can be
> solved by SL developers ?
>
>  ATIs drivers have bugs - ATI + OpenGL FBOs = crash or render artifacts
> or both.
>
>
>
> Who is responsible in that case ? Apple or ATI/AMD ? Because if there is no
> solution for this problem, Mac computers will not have dynamic shadows
> before a long time since they are all shipped with ATI cards. So I'd like to
> try to contact the support of the one in charge and see if something can be
> done.
>
>
>
> ___
> 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
>
___
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 depth-of-field feature

2010-11-25 Thread Geenz Spad

I wonder how awesome it'll run on top of the already awesome deferred
renderer that has really awesome performance on really awesome video cards
that have really awesome drivers?

Honestly, as nifty as DOF is as far as the "pretty" factor is concerned,
right now the deferred renderer needs a few more optimizations before any
additional features are added to it, and it still needs a few more work
arounds for buggy drivers (for example, successfully running the deferred
renderer on ATI hardware still tends to vary from person to person,
depending on their hardware and driver combination).  On top of that, you
still need a pretty powerful video card in order to really take advantage of
it, though I think that really has to do with bottle necks within the
rendering system as a whole, not just bottle necks presented by the deferred
renderer its self (although deferred rendering does have it's own bottle
necks, and SL's deferred renderer in particular presents a few interesting
ones of its own due to its flexibility).

On Thu, Nov 25, 2010 at 4:43 PM, Ricky  wrote:

> Things ARE getting fixed, just look at the daily scrum reports or the
> progress tracking in the JIRA.  Also take note that sometimes "adding"
> a single feature will often resolve several bugs and feature requests.
>  For instance the Deferred rendering channel will add the ability to
> have greater than 7 light-sources, solving several issues with 
> facelights and other lights taking out room lighting.
>
> As to optimization, things are pretty optimized.  Yes, they CAN get
> better, but without a major restructuring of how content is created,
> we will never have the high render rates found in the online and
> offline games.  Even so, the work being done on upgrading KDU looks
> like it is improving load/render rates as it is.
>
> Don't forget that there are multiple people in multiple teams working
> on this program.  Some are better at adding new features, and so are
> better utilized in that area.  Some are better testers than coders,
> and so that's where they get used.  Some, fairly rare, are really good
> at making existing code much better.  All these people types are at
> work here, and putting them all into "optimizing or fixing things"
> would be a death-knell for the company.
>
> I'd say, instead of berating new (and very cool,) advancements, we
> should all applaud the work being done.  At the very least it will
> make someone's day that much brighter.
>
> Just my opinion,
> Ricky
> Cron Stardust
>
> On Thu, Nov 25, 2010 at 12:34 PM, Rob Nelson
>  wrote:
> > Oh good, let's add more features instead of either optimizing things or
> > fixing things.
> >
> > Rob
> >
> > On 11/25/2010 8:56 AM, Opensource Obscure wrote:
> >>   Thanks to BlakOpal today I saw these very cool images:
> >>   http://twitpic.com/3a0vag/full
> >>
> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770
> >>
> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114
> >>
> >>   Where can I find more information about this depth-of-field
> >>   feature? (wiki pages, blog/forums, JIRA...)
> >>
> >>   It really looks good. I'm going to download a test build now.
> >>
> >>
> >>   Thanks in advance
> >>   Opensource Obscure
> >> ___
> >> 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
> >>
> >
> > ___
> > 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
> >
> ___
> 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
>
___
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] Mesh support current status???

Re: [opensource-dev] ATI vs NV vs OSX

[opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1823 - Replace current specular model with Normalized Blinn-Phong specularity

Re: [opensource-dev] Review Request: STORM-1819: Graded Shadows

[opensource-dev] Autobuild hell

Re: [opensource-dev] Anyone else having this issue uploading meshes?

Re: [opensource-dev] Anyone else having this issue uploading meshes?

[opensource-dev] Content Creation Improvement UG - Morph Target Discussion

[opensource-dev] Review Request: As Gatekeeper, I like binaries downloaded through a web browser to be signed

Re: [opensource-dev] Mercurial repository webpage layout

Re: [opensource-dev] OSX 10.8 / Xcode 4.5 compile support (wasReview Request: patch potential memory leak in llgl.h)

Re: [opensource-dev] OSX 10.8 / Xcode 4.5 compile support (wasReview Request: patch potential memory leak in llgl.h)

Re: [opensource-dev] Review Request: BUG-540: Math updates by Moon Metty. Reviewed by Chieron Tenk.

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

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

Re: [opensource-dev] Cocoa Project Viewer

Re: [opensource-dev] new viewer

Re: [opensource-dev] Rebrand Mac build

Re: [opensource-dev] Mac OS X Metal support

Re: [opensource-dev] Mac OS X Metal support

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

Re: [opensource-dev] Mesh rendering: What does indicesp provide?

Re: [opensource-dev] Project-MESH viewer

Re: [opensource-dev] Reflections in SL. Re: Project-MESH viewer

Re: [opensource-dev] Dynamic shadows and ATI

Re: [opensource-dev] Upcoming depth-of-field feature

36 matches

Site Navigation

Mail list logo

Footer information