Can I rotate a child about an axis NOT positioned at its center?

Hello,
Is it possible to offset the position of the local axis about which
objects are rotated?

Please consider the following:

A clock whose face is the root prim, with a single hour hand as a
child. How can I make the hand rotate about an axis located other
than the hand's geometric center?

initial position:

--o-----

desired rotation:

|
|
o
|

Notes:
- For the clock I can use the trick of cutting hand object so the
center 'appears' to be at the base, but I'm looking for a
general solution for any shape, any rotation axis position.

- I can get this effect by linking the clock hand to a
phantom root object whose geometric center is coincident with the clock
face center. BUT then the question becomes 'How do I make an object
with a collection of linked sub-assemblies'. Once built, I would like
a single object to rez, move, etc...

- I have considered (after drinking heavily) using the link/unlink
commands in script to move a phantom rotation axis around at will.
However, I think a physical object would (literally) blow apart
if I unlinked it to rotate one of its children about this phantom
object.


Thanks,
ab

Yes, just use a non-linked object, and use whispers to communicate
- you can use the moving_end event in the clock to detect when its moved and send new position and rotation to hand objects
- send keepalives from clock to hands every second or so. If the hands havent received keepalives for a few seconds, they llDie
- rez the hands in the on_rez and state_entry events of the clock

Personally I'd just cut the hand and link it to the clock when possible, and use the above method for the exceptions.

Azelda

I'm not sure why you would NEED to offset it. There's plenty of ways to do this without getting horribly complicated but to start, we have:

http://www.badgeometry.com/wiki/ChildRotation

In the case of child rotation, you'll just want to rotate around a single axis in relation to the root prim, which is fairly easy. Assuming you're speaking of an analog clock, and your clock face is circular, the axis's should line up. Or you CAN just rotate the child prim all by itself in relation to itself I believe. (That does address your offset doesn't it?)

If it doesn't, you can always use an animation trick. Basically, you'll want to get the position(getpos) and the rotation(getrot) for each step you want the hand at, record all of these, then setpos and setrot the hand at the proper time.

All of the above can be done with linked messages without any prim cutting or linking/delinking (which requires avatar permissions). I still think you won't need to worry about an offset, but if you do, there's how you work around it.

I'm looking for this same feature too, which I believe doesn't exist. I made a pet moogle that uses child rotation to dance, wave, ect, but it works because the prims for the arms and legs are A: one single prim, and B: positioned with their exact center meeting the body-prim, in other words an equal amount of "arm" extends invisibly INSIDE the moogle to "balance" out the rotation. If I could manually set the rotation point I wouldn't have to do this, but since it is always the center of the prim, I have to put an equal ammt of arm or leg prim both inside and outside.

I've tried makingmore complex animations, such as a multi-prim tail out of torus pieces, using llSetLocalRot or llRotLookAt with llSetPos, and the result worked smoothly only on occasion, any sort of lag will cause pieces of the tail to move before others, and essentially the tail will "break apart", it doesn't get out of synch with the other pieces but one piece at a time will move to the new location.

I'm beginning to sound like a broken record here, but here are a couple ways you could do this:

1) Claymation Approach
Using several prims as "frames," you could (fairly easily) do a few frames at each point of rotation you would like. Most folks do this.

2) Some broken code for you, since I'm not at my home PC.

vector axisPos = <1,0,0>;
rotation rot = <0,0,0,1>; //Set your target rotation here

llSetLocalRot(rot);
llSetLocalPos(rot / axisPos);

... or the like would roughly rotate your object around the parent prim at a 1m offset from the center. Don't hold me to this, though - llSetLocalPos and llSetPos with child prims are not something I've dabbled much with.

3) Texture animation
I would strongly suggest doing this for your second hand to save sim FPS. You could feasibly refresh it every 60 seconds.

Uhm, from what I can tell, llSetLocalPos() doesn't exist...

If we skip the idea of single prim rotations with an offset center. As it will only work on llSetRot/llSetLocalRot i.c.w. llSetPos, which will result in two problems:
A. Fixed 'speed' same as Rot, items first rot then move or vice versa. Splitting up into multiple llSetRot/llSetPos will still result in 'jerky movements'
B. Can't use on linked objects (llSetPos is sometimes borked on child prims).

We can only use multi-prim rotations for offset center rotations or any other forms of complex rotations. This shifts the problem from 'how to rotate' to 'how to move/rez/delete object groups in unison'

Option 1: scripted link/unlink. Issues:
1. Perms problem... need to ask owner for permissions
2. Can only unlink per prim.
3. Relink will make prim 'parent'
4. Doesn't work for physics objects (they'll blow up nicely)
5. When moving/deleting etc... parts can be left behind. So you'll eventuallly still need option 2.
I've never tried creating grouped link/unlink system as the task of 'managing' the system looked quite complex. (It's certainly more complex than the whole rot issue).

Option 2: 'multi object' objects System:
1. Need rezzing (llRez) of child objects from parent object
2. Need a 'keep alive' system based on llListen or llSensor to see if 'parent' object is deleted
3. Need a 'move with parent' script in child objects.

Issues:
1. Timing lag / daily server 'resets' -> make the 'rezzer' also check for existence of child objects, and rerez them if they've decided to kill themselves.
2. Movement. Do NOT use moving_end events in rotating objects... the rotatie itself is a movement. Or use them and check for a specific offset of movement between moving_start and moving_end
3. 'Kinematics' style rotations where child objects rotate with their parent objects is very difficult/impossible -> A reason to use the link/unlink system if you need this.
4. Does NOT work for moving physics objects. (I'm still working on a way to get multiprim rot in a physics system)

All in all it's well possible to have 'multi-object' objects. For a complete kinematics/multi jointed system it's probably necessary to combine both methods. (I have not tried this yet, but it would be a very nice scripting system to have

Some other tips when working on localrot things:
1. perpetual localrot items (ie clocks) are buggy... (= randomly move) This is probably caused by a erroneous 'recalculation' of the object's position based on the individual prims pos, every day or so. It can be fixed by a script checking and resetting the position, though.
2. A lot of the single prim move/scale (prim param) functions are buggy/malfunction when the prim is a child prim in a linked object.

All in all... the basic rot: 1 % of the work, extra plumbing: 99% of the work.

Whoops! Thought they added that. Well, it can be worked around.

//Again, this is untested.
llSetPos(llGetPos() - llGetLocalPos());

//Or
llSetPos(llGetPos() + (llGetPos() - llGetLocalPos()));

Or none at all. I'm likely going to take a shot at objects manipulated by offset, free of links (except for rigid-bodies). You'll see it on the boards if I'm successful.

What about using a combination of the totally clear disk with the hand attached to it, then simply rotating a clear disk. The key to this working, is that the disk is the LAST prim linked so that it is the root prim.... by the way, the totally clear disk does NOT have to be that large. Think of this as a door with a hinge.

Could this work, or does this sound crazy?

right, or another easy solution would be to simply make the hand perfectly symmetrical and, using textures or scripts to make part of the hand transparent.