[sldev] Rendering Limits

[Dzonatas Sol]

The XUI standard is still tied to Java. That means the fully scriptable 
XUI formats are limited to Java programmers. With the XUI standard also 
being tied to mobile devices that depend on Java, well, I guess the 
right question to ask is how to get XUI to work well, being fully 
scripted (with Java), on mobile devices that don't run Java? I'm sure 
further discussion on that will go beyond interfaces to handle rendering 
limits.

Also note, there are already Eclipse plug-ins for XUI builders. Since 
there are more than a few, I'll just link to a forum about them: 
http://sourceforge.net/forum/forum.php?forum_id=556171

If the fully scriptable XUI/Java based interface can reach the same API 
that any other alternative scriptable UI can reach, then that API is 
key... rather than require transformations of XUI to any degree.

Note, I have already made an API for ControlGroup classes in 
Snowglobe-Sharp, and it does make things that much more powerful (as you 
even noted with XUI).

Melinda Green wrote:
> 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
>>>
>>>   
>>
>