An Attached Object and llGetPos

Before anyone points out the obvious... yes, I know that in an attached object, llGetPos() returns the position of the center of the avatar.

Here's the situation:

I have an object (currently comprised of 5 prims) that sits in the palm of the hand of the avatar to which it's attached. (An included anim poses the avatar properly with arm extended and hand palm up.)

This object rezzes another object from its inventory a short distance above itself. Sort of like those small, hand-held "holographic message players" you see in some scifi stuff.

It's also meant to be able to function when sitting on a table, not attached to an avatar.

The positioning of the rezzed object above the imager is perfect when the imager is sitting by itself. It's when it's attached to the avatar and sitting on the palm of the hand the trouble begins.

When used in a parent prim of a prim set that's attached to an avatar, llGetPos() returns the position of the center of the avatar, not the center of the prim in which the script resides. Well and good. But according to the LSL Wiki:



Now the puzzling part.

The object was originally 4 prims; I added another small prim, buried in the center of the parent prim, with just enough code in it to kick its position back to the parent prim when messaged. Since it's buried in the center of the parent prim, its center position is close enough the the reference point I wanted (the center of the parent prim) to be useful.

However, using llGetPos() from within the child prim does NOT seem to be returning the position in the world of that child; it still seems to be returning the avatar's position, offset by about 0.01m on the Z axis. (I left a tiny bit of it sticking up out of the parent prim so I could still access it for coding changes if I needed to.)

Here's what I mean; while attached to my avatar, llGetPos() in the parent prim returns:

<246.36111, 182.07704, 553.20007>

and llGetPos() executed within the child prim of the attached parent yields:

<246.36111, 182.07704, 553.19824>


...as you can see, there's only a tiny difference in the Z axis, because I left the child sticking up slightly higher than the parent.

So... what am I doing wrong? Or is the Wiki wrong, and using llGetPos() within a child prim of an attachment will NOT in fact give the child's location in the world?

This is causing me to tear my hair out...


Oh, let me state that:

* Yes, I'm certain the child prim buried in the center of the parent prim IS a child, and I didn't accidentaly link it such that what I think is a child is the parent.

* I can't just derive an offset from my avatar's center through trial and error, because if someone else uses this device, and their arms are a different length than mine, the rezzed object would appear in the wrong place.


Help?

I guess Wiki is just vaguely worded, there...

"When called from within a child prim in a linked set, it returns the position of the child in region coordinates, not the parent's position. To get the position of a child object relative to its parent, use llGetLocalPos. To get the position of the parent from a script within a child prim, use llGetRootPosition"

... this should be actually something to the effect, when called from child prim, the result is position of root prim offset by local position of the prim invoking the function... or in other words return of llGetRootPosition + llGetLocalPos() (possibly add or take root rotation) or something to this effect. Because root position matches the centre of AV in attachments, you're getting essentially position of AV offset by local position of prim in question, in sim coordinates.

hope it makes any sense o.O;

Mmmm...

...does that mean there is NO way to get the region coordinates of a prim (or any part of a set of prims) that's being "worn" as an attachment? (I'm talking the coordinates of the prim itself, of course, not the coordinates of the avatar, which I seem to be getting with NO problem whatsoever...)

Correct, this information is not available. In fact not only is it not available to LSL, it isn't available to the server itself. I'm told there are settings in the client you can mess around with to change the heights etc. of avatars. The client will then render your attachment in a different place. The server knows nothing of any of this!

Okay... hmmm...

Well, is there any way to make the object that's being rezzed appear, say, 1m in front of the avatar, in the direction the avatar happens to be facing at the time?

I could alter the pose I'm using to animate the avatar so the held item is "under" an object that gets rezzed a certain distance and direction from the avatar...

Is there any way to place an object 1m in front of the avatar in the direction it's currently facing? I've tried, but I must be doing something wrong. Here's the code I'm using:

llRezObject("picture", (llGetPos()+(<1.0,0.0,0.0>*llGetRot())),
        ZERO_VECTOR, ZERO_ROTATION, spin_rate);

...and here's the result, just turning in place and rezzing several instances of the object...

http://www.castle-walls.org/secondlife/pics/orient.jpg

As you can see, though they appear to be (pretty close to) 1m from my avatar's center... they define a plane that's tipped. And since I'm only adjusting the X coordinate... I'm not sure why. The llGetPos() and llGetRot() in the item that does the rezzing is supposed to be returning the values for the avatar, since it's attached to the avatar. The llGetPos() certainly DOES return the location of the avatar center...

Help?

I suspect llGetRot() returns rotation of AV, but this rotation can be to some extent affected by slope of the ground plane underneath. Simple way to deal with it would be to 'flatten' the rotation on horizontal plane -- take he forward vector, discard the Z component, normalize the vector, use it as base for llAxes2Rot call together with vector pointing straight up and cross product of these two.

Have you considered using additional linked prims that cycle through being visible and invisible to fake the rezzing? Or is there some other reason why the 2nd portion has to be a separately rezzed object? Just an idea.

You know, it never occured to me it might be being affected by the slope of the ground underneath... it was driving me batty because the avatar is standing on a level surface, but getting that sloped distribution...

I'll try normalizing it and see what that produces. Thanks for the suggestion.

No, using another child prim never occured to me... it's a good idea, and I'll give it some serious thought.

There are several advantages to using a seperate rezzed object, though, instead of another child prim.

This item is supposed to function basically as a photo album or photo wallet, and let the user flip through the pictures contained therein, showing them to other people. Among other things, I've added functions for changing the size and position of the displayed picture... from near postage-stamp sized to small billboard size.

The way it works now is that a blank, flattened cube (basically like a square sheet of paper) is needed for each photo. The photo is placed as a texture on the two large, flat sides (so it can be displayed for people on both sides at the same time). Now, while it's certainly possible to store the textures and have a script switch them as to which is being displayed on the cube face at any given time...

...not all photos are going to be the same proportions. So by using an entire seperate item (prim) for each photo, when the photo is "mounted" on the prim in the first place, things like "number of repeats per face" and "offset" can be individually tailored for each photo if need be at the time of creation, and then when the display prims have been loaded into the photo "album", you don't have to worry about it.

If, on the other hand, a child prim is used to display the photos, and the photos are dynamically swapped textures, any adjustments that may need to be made for a given photo go out the window. Yes, I could get around that by requiring any user to make sure their photos are in a given fixed format... but I dislike constraining an end-user like that if I don't have to.

Also, if the prim used to display the photo is a child prim, and the parent prim (device) ends up rotated or slanted... so does the photo. By using a seperately rezzed prim for the photo, that prim can always end up level with respect to the region grid.

Still and all... it's a potentially useful idea, and I'll kick it around and see what it sparks. It would certainly solve the positioning problem nicely, though...

You can perform adjustments of UV attributes as well as texture switch and everything else for the child prim, with the llSetPrimitiveParams() call, i think... if it's done properly (all attribute changes packed into single list similar to how warpPos operates) then the switch/resizing is instant to the end viewer and they never see anything odd. ^^;

edit: this would quite obviously mean a need to store per-picture UV attributes and such somewhat, either in notecard or maybe in name of picture itself o.O

The reason you can't get the precise position of attached objects is because av animation (bones animation) doesn't actually happen on the server, but on the client.