[sldev] Rendering Limits

[Melinda Green]

Maybe there is more than one XUI here and I could be the one causing the 
confusion but I had thought that what LL's calls XUI was an entirely 
homegrown XML schema. (Or is that LLUI?) Anyway, there's no connection 
to Java that I'm aware of, and being a big Java nut, I'd certainly have 
remembered that.

Good luck getting traction with your Snowglobe-Sharp API. That does 
sound interesting.
-Melinda

Dzonatas Sol wrote:
> 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
>>>>
>>>>   
>>>
>>
>
>