[sldev] Why does the simulator do object culling for clients?

Tateru Nino tateru.nino at gmail.com
Wed Jul 18 08:38:02 PDT 2007


Considering the amount of ghosting we generally see (due to lost
ObjectKill packets), I'm wondering if it isn't a good idea for the
viewer to be able to periodically poll 'stale' objects (ones that have
had no Update for a while) just to verify that they're still present.
Having avatars and objects that have long since gone hang around in your
viewer for an hour or two - that can be a little odd, or even unsettling
at times.

Dale Glass wrote:
> On Wed, Jul 18, 2007 at 03:54:42AM -0700, John Hurliman wrote:
>   
>> As you move around in a simulator, the sim is constantly sending 
>> ObjectUpdate* packets for objects that become within range or have 
>> moved, and it sends ObjectKill packets for things that go outside of 
>> your vision. Then when you move back to that area it sends the 
>> ObjectUpdate* packets for those objects again. Is there a reason this 
>> culling is done across the network by sending ObjectKill packets for 
>> things that are not actually leaving the simulator?
>>     
>
> My guess:
>
> Suppose the sim didn't do that. In that case, the viewer would never
> know when the sim decided the object is too far away. So you'd need to
> have the viewer perform its own culling, or you'd have extra objects
> hanging around.
>
> If the culling on the viewer and sim didn't match, you'd end up with
> updates being sent for objects the viewer won't show, or the viewer
> showing objects for which the sim isn't sending updates.
>
> And since the sim determines which objects are near enough to notify you
> about their existence, it's only logical that it'd do the kill
> notification as  well. Less error prone, and avoids duplicating code.
> Sim needs to know which objects are far enough anyway, as it has to
> decide when to stop sending updates.
>
> Note: This is only a rather uninformed guess, as I can't look at the
> source ATM. 
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   

-- 
Tateru Nino
http://dwellonit.blogspot.com/



More information about the SLDev mailing list