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

Fri Jan 4 20:27:59 UTC 2008

I agree - thank you for this very enlightening writing! (It really should be copied up on a wiki somewhere)

This said, I have two questions (that are probably noob++ and rtfc/rtfw but hey...) just to be sure I understand the situation;

* 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)
* 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

> Date: Fri, 4 Jan 2008 11:31:20 -0800> From: danbmil99 at yahoo.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] another little can of worms: attachments :-)> > 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> > > > _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080104/8416200e/attachment-0001.html>