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

[Jake Simpson]

Argent Stonecutter wrote:
> Lots of interesting information there, Jake.
>
>> Right now, as has been mentioned, unsubscribe / subscribe is UDP and
>> will probably need to remain that way since UDP as asynchronous and TCP
>> is not - if object updates are coming via UDP (and they need to, trust
>> me on this.
>
> Seems to me that if you go through with the "informational" 
> subscription mechanism, then the subscriptions could be sent TCP since 
> if something like TCP congestion causes a late subscription that just 
> means a later ACK.
>
>> Further to this there are other things to be tried, like not sending
>> positional updates at all, but only sending velocity changes.
>
> This approach would seem likely to make the existing problems with 
> rubberbanding exponentially worse.
>

What issues specifically do you mean? I totally believe they are there, 
just trying to get a feel for what you guys feel they are?

> Sending position updates less frequently, or only when you get a 
> velocity change, OK. But I suspect you still need to send position 
> updates more frequently than you're going to want to be sending full 
> updates.
>
>> If you don't remove those
>> objects from the stream that are not considered within the clients
>> perview (and not just frustrum perview as most FPS games have it - you
>> need to be able to consider objects behind you to ensure you get sounds,
>> particles that overlap your view and so on) then it doesn't take long
>> before your stream is *full* of objects you can't see, don't care about
>> and yet are getting updates for you don't need.
>
> Absolutely. I was just thinking that the client is already doing most 
> of the analysis anyway.
>
> What about this scheme? The client could send a kill for an object to 
> the server when it gets an update on the object and it determines that 
> it's out of range. That way if the server "lost" a kill from the 
> client, it would sync up quickly.
>
That might well work. Definitely worth investigating. I would just be 
concerned that if that was the only way an object is removed from the 
update stream then someone with a hacked client could then just sit in a 
sim and slowly start eating all the network bandwidth because they never 
send back a Kill message. Griefing, unfortunately, is something we have 
to consider which is why I more prefer to keep this sim side than not.

>> It enables people to ask the sim for
>> information about objects they can't see in an attempt to cheat at
>> games, and generally see stuff they don't have the permissions to see,
>
> Unless there's going to be some kind of genuine privacy scheme 
> implemented in SL (which is another topic near and dear to my heart, 
> but not one I'm going to go into now), I don't think there's much that 
> the client can't see in the sim it's in. The longest diagonal in the 
> building zone of a sim is 849 meters, which means that an agent at 
> <128,128,384> with a draw distance of 512 can see any object in the 
> sim. Worst case, you can see well over 50% of the volume of the sim 
> from any point in the sim, and from a corner you can see well over 50% 
> of the volume of four sims at once.
>
> I think the only consideration given to the "privacy" issues of this 
> scheme are that a sim should kill objects for clients in sims more 
> than two sims away. That's a *cheap* calculation, and more an 
> optimization than anything else.
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html