Wristwatch hand problem

I am trying to make hands for a wristwatch with secondary dials on it's face.

This means the base prims for the secondary hands have to be as small as possible: 10mm x 10mm x 10mm. It is possible to slice a cube to make one set of faces very thin (slice 0.49 - 0.51), and then to cut it to make one of the thin faces only ¼ of the width of the base prim (cut 0.375 - 0.813), and this is ideal for a very small hour hand when viewed down along the x axis, with only the top of the smallest face of the watch hand prim protruding through the watch face prim.

However, this presents the problem of rotating the hand prim, which is a link child of the clock face prim, around an axis that is not central to it.

Void Singer's code examples (many thanks, Void) work perfectly on unlinked prims, but appear to run into the llSetPrimitiveParams/PRIM_ROTATION bug when used in child prims (or maybe I am messing up my implementation). The JIRA on this includes suggestions on workarounds, but I am struggling to get my head around what's going on and what I need to do. (Also, I need to be able to set an absolute rotation for the hands: they respond to link messages telling them what second or minute they should be pointing at - this is important because lag can mess things up when incremental rotations are used.)

If anybody can help me sort this out I shall be most grateful.

Incidentally, I intend to make the resulting wristwatch an open source freebie should I ever manage to finish it to a high enough standard for public consumption (in case that influences anybody's inclination to respond to my question )

Background: by using 10mm prims for the secondary dials I can make the main watch face 25mm in diameter, a very good size indeed for a fairly complex wristwatch. Should my current thinking prove untenable, Plan B involves attempting to make the hands from sculpted prims that void the bulk of the prim leaving only a short, slim watch hand with one end located on the prim's centre of rotation, but this would involve my learning how to make sculpted prims, and I don't even know if it's possible to do what I want with them. Plan C involves making the diameter of the watch face 35mm and the secondary dials 14mm in diameter; this would leave adequate leeway to make hands of different lengths, and indeed widths, and is by far the easiest way of doing what I want, but the resulting wristwatch would be much bulkier than I would like.

If anyone has suggestions for plans D, E and F, etc., please let me know

(I did try to attach a .PNG diagram to this post, but there appears to be a problem with uploading attachments to posts in this forum.)

One solution I've seen is making the hands rotating textures. No muss, no fuss.

Unfortunately this method involves stacking up a whole load of textures with transparencies: three main hands, 6 hands on three secondary dials, day, date 10s and units, month, year 10s and units, and the holes in the watch face texture to show the date information. The Open GL alpha bug put paid to that idea. It's what I tried first. It's the discovery of the slice parameter for prims that has resurrected this project

There is a way to cut a prim so the visible part of the prim is off center, but rotates around a central point. I think this will solve your problem. (I developed it for my own clock project). I am just not sure if it can be made small enough for your watch. I'll send you some information in-World.

if I understand the cuts you've made (box sliced paper thin, path cut to to a side and to a corner) to get your differing lengths of .5cm and sqrt(.5cm) or similar) and these dials are then offset from the main center of the watch...

this is a slight modification of the offset rezzing formula...

gPosCenter; //-- position of the offset dial relative to the root.
gSizHand; //-- < 0.0, length of hand, 0.0 >
gRotCurrent; //-- make sure this is filled with the rotation that the child prim is at for noon

//-- alternative A:
gRotNext = gRotArc * gRotCurrent
//-- alternative B
// gRotCurrent = gRotArc * gRotCurrent;

llSetLinkPrimitiveParams( [PRIM_POSITION, gPosCenter + gSizHand * gRotNext ,
PRIM_ROTATION, gRotNext / llGetLocalRot()] );

alternative A is for if you calculate rotation based on current time, and disregard the current hand position

alternative B is if you calculate increments from the current position, and you'd replace gRotNext in the set prim call with gRotCurrent.

To a limited extent, you can get away with stacking 32-bit textures if you are
making something like a clock. I have made several clocks that have hour, minute, and second hands on separate prims, without any alpha sorting issues. I suspect it works because each texture is mostly transparent -- the only opaque elements being the hands themselves -- although I'll admit that I haven't really thought this through carefully. I have never tried stacking as many textures as you want to, nor have I tried using a clock face which, itself, is a 32-bit texture. There seems to be a threshhold condition somewhere between my limited experience and your goal. It would be nice to know how far you can push things before alpha sorting starts to be a problem.

hehe oops Rolig is right.. if you use a cicular prim for the hands textures on only one surface (the secondary dial) you won't have sorting issues if they are all aligned to the same plane

Nice, but the info I gave her will give her a hand that rotates at one end, without scripting trickery. I guess I should give everyone the benefit of the prim torture to do it.

First make the prim a Sphere, and set the Dimple to B: 0.9 and E: 1.0

Then change the prim to Box.

Set Size to X:0.264 Y:0.19 Z:0.72 (these can be adjusted to suit, dimensions are for example)

Set Top Shear X: to -0.4 (or whatever you desire, more shear = center rotation is offset farther)

As you see you get a hand which rotates around it's center which is offset from the visual center.

Thank you all very much. With your help I managed to get there. It's now just a matter of scripting all the features I want, which is all pretty routine, and therefore a bit dull.

heh I didn't think of using shear to offset the apparent rotation center... nice =)