[sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h

[Max Okumoto]

Never mind, I miss read the header.  I just need to down load the glgui 
package.

                     Max

Max Okumoto wrote:
> Hi Brad,
>
> I tried to compile the windlight-1-17-0 branch, but ran into a slight 
> problem.  I don't have the glh headers.
>
>     llwindow/llgl.cpp:47:28: glh/glh_linear.h: No such file or directory
>     llwindow/llgl.cpp:48:33: glh/glh_convenience.h: No such file or
>     directory
>
> Googling for them seems to indicate that those are NVIDA header 
> files.  Are there any patches
> for using ATI drivers?
>
>                Max
>
> Brad Linden wrote:
>>
>> First, a real short introduction:  I'm Brad Linden and joined the 
>> Boston area office of Linden Lab last month.  I've been working on 
>> WindLight (available at 
>> http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0/).  
>> You can see Zen's blog post 
>> (http://blog.secondlife.com/2007/06/14/windlight-update/) and 
>> Torley's post 
>> (http://blog.secondlife.com/2007/05/21/windlight-atmospheric-rendering-comes-to-second-life/) 
>> for more details.
>>
>>
>> Nicholaz Beresford wrote:
>>>
>>> Just off hand and without looking deeper, I think
>>> the "VO" stands for Viewer-Object (think these
>>> are derived from LLViewerObject)
>>>
>>>
>>> Nick
>>>
>>>
>>> Second Life from the inside out:
>>> http://nicholaz-beresford.blogspot.com/
>>>
>>>
>> That is correct.  The LLSky class is a global singleton (gSky) for 
>> managing access to anything related to the sky, including the LLVOSky 
>> instance (gSky.mVOSkyp).
>>
>>> Max Okumoto wrote:
>>>> Hi,
>>>>
>>>> Can someone at LL explain the llvosky.h vs llsky.h naming convention?
>>>>
>>>> My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming
>>>> about 5%, so I have started seeing if I can speed it up.
>>>>
>>>>                                              Max
>>
>> You might want to wait before spending too much time on that, or at 
>> least not work on that branch.  If you look at the WindLight branch 
>> you'll see that that function has been completely replaced with 
>> something much more cpu-intensive, but updated less frequently.  It's 
>> essentially a straightforward attempt at imitating the WindLight sky 
>> glsl shaders in 
>> indra/newview/app_settings/shaders/class2/windlight/WLSkyV.glsl and 
>> indra/newview/app_settings/shaders/class2/windlight/WLSkyF.glsl.  If 
>> you want to try to optimize the sky CPU code, this branch is the 
>> place to do it, but take note that on systems that have a GPU and 
>> OpenGL drivers that can run WindLight, this code is obsoleted by the 
>> new LLVOWLSky class, and the LLVOSky class will be largely disabled 
>> (this is not happening properly in the snapshot we exported to the 
>> public svn server).
>>
>> As our focus has been on getting the new GPU rendered WindLight 
>> codepath working on as many hardware configurations as possible, the 
>> CPU rendering code in LLVOSky has not had as much attention, as it's 
>> really not suited for the way WindLight works and may need a complete 
>> refactoring, and there are major outstanding bugs in it: 
>> https://jira.secondlife.com/browse/VWR-980.  Any contributions to the 
>> CPU fallback code in LLVOSky would be much appreciated.
>>
>> So in summary, if you want to work on sky code and get your code used 
>> after WindLight gets merged into the trunk, work in the WindLight 
>> branch.  If you have questions about what you find there, I'm your man.
>>
>> hope this helps,
>> -Brad Linden
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>