On Wed, May 02, 2007 at 08:28:49AM -0700, Ken Taylor wrote: > First of all, a question: Would it make any sense to start a "VOS > Development" mailing list separate from this discussion one? I hate clogging > the list with all my posts about build problems and such, but also don't > feel good about just sending it directly to the main developers -- there may > be other people out there looking at the code who would be interested.
Vos-d *is* the development list. If people don't want to see the daily grind of software development that is discussion like this, they should join the announce list. Presently there isn't enough traffic to justify splitting vos-d up, and also it's my experience that unless there is a clear line between "developers" and "users", it is better to keep everyone on the same list so that everyone sees all of the discussion. > send velocity vectors along with position, or discern velocity from previous > updates, and keep moving the objects out along their current path. However, > while this works when everyone's going pretty straight, it can lead to > distracting artifacts when there's lots of starting and stopping or changing > direction.) Since there's already network lag, lagging a little bit more is > an acceptable tradeoff for much smoother looking motion. VOS s3 used extrapolation, sending position, velocity and acceleration and seemed to work pretty well, but we never really tested it in cases with a lot of rapidly changing motion. I feel like you should be able to get good results from an extrapolation approach using control theory and filters (to smooth out network lag and jitter) but there's still the common edge case where someone stops, the system over-compensates for their motion and then "snaps back" like a rubber band. I see how interpolation is a simpler solution to the problem. > There's one big difference between the network activity of games like > Half-Life 2 and of VOS: Online games usually use a known, fixed update > heartbeat, and differences in packet arrival times are generally due to > network jitter, server lag, or dropped packets. As far as I could tell, VOS > has no such update clock, and my measurements of movement arrival intervals > varied between 30ms and 240ms for just walking an avatar across the screen > on the interreality world server. Usually the history buffer size is around > 2x the update period, but 500ms of lag would have been a bit much. So I > chose a default buffer size of 250ms for now (Half-Life 2 uses 100ms) -- but You're right, VOS is not clocked, due in part to the current multithreading design that encourages asynchronous "anytime" execution of tasks. This is something we may need to revisit in the s5 design, actually, and I'd be interested to hear your thoughts about it. I should note that the VIP low latency protocol used for sending out position updates does use a 100ms clock. Also you might want to compare your ICMP ping times with your VOS ping times just to get an idea of how much of the variance in latency is inherent in your connection to interreality.org. > that can be changed by the application (and in the future, perhaps an > adaptive buffer size would be doable -- not sure if it's worth the effort, > though). The variable update period doesn't affect the algorithm greatly, > but a few things are affected -- for instance, when an object starts moving > from standing still, I don't know whether that update represents 30ms of > movement or 240ms. I assume worst case for now and interpolate starting > movements over the full 250ms, which looks fine in most cases, but also > leads to a weird "slow-start" effect in others (such as jumping). I may tune > this parameter a bit before submitting my changes. Something that isn't exposed currently, but probably should be, is the current round trip time reported by the VIP layer. This gives you a smoothed value for the round trip time for the last N packets and is used by VIP to determine retransmits, estimate network congestion, etc. Having that data on hand would probably help make the interpolation smarter. > Another thing to worry about is teleportation -- not as common in VOS as in > FPS games (you teleport when you die), but it happens. You can always "Warp > to starting point" in Ter'Angreal, for instance. But visually you'd want the > teleport to look like a teleport, not like the object is zooming across the > sector really fast. The way I'm addressing this is having a "maximum > velocity" specified. Any object travelling faster than this between two > points is assumed to be teleporting, and is "snapped" to its position. There > is a default maximum velocity, and it can also be set per-object. In the > future, other ways to explicitly specify a teleport event might be possible. The "maximum velocity" approach makes sense. > [details snipped] > > And that's about it. I still have some things to work on (I haven't actually > done the key-frame updates in csVosA3DL yet; I started with the assumption > that syncPosition and syncOrientation only occurred on new property updates, > and then discovered that's not the case, and have to fix some things; I > haven't decided just how to deal with a doMoveTo applied to an object being > interpolated; model animation isn't in sync with the movement (it's not > being lagged); "teleport detection" isn't implemented yet; I need to handle > Ter'Angreal "grabbing" properly; etc) so it'll probably be another week or > so before I'm ready to submit it. But the basics are working, and it looks > pretty nice :) This sounds terrific! I have to talk to Reed, but since you've shown some dedication (and a willingness to wade through the CS plugin code, which is pretty much trial by fire) I will probably go ahead and set you up to be able to commit to the main branch on interreality.org -- I don't know when Reed and I have the time to merge your changes ourselves right now, but it would be a terrible shame to let this good work linger in the queue. -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
