[sldev] Rendering Limits

Dzonatas Sol dzonatas at gmail.com
Sat Jun 20 19:58:27 PDT 2009


Ah! Yes, a bit of confusion most certainly!

Thank you for the luck.

To touch back on rendering limits, I wonder how many extra vertices the 
UI overlay adds. I was just thinking about this limit while I was in a 
group IM session. The viewer window is not set fullscreen. There are 
many reasons why I don't usually set it fullscreen, and those range from 
performance to mainly that I like being able to have several IDEs on my 
screen at once (or where they can be quickly tabbed). I took a 
screenshot of the IM session (and moved IDEs out of the way beforehand). 
Take a peek:

http://mono.dzonux.net/file/MonoVida-20090620a.png

Now, the long lines make it harder to see much further in the past 
conversation unless I scroll the window. It would be easier if the 
window was resized larger to see longer types lines on one line instead 
of multiple lines. To achieve that with the normal viewer, I would have 
to go fullscreen. This brings up issues that fullscreen would block my 
other windows that I have open and could make the performance go down 
(hence, my thought track on render limits). Sometimes when I click 
fullscreen, it is quick, but usually on a busier scene it takes awhile 
to flip to fullscreen and flip back when I want to get back to the IDEs.

With MonoVida, where it can display the communication window as a 
totally separate window from the viewer, I'm able just "fullscreen" the 
communication window, or even give half the screen to comms and the rest 
to the main view, like this:

http://mono.dzonux.net/file/MonoVida-20090620b.png

In the normal viewer, the communication window would be extra vertices 
to process. In MonoVida, there are no GL verticies or GL text to 
process, as the communication window doesn't even use GL. I could make 
the main view very small and just be involved with the commuication 
windows and maybe other applications/IDEs.

I think you'll agree the fuller view of the communication window is much 
easier to read.

Anways, mainly wanted to add a question how many extra vertices are 
being used by LLUI?

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



More information about the SLDev mailing list