[sldev] Rendering Limits

[Melinda Green]

It is definitely on the road map to eventually support a fully 
scriptable XUI format as well as to allow programmatic viewer control 
from external processes through published APIs. I don't expect that the 
native scripting language will be anything like LSL, but who knows, that 
might not be such a bad idea. Visual GUI builders are definitely another 
direction in which I expect this to grow, and implementing one as an 
Eclipse plug-in definitely looks like the quickest path to me. I don't 
know anything about Glade but perhaps that would make that task even 
easier. The key will be to get such GUI builders to read and write XUI 
files. That much could be done today even without any scripting ability, 
and even the LL designers struggle to hand-code XUI when such a GUI 
builder would save so much time in the long run. That's definitely a 
plumb task that an enterprising SLDev member could take on and earn much 
love. In the meantime I highly encourage anyone interested to get more 
familiar with the powerful XUI features available today. Much of it is 
undocumented, and helping to create *that* missing piece would be a 
great place to start since clear specs are absolute prerequisites for 
creating GUI builders or any other infrastructure on top of it.

-Melinda

Dzonatas Sol wrote:
> I think what some people want is a like a LSL based code-behind 
> feature to the UI.
>
> Did I say it? Oops, I did.
>
> Hold that thought.
>
> Actually, I'm eager for GtkBuilder to fully phase-in, then UI builders 
> like the Glade Interface Designer would have lots of fun interactive, 
> custom widgets ready to use in the palette:
> http://glade.gnome.org/screenshots.html
>
> Example vid of using Glade:
> http://people.redhat.com/overholt/nativeeclipse/
>
> Of course, that was with Eclipse, and the Eclipse UI is written with 
> Gtk. Hmmm - powerful enough for holistic programmers.
>
> Here is an older review of Glade: 
> http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/
>
> The Glade Interface Designer is also a library, so it is embeddable 
> (into some viewer app someday maybe): 
> http://glade.gnome.org/docs/index.html
>
> Ok, I said too much.
>
> Cheers,
> http://twitter.com/Dzonatas
>
> Melinda Green wrote:
>> 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
>>>
>>>
>>>     
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting privileges
>>
>>   
>