Child rotation is the rotation of a child prim in relation to its parent (instead of in relation to the world). This comes into play when moving (rotating) parts that are in a linked object that can itself be rotated.

An example of child rotation is a car door. No matter what direction the car faces, the doors are probably expected to always open outwards and rotate around their hinges.

The usual way of rotation using

Or, if to do it manually for some reason (such as perform a local rotation with a

SetLocalRot(rotation localrot) { llSetRot(localrot / ( (ZERO_ROTATION / llGetLocalRot()) * llGetRot())); }

- The
operator rotates the rotation on the left by the inverse of the rotation on the right. It has nothing to do with division.`/` - This does not work for attachments as
`llGetLocalRot`and`llGetRot`behave differently when in a prim that is attached to the avatar.

The same in more detail (and with the inverting done manually):

rotation Inverse(rotation r) { r.x = -r.x; r.y = -r.y; r.z = -r.z; return r; } rotation GetParentRot() { return Inverse(llGetLocalRot())*llGetRot(); } SetLocalRot(rotation x) { llSetRot(x*Inverse(GetParentRot())); }

SetLocalRot(rotation localrot) { llSetRot(localrot / rootrot); }

(1) first pi/2 about the world's z-axis...

(2) then pi/2 about the world's x-axis...

The final rotation would be:

Note the order of operations.

(1) first pi/2 about the object's z-axis...

(2) then pi/2 about the object's x-axis...

The final rotation would be:

This last example is useful for when a script computes a small incremental rotation in the object's local frame (call it

Below here needs its "you"/"your" reworded. -EepQuirk

Now, after that

Step 1: First, you need your basic linked object. Any linked object will do.

Step 2: Rotate your linked object, so that the parent of the set is at

Step 3: Locate your child object that needs to be rotated. Go into edit mode and check the box next to "Edit Linked Parts". This will allow you to select prims in the set individually

Step 4: Select the target prim, and unlink only it from the set. Now, right click the target prim again. The target prim should now have a gold halo around it, and should be movable seperately from the set.

Step 5: Rotate the target prim to the rotation you want it to be at. Then, put this script into it:

state_entry() {

}llSay(0, (string) llGetRot());

}Step 7: Repeat steps 5 and 6 until all rotations of the object are covered.

Step 8: Link the child prim back on to the set.

Step 9: Rotate the parent of the set back into its original rotation.

Step 10: When passed the values you got in step 6,

Getting things to work out with attachment prim rotations is challenging because of trying to rotate child prims relative to the root prim of the attachment and not the avatar rotation. Here's the breakdown of the various functions in different situations:

llGetRot | object global rotation |

llGetLocalRot | object global rotation |

llGetRootRotation | object global rotation |

llGetRot | object global rotation + prim rotation |

llGetLocalRot | prim rotation |

llGetRootRotation | object global rotation |

llGetRot | avatar rotation |

llGetLocalRot | attachment rotation |

llGetRootRotation | avatar rotation |

llGetRot | avatar rotation + prim rotation (BOGUS) |

llGetLocalRot | prim rotation with respect to the attachment root prim |

llGetRootRotation | avatar rotation |

Basically, what's going with attachments is that the avatar sort of becomes the root prim and replaces its rotations for the attachment root prim rotations.

There's a couple things to take note of here. One is that there's no way to directly tell what the attachment rotation is from a script within an attachment child prim. That makes it a bit hard to make root prim relative adjustments to rotation.

The other is that llGetRot returns a completely bogus value from a script in an attachment child prim because it's actual rotation is

For example, create two prims and link them. Set the child to have a rotation of 30 deg in the Z axis. Attach the object to your skull or somewhere appropriate. Then rotate the whole attachment 45 deg in the Z.

Then using this handy script:

out(string message) { llOwnerSay((string) llGetLinkNumber() + "> " + message); } vector deg(rotation rot) { vector eul = llRot2Euler(rot); eul *= RAD_TO_DEG; return eul; } default { touch_start(integer count) { if (llDetectedKey(0) != llGetOwner()) return; out("llGetRot: " + (string) deg(llGetRot())); out("llGetLocalRot: " + (string) deg(llGetLocalRot())); out("llGetRootRotation: " + (string) deg(llGetRootRotation())); } }

You will get results similar to these:

Root 1:

Root 1:

Root 1:

Child 2:

Child 2:

Child 2:

Looking at the child's

Having

Functions | Rotation

Comments [Hide comments/form]

Okay. This page wouldn't suck so much if it had a definition of what, exactly, Child Rotation was and some other clarifying prose. I'd add it if I had any idea myself.

-- ChromalBrodsky (2004-04-25 20:37:03)

So is llSetRot / llSetPrimitiveParams([PRIM_ROTATION,...]) broken now? From reading this page, running "llSetRot(llGetLocalRot())" should be a null operation; however, when I try it, that line only works as expected if the root object's rotation is ZERO_ROTATION.

-- NeoRebus (2004-07-10 13:26:25)

This page needs the ACL's set so only registered users can edit it.

-- DolusNaumova (2006-07-11 08:52:02)

Attach a comment to this page: