Transfer sittarget data from one prim to another, is it possible?

I'm using a utility like PrimSitter to embed sit poses into furniture pillows. No problem for single poses. But I also have couples cuddle poses. Up till now I had two poseballs for cuddle poses: F+M. But I also want to embed these two poses into two pillows.

Here's the problem: my F+M cuddle poseballs are so perfectly aligned to eachother, that it's almost impossible to get the same alignment using a PrimSitter-like utility for first the F and then the M position. Mainly because I've offsetted each animation in Poser, so an avatar stands up in front of a couch and not on the couch. The animation is therefore not at the center of the PrimSitter helper-prim which makes rotating/adjusting very difficult. Btw, I want to keep the animation offset, no compromises.

I'd like to know if the following is possible:

- Rez a poseball with an ani and sittarget and position it on the couch exactly where I want it. The poseball-prim will have its own rotation on all axes.
- Rez a (sculpty) pillow on the couch so it looks right on the couch. Also this prim has its own rotation on all axes, and... different from the poseball's rotation.
- (after adding animations and necessary scripts to poseball and pillow) Simply touch the sculpty pillow prim: the exact position of the animation in the poseball AND the position/rotation of the poseball prim itself get transferred to the pillow prim, so that the animation is now embedded in the pillow prim and the avatar sits at the exact same position where he sat when sitting on the poseball.

Pic 1: this is how precise the cuddle ani should be.


Pic 2: the desired transfer process (when possible)


I hope I explained this correctly. Is this by any means possible? I don't ask you to post any scripts here, I only want to know if it's technically possible or that I should search for another solution.

I believe it should be possible, but there is a bit of stupid, hackish math that you'll have to do because of defects that have been present in sit targets since the very early days of SL (defects they are never likely to fix because it will "break" existing products).

There is a set of scripts called, I believe, "Easy Sit Target Positioner," that will show you the calculations you need to perform. It was written by Lex Neva. A search in this forum or maybe the Script Library forum (or maybe even the LSL wiki at this point) should come up with it.

Actually I just thought of something. If you are willing to go through that whole scenario from setting up the poseball to transferring to a sculpty or whatever, you might consider a dynamic solution with llSetLinkPrimitiveParams(). If you use that in BOTH the poseball and the final prim to move the sitter into the right position after they sit, you should be able to get exact positioning without having to deal with crumby old SL defects regarding sit target position. You can also set the sit target CLOSE to the final position but ignore the buggy offsets, in order to make the post-sit movement less noticeable if there is any lag.

Hi Hewee, thanks for your reply. I think I know what you mean. But... are sit targets the issue here? I mean the following. I'll try to explain as good as I can, because English is not my first language.

- The animation has an offset, made in the animation program. I'm using the same animation for poseball and pillow prim. I other words: when I would position the poseball and pillow prim at the exact same position and rotation, and use the same sit target for both prims, the sit position would also be the same for both prims. So my conclusion is: animation offset doesn't play any role, is that right?

- Now sit targets: it's true that at the moment I should use different sit targets for both prims. But (if I'm right) that is only because the two prims have different positions and rotations. If these prims would be positioned and rotated exactly the same, the sit target could also be the same for both, yes?

So what I was thinking is this:

- The poseball prim has its own XYZ position in-world
- The pillow prim has its own XYZ position in-world

That could be mathematically be transferred pretty easily by script from one prim to the other, right?

- The poseball prim has its own XYZ rotation in-world
- The pillow prim has its own XYZ rotation in-world

Is this where the problem is? Is there a mathematical recalculation possible for it? Maybe even in script steps: first X, then Y, then Z.

In other words: tackle the problem not from the sit target viewpoint, but from the prims position and rotation viewpoint. Unfortunately my mathematical skills and scripting skills are not so good, so maybe my reasoning doesn't make any sense. But still I have a gut feeling that the issue could be solved somehow.

[EDIT] Oops, indeed I am missing something here. The pillow prim doesn't have a sit target yet. The sit target should be 'copied' from the donor poseball prim into the pillow prim, and at the same time be recalculated using the difference in both prims position and rotation. Damn! Oh boy, this is way more complex than I thought.

Hi Paulo~ how many animation will you be using in each pillow? If you're using only 1 animation on each of them, i have a item which you may be interested in.

I'd not list the link here coz it's not a product ad forum. Contact me in-world if you're keen to find out more

Paulo,

You have the right idea. You want the avatar to sit at same position and rotation relative to the whole object (the root prim, let's say). So you have to account for the poseball's position and rotation relative to the object's root prim, then you have to account for the cushion's position and rotation relative to the root prim too.

Ideally, the relationships would look like this:

(Definitions)
avPosG, avRotG - avatar's position and rotation in global coordinates
avPosR, avRotR - avatar's position and rotation in the root prim's (object's) coordinates
avPosC, avRotC - avatar's position and rotation in the child prim's (e.g. cushion's) coordinates
rootPosG, rootRotG - root prim's (object's) position and rotation in global coordinates
childPosR, childRotR - child prim's (e.g. cushion's) position and rotation in the root prim's (object's) coordinates
sitPos, sitRot - sit target position and rotation

avPosC = sitPos
avRotC = sitRot
avPosR = (childPosR+avPosC)*childRotR
avRotR = avRotC*childRotR
avPosG = (rootPosG+avPosR)*rootRotG
avRotG = avPosR*rootRotG

Unfortunately, due to those sit target defects, the sit target position (sitPos) is NOT quite the same as the avatar's actual position relative to the child prim (avPosC). That's why when you use llSetLinkPrimitiveParams() you don't get quite the same position as when you use llSitTarget(). And it is really screwy how they differ. Something like a little z difference in the avatar's local coordinate system and a little z difference in the GLOBAL coordinate system. Really, really messed up. But if you use llSetLinkPrimitiveParams() as a replacement for llSitTarget(), you can get around this.

You MIGHT also be able to set the sit target in the pose ball, then use llGetObjectDetails() to get the avatar's actual position and rotation (I think those'll return global values even if the avatar is sitting?), then transform them into the proper (cushion) coordinate system and use llSetLinkPrimitiveParams() from there.