[sldev] Re: Why does the simulator do object culling for clients?
Adam Frisby
adam at gwala.net
Wed Jul 18 12:11:31 PDT 2007
Incidentally, removing this logic from the simulator results in a pretty
heavy cutback on CPU requirements for the server in my own experience,
since you can pretty much ditch the whole 'interest list' thing, without
really affecting the client too much (although your bandwidth bills will
go up).
Adam
Douglas Soo wrote:
> Actually, objects diappearing when you're near them may be due to a
> client side culling issue. Moving the camera shouldn't generally cause
> objects to be unsubscribed - camera position and direction is used for
> determining which objects to subscribe to first, but for the purposes of
> unsubscription, I believe that only your avatar position is used.
>
> The subscription and unsubscription logic needs a lot of work, and will
> likely eventually be moved to be viewer-side. I leave it as an exercise
> for the reader to figure out what the optimal strategies for this are. :)
>
> - Doug
>
> --On Wednesday, July 18, 2007 12:37 PM -0500 Argent Stonecutter
> <secret.argent at gmail.com> wrote:
>
>> On 18-Jul-2007, at 12:10, Douglas Soo wrote:
>>
>>> The ObjectKill message is a message that is sent when your agent on
>>> the simulator has decided to unsubscribe to an object on the
>>> simulator. The primary reason why it needs to be send is that once
>>> your agent on the simulator isn't paying attention to objects, it
>>> won't send further updates to the viewer, which will cause lots of
>>> interesting artifacts in the case of objects that change when you
>>> aren't subscribed. In particular, moving objects can cause quite a
>>> headache (ghosting, etc.) - so the correct behavior is to cull the
>>> object from the viewer completely.
>>
>>
>> Interesting. This explains the problem where objects vanish while you're
>> cammed in near them, because the subscription list is based on your
>> physical position rather than your camera position. I was thinking that
>> letting the client handle the *un*subscription would alleviate this
>> problem, but obviously it's more complex than that.
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
More information about the SLDev
mailing list