[sldev] Rendering Limits

[Melinda Green]

Nexi,

I'm not stating an opinion about the value of Windlight controls one way 
or the other. I do agree with you that it would be better if the setting 
names were better chosen in order to organize them into some meaningful 
hierarchy, but the chance to do that passed a long time ago. Even if 
someone did the huge job of changing the names throughout the entire 
source code and XUI content, that patch would never be accepted because 
of the branches within LL (and externally) that would be affected. The 
end result is that once you name a setting or control, it's nearly 
impossible/impractical to change it. We're then left with an underlying 
flat list of settings for better or worse and I therefore believe this 
is *not* the place to start! We could of course impose an external 
organization onto that list though a config UI like you suggest. That 
sounds like a good idea to me but is completely orthogonal to taking 
advantage of the existing XUI<-->saved settings bridge.

If anyone wants to see good examples of doing the sort of stuff I'm 
talking about, I recommend looking at the new View->Beacons floater 
implementation that I created. It was implemented almost entirely in 
XML, only requiring C++ code to launch the floater and to enforce a 
couple of the previous quirky interactions between the beacon types. The 
rest is implemented entirely in XUI making heavy use of the control_name 
tag. BTW, this is how many of the Windlight controls were implemented 
too and was where I found the examples I needed when doing the beacons 
work. This is an incredibly powerful and underused pattern.

-Melinda

Nexii Malthus wrote:
> Well, I think we could start by re-working the debug-settings menu a bit.
>
> Load up Firefox and go to this page:   "about:config"
>
> Thats an excellent example of a good debug settings menu. The settings 
> are easily understandable imho.
>
> Seperated into their relevant sections,  I think it would be great if 
> we had that a similiar naming scheme. That would be at least one step 
> towards opening up the deeper parts of the engine towards users. Not 
> to mention the help it would provide to developers, lindens and 
> non-lindens alike for making it easier to test out experimental 
> features or performance optimizations.
>
> Imagine a naming scheme towards the graphical subsystems.
> render.spatial.maxnodesize for this situation as a loose example.
>
> Wouldn't it be easier and efficient to expose only the relevant debug 
> settings to each subsystem too? render.* being available to the render 
> stuff. network.* being for the network stuff.
>
> If we want to revamp the whole way preferences work we need to move 
> step-by-step from the bottom up.
>
> I do agree that the LL designers feel a bit itchy about the current 
> windlight preferences and I agree, it is messy. But its wrong to hide 
> the tools for the right job when you consider the majority of 
> individuals that are willing to go a step further to make their 
> experience so much better.
>
> Just look at the stuff Torley and other talented photographers have 
> made in snapshots by messing about in the windlight settings and shadows.
>
> - Nexii Malthus
>
> On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green 
> <melinda at superliminal.com <mailto:melinda at superliminal.com>> wrote:
>
>     That's an interesting suggestion, Nexii. I'm not sure how the LL
>     designers feel about all those Windlight preferences but I
>     wouldn't be surprised if they'd mostly prefer to hide or eliminate
>     most of them. There's always a tension between number of controls
>     and the all-important SL learning curve.
>
>     One way to break this logjam is to start using the new XUI
>     features to allow external designers to create custom UI without
>     the need for developers to hook them in and compile entire custom
>     viewer binaries and then update them with each viewer version.
>     Skinning is the first step on that road but there is a lot of
>     other useful stuff under the hood that can also be used today. My
>     favorite is the "control_name" XUI tag which lets you associate
>     check box and slider values with particular saved settings. When
>     you load a floater or other XUI element containing a check box or
>     slider with that tag, then it takes it's initial value from the
>     named saved setting and automatically saves back out modified
>     values as the user interacts with those controls.
>
>     This is extremely powerful and should let you create your custom
>     panel to control any of the boolean or real valued settings that
>     you see in the debug settings floater. The only thing really
>     missing here (other than support for more control types) is the
>     ability to launch a custom floater. Ideally that would come with
>     the badly needed keyboard remapping functionality to allow you to
>     specify a hot key to load a named floater. (Hint: Great Snowglobe
>     feature here!) Since we don't have that yet, you'd probably have
>     to append your controls to some existing floater if you want to
>     add controls without programming, but that shouldn't be too awful.
>
>     -Melinda
>
>     Nexii Malthus wrote:
>
>         I think by spatial groups you could consider how dense an area is.
>
>         We really should open many more options on the preferences
>         menu. Perhaps it should branch off into a seperate menu due to
>         the relevant complexity, imagine how complex the windlight
>         sliders are, but they are also nicely dispersed into their
>         relevant categories and sections. We should aim to achieve the
>         same, not to mention the explanations that were provided in
>         the WindLight menu were pretty cool and awesome to understand
>         what the settings do.
>
>         WindLight is a mere single subsystem of the entire graphics
>         system, why can't we have the same attention put into other
>         areas in terms of control via the UI?
>
>         There are many hidden settings, some that are not even
>         affected by the more generalised "Low, Medium, High, Ultra"
>         that have an impact on FPS and the experience.
>
>         L$0.02.
>
>         - Nexii Malthus
>
>         On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky
>         <gretzky.harleen at gmail.com <mailto:gretzky.harleen at gmail.com>
>         <mailto:gretzky.harleen at gmail.com
>         <mailto:gretzky.harleen at gmail.com>>> wrote:
>
>            It appears to be more than just jewelry that is effected.
>            VWR-14049 and VWR-14146 are builds that are effected also. When
>            posing this question I was really trying to understand how the
>            rendering limits work. For instance, does the renderMaxNodeSize
>            limit apply to the entire scene, or only to portions of the
>         scene?
>            Does it apply to avatars as well as objects? It seems to have
>            something to do with 'spatial groups' but what are 'spatial
>            groups'? Is renderMaxNodeSize the only rendering limit?
>
>            If renderMaxNodeSize is the only setting that, I would
>         think the
>            best solution as has been suggested on the JIRAs and here is to
>            move the setting onto the Graphics preference tab. Since it
>         seems
>            to be a little low for those running graphics at High and
>         Ultra it
>            should probably be increased for those users. So maybe
>         something like:
>
>            Low - 2048
>            Mid - 4096
>            High - 8192
>            Ultra - 8192
>
>            Then if a user chooses Custom there should be a slider
>         control to
>            allow it to be set to the value of their choice. Just my
>         two cents.
>
>            -Harleen
>
>
>            _______________________________________________
>            Policies and (un)subscribe information available here:
>            http://wiki.secondlife.com/wiki/SLDev
>            Please read the policies before posting to keep unmoderated
>            posting privileges
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         Policies and (un)subscribe information available here:
>         http://wiki.secondlife.com/wiki/SLDev
>         Please read the policies before posting to keep unmoderated
>         posting privileges
>
>