Everybody face east ... please?

I'm chasing myself around the block this morning and getting dizzy. I have a link set in which each of the prims is facing a random direction, and I want them each to face (global) east. I can't seem to get them to do it. I've experimented with several things and have read through Void's rotation page and the stuff in SVC-93 regarding rotation of child prims, but my head is starting to hurt. Anyone care to toss me a suggestion that works .... or an aspirin?

ETA: For what it's worth, I can get CLOSE to where I want. The following snippet at least gets everyone facing the same direction as the root prim....

integer PrimCount = llGetNumberofPrims(); 
rotation RootRot = llGetRootRotation();
while (PrimCount-1)
    {
        llSetLinkPrimitiveParams( PrimCount--, [PRIM_ROTATION, llEuler2Rot(<90,0,0>*DEG_TO_RAD) /RootRot] );
    }

.... just not all facing east.

/me is curious what happens if you take out that division by the root rotation..

edit: not because I think I know the answer but because it's probably the first thing I'd try after running in circles for a while.

Thanks. I put that division in there out of desperation. My intuition says that it should be multiplication, but SVC-93 convinced me that maybe division was the way to go. At last doing it this way gets everyone facing the same way (although I have other problems in the script that mess it up again later, but that's a different story .... ). I just can't figure out how to get the "same way" to be global east. Matrix algebra makes sense to me, but this application is still black magic.

Rotations always make my head hurt..

I think division is actually the correct thing there. I usually think about it as adding in a rotation uses * and taking a rotation out uses /.

So "I want this to be rotated so it points to the left of the way some other thing is rotated," you'd use * to multiply 'left' and the way the reference object is rotated. Going the other way, taking a rotation out of the result, should use /. I think.

What happens when you take the / out?

edit: and we're not talking about an attachment here, right?

edit edit: finally browsed through svc-93. You tried this bit??



edit edit edit: /me tries the above in opensim and it seems to work. No idea if the opensim folks carried svc-93 over there or not but the child prims all seem to point E now.

Try this:

default
{
    touch_end( integer n )
    {
        integer pn;
        for ( pn = 2; pn <= llGetNumberOfPrims(); pn++ ) llSetLinkPrimitiveParams( pn, [PRIM_ROTATION, < 0.0, 0.0, 0.0, 1.0 >/llRootRotation()/llRootRotation()] );
    }
}

It works (big LOL)
< 0.0, 0.0, 0.0, 1.0 > (no rotation) turns all childrens X axis towards east.
Explanation: < 0.0, 0.0, 0.0, 1.0 >/llRootRotation() is east compensated for the rootrotation.
The extra /llGetRootRotation() make llSetPrimitiveParams do a local rotation.

Simple...

rotation root = llGetRootRotation();
llSetLinkPrimitiveParams(LINK_ALL_CHILDREN, [PRIM_ROTATION, (llEuler2Rot(< PI_BY_TWO, 0.0, 0.0> / root) / root]);

It looks like you want to rotate all children so... LINK_ALL_CHILDREN (And it's nice to see all the prims turn all together...)

And the rotation is an absolute rotation, relative to region axes, so you divide twice by the root rotation.

And don't ask why!

Thank you, Meade, Dora, and Kaluura.

I had the feeling I was getting close, but it looks like I still don't understand the logic well enough to have produced what you did on my own. I need to stare at your posts and scratch my head a bit more before it sinks in. Now I can't wait to get home to my desktop so I can get in world to try this out.

It ALMOST works, but the root prim doesn't end up facing east with everyone else. In fact, when I try to include any rotation of the root prim it rotates the entire linkset as a final step. Gotta keep thinking about this........

if you don't care whether the wole linkset ends up rotating, just set everything to zero rotation... (assuming +X == forward on your prims, otherwise set all the children that way, and then rotate the root to whater passes for forward)

if you want them to all align in place, you have a new problem, because you have to move all child prim positions to rotate the root and have everything stay in it's sim relative position

Rotations are geometric aren't they? So East is 0 degrees and North is 90. Compass works the other way, of course, just to add another layer of confusion, lol.

Make sure to go forward, ++ not --, in the loop.. The root prim is the first in the link set.

It's kinda normal... There is (alas) no instruction to rotate the root without also the whole linkset.

Any way, I think I understood that you wanted to rotate all the prims of an object toward east. Here is something that looks like to be working. I hope you don't look for some pretty movement here... It ain't pretty!

default
{
    touch_start(integer total)
    {
        rotation east = llEuler2Rot(<0.0, 0.0, PI_BY_TWO>);
        rotation root_rot = llGetRot();
        vector root_pos = llGetPos();
        integer num = llGetNumberOfPrims();
        for (; num > 1; --num)
        {
            vector child = llList2Vector(llGetObjectDetails(llGetLinkKey(num), [OBJECT_POS]), 0) - root_pos;
            // llGetLinkLocalPos(num) ...if such a thing existed
            llSetLinkPrimitiveParams(num, [PRIM_POSITION, child / east, 
                                            PRIM_ROTATION, ZERO_ROTATION / root_rot]);
        }
        llSetRot(east);
    }
}

You owe my just a new head... (My old one exploded in the process) ...and a night of sleep. (It's 5AM! Damn!)

WooHoo! It works! And it is pretty. I had no idea this was such a nasty one to figure out. Thank you, Kaluura.

I thought this made sense the other day, but I've been poking at it and have made a couple of troubling discoveries that tell me I don't have a firm grip on it yet. Here's a stripped down version of the script Kaluura put together so carefully....

default
{
    touch_start(integer total)
    {
        rotation east = llEuler2Rot(<0.0, 0.0, PI_BY_TWO>);
        rotation root_rot = llGetRot();
        {
            llSetLinkPrimitiveParams(2, [PRIM_ROTATION, ZERO_ROTATION / root_rot]);
        }
        llSetRot(east);
    }
}

It does exactly the same thing as her script did, but without the tricky business of determining a child vector and using llSetLinkPrimitiveParams(2, [PRIM_POSITION .....]). This is actually what I think Void was suggesting .... all I have to do is set all prims to ZERO_ROTATION and I'm home free. That was my first troubling discovery ..... all the business with trying to set PRIM_ROTATION wasn't necessary. The second discovery was that it doesn't do ANYTHING AT ALL. In fact, I can't change the relative positions of any child prims in the linkset no matter what I do. I have tried

        vector root_pos = llGetPos();
        llSetLinkPrimitiveParams(2, [PRIM_POSITION, root_pos + < root_pos.x + 2, 0,0>/root_rot/root_rot]);

which I would have expected to move the child prim 2m along the root prim's X-axis and at the root's Y and Z, but no soap. Absolutely no movement. I've tried all variations on the theme (including a lot of really outlandishly stupid ones) and they have no effect whatsoever.

I'm really trying to understand this puzzle, but I think I'm still missing a piece. If I [highlighted]wanted[/highlight] to move each of the child prims, how would I do it?

This is probably way too dumb a suggestion, but just in case; this wouldn't be anything to do with the viewer bug that stops it from updating small changes in a prim until you right-click or do something drastic to it?

The argument:'root_pos + < root_pos.x + 2, 0,0>' may be bigger then 10m or too far for the prim to stay linked, so the call is silently ignored.

AND you shall not have the final '/root_rot' for a position only for the rotation

You're probably right on your second observation, Dora. I'm still not comfortable with that part. As for the first point, though, I've been testing with a linkset that has two prims within a couple of meters of each other, and I want to move the child to a point that is only 2m from the root. I don't think there's a distance limitation here.

The basic point, though, is that I have tried putting all sorts of arguments there. None of them work. llSetLinkPrimitiveParams(2,[PRIM_POSITION .... fails silently no matter what argument I put there. So far, anyway.



Not likely, Pete. This is not a change in the prim's properties, but in the prim's position. As the experiments with rotation here show, you can certainly address some aspects of a child prim's orientation in space with llSetLinkPrimitiveParams. I just don't understand how to address position.

llSetLinkPrimitiveParams([PRIM_POSITION]) is the same as (non-existing) llSetLinkLocalPos(). In other words, this function set the (un-rotated) offset of a child prim relatively to the root... So, when you use [PRIM_POSITION, root_pos + < root_pos.x + 2, 0,0>], you are trying to send this poor child prim out of the sim.

Because of the link limits, it may work but only if the root is very close from <0, 0, 0>. With your "formula", assuming you work over the common water level, you are already trying to send the child 20m away... on one axis.

To set a child prim 2m ahead of the root in the X direction:

[PRIM_POSITION, <2, 0, 0> / root_rot]

Simple, no?

Hmmmm... Thanks, Kaluura. I'll give that a shot when I can get in world from the home computer tonight. Heck, I'll try anything if it helps me understand how prim movement works in a linkset.

I'm still puzzled, though, Kaluura. You did an elegant job with the script you posted earlier in this thread ... a script that, in part, seemed to reset PRIM_POSITION ... and yet if I isolate that one part of the script and run it by itself, it fails silently. If I remove the PRIM_POSITION part of the llSetLinkPrimitiveParams call, it has no effect on the way the script works either. I think I'm missing some key point about child prims, because it seems as if your method SHOULD make a difference. You obviously thought it should, and it made great sense to me too until I tried taking it apart and playing with it.

valid link distances are determined by prim sizes of ALL prims in the linkset.... and the small the prim, the smaller the valid distance...

Hmmm... Are your prims the one over the other and over or below the root? If yes, then the part which set the position has no visible effect... and is useless. The same applies once the root is rotated toward east. In both cases, the child prims already have the position they will have when the root will rotate or not.

My script is meant to work whatever the position of the child prims and whatever the initial rotation of the root. Rotate the root to some awkard position, move and rotate the child prims randomly all around it and you will see a difference.

Once thing to always remember is that when the root rotates or moves, the child prims don't. Whatever they may look like to be doing, they don't move nor rotate. They live in a small universe around the root and know no other axes than the ones of the root which, from their point of view, is *not* rotated.

Moving is relatively easy in such a system but things become messy when you want to align the child prims relatively to the region axes... which are moving for them when the root rotates... especially when you have to fight against the bugs *somebody* attached to the rotations. (Let's do not name people.)

Thanks, Kaluura. It's slowly sinking in. It's a reference frame problem. I didn't realize that I was supposed to be thinking in a local reference frame, so I was trying to cast everything in a global frame. I appreciate your patience. I'll keep experimenting with variations on the theme until I'm confident that I understand what's happening and can apply it in different settings.