[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