|
|
|
I think the possible advantages are outweighed by the likely problems this would cause. I could see it becoming very common for your physics to get decoupled from the server's... everyone's connection is different. You'd be likely to have a different idea of where your avatar is than everyone else. If your client is actually telling the server where your avatar is, then slowness/bugs on your system will result in your avatar doing weird stuff in the view of everyone else. Lag on your end could result in people seeing you walking through walls. A hacked client could allow you to completely ignore, say, vertical walls. All in all, I think it's best to have one central authority for positions of avatars and their physics.
That said, though, some physics IS offloaded to the viewer: flexprims. I'm with lex on this matter.
Flex-prims are really only a visual candy though, they don't really do anything.
As for the latency issues; if you're lagging you already move strangely, in leaps or not at all, to you and to others. You also already see other avatars near you falling through things. At worst, this would require the server to do some processing on avatars who aren't sending updates as quickly as expected. Think of it in a flow like this: At stage 3 the server simply checks to see how far I've deviated from where it expects me to be. If I've deviated too far then I'd be forced to balance between the position my client says it now is, and where I was last noted by the server. If my updates are arriving too slowly, then my avatar will be stopped, or automatically switched to server-side calculation if the server believes it has enough spare processing power. Or potentially a mixture of both depending on the severity, i.e the server could calculate every 6 ticks and leave the rest to the client. At the least this would still significantly reduce the amount of physics processing by the server and simply require it to do some fairly simple logic (testing timestamps and doing vector distances) to decide what to do with an avatar. Leaving it with the responsibility of acting more like an information router to other clients, rather than having to bear the brunt of the work. If this reduced physics processing by even half it would considerably increase the available processing power of a simulator. As for the issue of hacked clients. We can already walk through walls. To prevent that (or to make it meaningless) we need better permissions systems, all of which would still be handled server-side; things like options to prevent objects being sent from disallowed parcels, or from disallowed sections of parcels (much preferred).
It would be no different than a client now that place you anywhere in the sim it likes, you just won't actually be there so won't receive chat etc. I think we just can't trust the client to handle this kind of important computation/information.
Think about how this system could be used for griefing. Even if the server tries to do some kind of smoothing out of errant positioning by the client, it might well be possible to make a client that causes your avatar to "vibrate", moving erratically all around within, say, a several-meter sphere. Why would this be useful? Well, the way griefing management currently works, if you can't right-click someone, you can't eject them from your parcel very easily. It's a serious pain in the butt even now if someone's moving around quickly while griefing your land. A "vibrating" avatar could very well be rendered nearly unclickable, making it difficult to read their nametag and impossible to right-click them, which is the quickest way to ban and eject an avatar from your land. Instead the land owner would have to go through the slow, painfully long process of opening the About Land window and banning manually, then wait for the auto-eject which can take awhile... and that's only if they can actualy see the person's quickly-moving nametag. That's just one example that comes to mind of why this may not be such a good idea. In order to counteract something like this, a lot of the physics calculations for the avatar done on the client would have to be reproduced and "verified" by the server anyway. This computation might well represent almost as much work as just doing the calculations on the server. Furthermore, the data produced by calculating avatar physics on the client will necessarily be less accurate than current avatar positioning data, because of the time it takes for the data to reach the sim. If you live on another continent from the sim's physical presence, traffic may take as much as 200-500 milliseconds to arrive at the sim... and then it'll have to be rebroadcast to all other clients. This will be visibly displeasing. So what I see is a limited computational benefit, a potential for mayhem, and a rather unpleasant performance drop. The issue of griefing is a failure of the current land-management tools. These are really a separate issue and need their own JIRA entry.
However, with the sim performing basic smoothing of the movement, it shouldn't be possible to do anything that we can't do already, as the server will be expecting a current position and a velocity vector from the client, meaning it knows where you think you are, and how fast you are moving and in what direction. Thus it is not possible to simple move from location to location without the simulator interpolating you when it passes your location onto other clients, or causing it to invalidate your results and ignore/smooth them. Therefore 'vibrating' your avatar would be no different from taking the current open-source client and simply programming in a 'vibrate' loop for your controls. Moving through walls is already possible, I can't really think of any other exploits. As for lag, same as above. Your client would be providing the simulator with a current location and a movement direction/speed relative to yourself. So if I send a position and speed, then one second later provide a valid new location and speed, then assuming the latency from me to the server has not changed, then it will agree with what I've calculated and allow me to continue calculating my own physics. When the server receives my location/speed information, it broadcasts this to all clients (including mine) so if I'm lagging horribly, then I'll keep getting put back and slow-down. Exactly as happens now if I'm lagging a lot. The client can compensate for this by sending physics results immediately, but waiting for my ping-delay before displaying the result. ie: 1. I press forward Conceptually it's a lot more difficult to consider how latency would be affecting this system, but ultimately it is the same in the end. Currently lag may cause me to move slower than others see me and get jerked around, this one may cause me to move faster than others see me, and get jerked around. Lag isn't going to make performance any worse really. And I've already mentioned auto-switching. If the user is lagging too badly, or the results coming from it appear invalid (validity checks are always going to be much simpler than calculating collisions) then the simulator can switch the user to server-side physics again, switching them back if their ping goes down, or their client starts giving sensible values again (ie the sim would flip back to client-side just to test every now and then to see if its improved). Clients who's performance is consistently poor when calculated client-side can simply switch to simulator-physics only. Even if a fraction of users switch to client-side physics it alleviates a large amount of physics calculation. For the most part the networking overhead would be worst then the physics calculation ATM. Havok 4 should drastically reduce physics load on the sims due to using better shortcuts. For the most part a lot of "non essential" items(read rotations, texture animations) are handled on the client side and don't take up much server resources.
Running a distributed model introduces many issues:
I'd like to see the client be smarter about physics, to reduce the effect of lag on what you see, but I'd rather not have internet latency between the avatar and the sim.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Offloading physics to the viewer
http://forums.secondlife.com/showthread.php?p=1674820#post1674820
An alternative is that avatar physics could be handled by an avatar farm. This would still offload physics for the avatar from individual simulators, but without placing it onto the viewer. This has the advantage of greater speed and security (no possibility of false values being sent*) but at the cost of requiring the extra hardware to run it.