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

[dan miller]

great exposition!  This really helps me understand the situation wrt SL
servers.

However I think it's worth considering what we can do that goes beyond
Linden's implementation, but stays compatible with the client.  What you
describe with tinys and attachments is really an elaborate kluge to avoid
the limitations of Linden's server-side architecture.

Since the client is basically constructed as a 3D viewer, and knows nothing
about physics, it seems to me there is an opportunity to think about
attachments in a much more reasonable way.  The subtleties arise when you
start thinking about how animation interacts with server-side movement.

Even without getting into attachments, the whole paradigm of the avatar
represented as a simple bounding volume can be called into question -- but
this probably leads inevitably to client-side changes, such as animations
with physics, as Adam suggests in another post.

In my dream world, there is no distinction between physics and animation. 
What we call animation today would be translated into physics commands,
which would be implemented using control logic on top of virtual forces.  At
that point, it would generally be impossible to animate something that is
physically unrealistic, such as two body parts interpenetrating.

The key to making this work is to understand the relationship between server
and client, and managing the unavoidable latency between the two.  What I'm
still unclear on is how far we can go without requiring changes to the
client protocol.

-dan


--- Melanie <melanie at t-data.com> wrote:

> Hi,
> 
> Dalien Talbot wrote:
> > 1) from Dan's: "how are the 'huge dino' avatars are made - whose height
> is
> > above the max height of the avatar"
> 
> Simple...
> 
> You can make an animation that offsets the visible avatar from the 
> true position. Now, the physics aspect is very interesting:
> 
> For the purpose of physics, an animation doesn't cause the avatar to 
> move at all!
> The avatar is always represented in physics at the point where the 
> server sees it, as it's bounding box, at it's position.
> 
> Now, your wyrm avatar:
> 
> For physics, the avie is located at ground level. Typically about 
> where the legs are. So, you can bump into the legs. You actually 
> bump into the avatar!
> The animation lifts the _visible_ avie 5 m into the air, sets it at 
> an angle and folds in the arms and legs, so that the avie is 100% 
> within the dragon body.
> Finally, the attachments are put on. They are attached to the limbs, 
>   which makes for some unusual joint translations. That is why these 
> avies have their own set of animations, AO style. They are phantom.
> 
> If you want to do battle with this dragon, you have to attack it's 
> legs, since, for collision purposes, that's where the avatar is. The 
> translation which is effected by the animation is simply not a 
> factor here.
> 
> Try to collide with such a beastie while flying - you'll fly 
> straight through it!
> Airspace above a Tiny? No, you'd bump into an avatar. Tinies cannot 
> go through tiny doors! The door must be at least the height of the 
> bounding box of the shortest possible "normal" avatar.
> 
> So:
> Physics: serverside, bounding box @ position. That simple.
> Animation: clientside. It has no bearing on physics interaction, 
> even if it visually translates the avatar somewhere else.
> 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.
> 
> In an attachment: (from memory)
> llGetPos() = world position (avatar center)
> llGetLocalPos() = offset from attachment point
> llGetRot() = world rotation of the AVATAR. The looking direction is 
> always parallel to the ground plane, unless in mouselook.
> llGetLocalRot() = rotation at the attachment point.
> llGetRootRotation() = llGetRot()
> 
> llSetPos() = sets attachemnt point offset
> llSetRot() = does nothing
> llSetLocalRot() = rotates attachemnt.
> 
> ALL the above is clientside!
> 
> Attachments are phantom, but collisions of the AVATAR trigger 
> collision() events in attachments.
> 
> Attachments can enable physics. That makes them no less phantom, but 
> allows them to use damping motion to move the AVATAR. This is how 
> the windwalker/wallwalker work. The object, going physical, actually 
> just links their physics functions the the avatar's physics.
> 
> Here is a little bug that LL has in there: If a script makes an 
> attachment physical, and the script is then restarted/resaved/reset, 
> the attachment will not behave as a physical attachment anymore, but 
> will claim it is one. So, physics can not be re-enabled, since the 
> LSL interpreter thinks it already is.
> In order to edit/test a script that does physical movement, you need 
> to unwear and re-wear the attachemnt, which resets that flag.
> 
> Weird, but I make weapons, I know. I wish there were swords that 
> actually collide with the avie they visually hit!
> 
> Melanie
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>