[sldev] Rendering Limits

Melinda Green melinda at superliminal.com
Thu Jun 18 19:03:01 PDT 2009


I love what Jesse, Stickman, and Ambrosia have already said on this 
subject so I won't repeat them but I will heartily endorse their 
opinions. The one thing I will add is to drill a little deeper into what 
Dzonatas is suggesting here to refine the LOD selection mechanism. There 
is a large body of published research on this subject and I once 
implemented one particularly exciting algorithm from a SIGGRAPH 
proceedings in the mid 90's. I'm sorry that I can't find it but the 
basic idea was to use a modified knapsack algorithm (normally NP 
complete but cheap if you can accept quality within 90% of optimal) to 
select the greatest rendering result for the cost given a set of LODs 
for each object and heuristically calculated costs and benefits for each.

This relates to Dzonatas' suggestion because moving objects do indeed 
reduce the benefits of drawing them at higher LOD. The question is not 
how fast the object or user is moving, but how fast a given object is 
moving in the user's screen space. So if you're flying forward, for 
example, you'd want high resolution directly in your direction of travel 
since objects there won't move much on your screen. The algorithm also 
gives weight to each object's size on the screen, so even that 
complicated necklace becomes worth the high LOD of the whole building 
you're in when you are admiring it close up. It even weights objects 
higher when they're near the center of your screen on the assumption 
that you're probably more interested in things you're pointed directly at.

All this is to say that if we're going to get much more sophisticated in 
our handling of LOD, there are some excellent techniques available and 
it might be best to consider a holistic approach to the problem rather 
than to grow another ad hoc solution.

-Melinda

Dzonatas Sol wrote:
> Further, it would be good to know how many times the limit was hit per 
> frame, if the limit is done per render object (being prims that share 
> the same linkset or the same axis origin).  If the limit is hit often, 
> then it would be a way to let the user know the scene is too complex 
> for their graphics platform. Some settings could be changed 
> automatically in order for the user experience to stay relatively 
> responsive.
>
> The rumor is that the limit is a cutoff per frame right now for 
> enumerated vertices. If that is true, then the above suggestion is 
> only workable if a limit is made for a maxium per object as above.
>
> With this, for example, there could be logic for: if( !moving ) 
> renderHigherDetail() else if( movingfast ) renderLowerDetail() else 
> renderNormalDetail()
>
> Tigro Spottystripes wrote:
>> would it be too hard to make things that are above the limit be LOD'ed
>> down gradually, and only start unrendering things when a huge chunk of
>> everything on screen is already at lowest LOD?
>>
>> Also, any such limits should be a slider with a typeable textbox next to
>> it on the graphics tab of the preferences screen IMO.
>>
>> Moriz Gupte escreveu:
>>   
>>> I think rendering limits are inevitable, resources tend not to be
>>> unlimited. There will be disagreements regarding rendering
>>> prioritizations/limits ... this is to be expected. Perhaps one
>>> approach would be to see how much pain is inflicted on the community
>>> if a limit is imposed. If most don't even notice it, then it's
>>> probably a proper rendering limitation...which would then qualify as
>>> an 'optimization'. One thing is very helpful though, and think Soft
>>> has done some of it already, is to publish these limitations and how
>>> it impacts rendering (must be easier for LL to initiate that than the
>>> community). *forgive me * if this is published somewhere already, may
>>> be share the link.
>>>
>>>
>>>
>>> On Thu, Jun 18, 2009 at 8:53 AM, Soft<soft at lindenlab.com> wrote:
>>>   
>>>     
>>>> Try creating a 128x128 sculpted prim, then link 255 of those together
>>>> in a 16x16 grid (remove one to make 255). Then scale them down as far
>>>> as they'll go and wear it like a badge. You should start to see some
>>>> prims in the set vanish.
>>>>
>>>> On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia<chaosstar at gmail.com> wrote:
>>>>     
>>>>       
>>>>> This is news to me as well. Rendering limits? Which? I personally have
>>>>> not noticed anything that I might recognize as a new rendering limit?
>>>>>
>>>>> On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky<gretzky.harleen at gmail.com> wrote:
>>>>>       
>>>>>         
>>>>>> Can you elaborate on what the new rendering limits are?
>>>>>>         
>>>>>>           
>>>> _______________________________________________
>>>> 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