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

[Adam Frisby]

Animation physics is something I may be assigning a developer to soon - 
it's something we would be really keen to see. Unfortunately to do it 
properly we need that ragdoll avatar packet support into the client.

It may be worthwhile trying to contract Jeff Ventrella who was working 
on that to see if he still has the patches or the ability to get them 
(albeit in a limited beta form) into the client somehow.

Regards,

Adam

Melanie 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
>