Funny... the problems you mention actually result from a lack of semantics!
Consider the case of a specialized VR application like a game: You already know all possible actions a user can take, and your protocol usually transmits them directly. E.g. if a user wants to jump, the client sends a "jump" PDU, if he wants to teleport, you get a "teleport" PDU, and for regular continous movement a "movement" PDU. In contrast, "generic" VR platforms usually center around a common data model; the protocol covers synchronization of this data model among participants. The advantage is that you can have arbitrary user actions, as long as you can express them in terms of model changes (which are transmitted in corresponding PDUs). The disadvantage is that you loose application semantics in this process; the receiver only sees (possibly unrelated) changes in the data model, and has to infer the originator's action/intention from the changes. In the way Ter'angreal currently handles movement updates, this problem is also evident, since we don't really have a "movement" PDU in VOS, only "property change" PDUs. If a client moves his avatar, Ter'angreal changes the position and orientation child properties of the avatar, which results in two *different* update messages. A receiver has no way of knowing that these two updates are related, i.e. whether the avatar moved a bit and then turned, turned and then moved, or did both at the *same time*. Luckily this semantic problem is of no consequence to a human user, as the resulting differences in the visual presentation are too small to percieve. Teleporting or jumping are worse, since the resulting property changes are indistinguishable from those caused by regular continuous movement. You cannot really fix this with a "don't-interpolate" flag, as there is no good place to put one. You could extend the property- update notification, but a lot of properties do not use interpolation (hmm.... interpolate a nickname change? cool :-) My hope is that this problem might get smoothed over a bit in S5. I assume that both position and orientation will likely be embedded children of an avatar vobject. If you change both, you need to acquire the lock of the parent, change the values, and release the lock (ok, VOS will do this for you transparently). In this case, VOS should defer the update notifications until the parent lock gets released, and the send them all in an atomic "compund update" (message block?) which is semantically slightly closer to the actual user action. I am not quite sure how you could squeeze a "don't-interpolate" flag into the mix though - unless it is an actual embedded child of the avatar vobject, which is somewhat messy. The only *real* solution, both in S4 and S5, would be what the games do: Send a custom "movement" message... and loose the genericity of the VOS platform. Regards, Karsten Otto (kao) _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
