[Opensim-dev] another little can of worms: attachments :-)

[dan miller]

> * I understand this to mean that the attached prims actually don't 'move'
> as in 'changing coordinates' during an animation, so that even if they
> move on the screen, they don't move representation wise; nothing actually
> is communicated or changed. Is this correct? (this would mean that there
> is no way of ever processing physics on attachments)

hmm.. not necessarily?

> * What is meant with "ALL the above is client side"? Surely, the rotation-
> and position offset changes are updated on the server and then transmitted
> to the client?Best regards,
> Stefan

[melanie:]
> > Attachment: in world, phantom, and always rooted at the avatar's 
> > center of mass. The true offset of an attachment from
> the avatar's > > physics center is always 0,0,0. The asset contains a
> separate set of > > offsets, which are a display offset. This is added to
> the offset for > > the attachment point, clientside.

ISTM that with some serious thought, you might be able to use the asset's
display offsets to do some physics.  The problem you will run into I think
is how to synchronize the server side with the client.

In general, it seems to me that the sorts of animations the client takes
care of are considered too rapid and complex to be done server-side and
faithfully transmitted, given the state of the server/client comm protocol. 
Without some sort of synchronization algorithm, it's bound to fail.

It might be instructive to look at how OpenCroquet deals with this issue --
it's much more conceptually solid (though I have doubts as to how it scales
in real-world scenarios).  As I understand it, all the client machines run a
sort of 'physics' in perfect synchronization.  I'm putting physics in quotes
because in fact it's really a language to represent object movement, and
objects can have various physical properties such as the ability to collide,
various dynamics and so on.  It's a very elegant solution as it eliminates
two distinctions which are troublesome: server vs. client, and animation vs.
physics.  It seems to me there would be some trust issues with this model,
but in an intellectual sense it's very clean.

It's also interesting to think about how VOIP and video streaming work.  In
these applications, you explicitly synchronize the end points with a fixed
latency buffer, which is long enough to cover the worst-case network
latency.  This allows you to transmit time-based events smoothly over the
network.  LL's UDP model seems to have no notion of time; packets are
received as soon as they're available, and there's no knowledge of when they
were sent (am I right about that?)  This is what makes server-side
animations or even synchronized client/server motion impractical.

At least that's my uninformed opinion.

-dan