Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Rotating 3 child prims?

Gerami Fizz
That Guy
Join date: 15 Jun 2005
Posts: 88
06-27-2005 12:26
Hi all,

I've got a bit of a dilemma... As a learning project, I'm working on an analog clock with 3 prim hands (seconds, minutes, hours), but I can't get the hands to rotate when they're linked to the face! (Correction: Sometimes I can get -one- hand to move, other times it rotates the face with it.)

I am using llSetLocalRot for the rotations. Isn't this the sort of application llSetLocalRot was designed for? I know there have been child prim rotation posts before, but I don't think they dealt with more than one child prim. If anyone can help me to my satisfaction, I'll give you a free copy of my AWESOME clock...

I'll accept workarounds, hacks, legitimate coding... but here's what I need it to do:

1. Be one linked object. (Currently the clock only works correctly if the hands are unlinked.)
2. Be able to rotate about the Z-axis. (Currently impossible due to llSetLocalRot not having a parent to refer to, because the hands are unlinked... I think.)

It already displays the correct time, all I need is a way to attach the hands. If anyone has experience with this, please respond here or send me an IM. I'm not constantly online, but I'll get it eventually.

Thanks! (And sorry if this is a repeat post.)
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
06-27-2005 14:06
There shouldnt be any differences with rotating one child prim versus three. (Though it would be wise to check for problems that occur when all three try moving at the same time.) How are you computing the rotation of each hand? Im assuming you already know that each hand can be only one primitive, or the rotation will most likely be unsynchronized (each prim that composes the hand will move seperately to the destination rotation, even if the rotation is triggered at exactly the same time.)

Here's how I'd do it.
Have 12:00 be when z=0 radians (you might have to rotate the clock face for this to happen.). When oriented correctly, 6:00 should be PI Z=PI rads(180 degs).

Each hand should divide the current time within its current revolution, by the total number of units in one revolution, and multiply it by TWO_PI to get the new Z-rotation of the hand. For example: in the second hand, one revolution is 60 seconds. so if the current time is 12:00:00, then the z rotation of the second hand is 0 / 60 * TWO_PI, which is 0. When 12:00:01 rolls around, the second hand's rotation should be 1 / 60 * TWO_PI. The minute hand uses a similar algorythim.

The hour hand simply divides by 12 instead of by 60.

How are you currently computing and applying the rotation to each hand?
==Chris
_____________________
October 3rd is the Day Against DRM (Digital Restrictions Management), learn more at http://www.defectivebydesign.org/what_is_drm
Eggy Lippmann
Wiktator
Join date: 1 May 2003
Posts: 7,939
06-27-2005 14:11
Why don't you use texture rotations like everyone else does?
Gerami Fizz
That Guy
Join date: 15 Jun 2005
Posts: 88
06-27-2005 14:45
Because I'm difficult, and it involves particles...

I've got the clock working perfectly when it's unlinked, but it can currently only face one direction (because it's unlinked).

The three hands are indeed separate prims, each containing their own scripts. Each of the hands in turn is a particle emitter that generates an elongated particle hand for a really cool floating glowing analog clock effect.

I computed the time by using llGetWallclock and then performed the appropriate math to determine hours/minutes/seconds. I'm not having trouble with the calculation or the display, just the linking.

Thanks for your input so far.
Christopher Omega
Oxymoron
Join date: 28 Mar 2003
Posts: 1,828
06-27-2005 14:59
From: Gerami Fizz
I've got the clock working perfectly when it's unlinked, but it can currently only face one direction (because it's unlinked).

Hmm... you might need to rotate the current rotation of the object rather then set the rotation of the object. In this case, you want to apply a rotation that gets you from your current rotation to your destination rotation. For example, if your "ticking" every 1 second, your second hand needs to rotate 1/60 * TWO_PI every second.

The way you apply this to the current rotation of the second hand is to use this:
llSetLocalRot(llEuler2Rot(<0, 0, 1/60*TWO_PI>;) * llGetLocalRot());

This "adds" 1/60*TWO_PI to the rotation of the object on its local-z axis (if Im not mistaken, Its been awhile since Ive tested the rotation functions).

The only problem I see with this is that your system may gradually get out of sync (adding 1/60*TWO_PI 60 times might not exactly equal TWO_PI, due to floating point rounding error). If that occurs you might get away with resetting the rotations of each hand to the root clock rotation (llSetLocalRot(llGetRot()) I believe) every day at midnight.

Hope this helps! :D
==Chris

NOTE: Try llEuler2Rot(<0, 0, -1/60*TWO_PI>;) if the above makes your second hand move counter clockwise. I just remembered that positive rotation moves CCW instead of CW. :o
_____________________
October 3rd is the Day Against DRM (Digital Restrictions Management), learn more at http://www.defectivebydesign.org/what_is_drm
Gerami Fizz
That Guy
Join date: 15 Jun 2005
Posts: 88
06-27-2005 15:34
Thanks Chris.

Actually, I just got it working on my own... apparently I was an idiot and didn't reset the scripts in the hands when I attached them to the clock. I really need to remember my good coding practices and build that stuff into the script.

So... anyone want to buy a really neat looking clock (assuming you're in an area where particles are reliable?) heheh. Thanks for you help.