Cartesian -> Polar Conversions

Hey everyone, I am trying to create a HUD object, that would put a "dot" prim on the HUD and would show it relative to the center of the prim behind it, which would represent me. This would work very similar to the mini map. I think I need to do cartesian -> polar conversions but I am not sure how to. At the moment since I can not do the polar conversion it is only working correctly when you face north. Any help would be appreciated.

vector vec = <128,128,0>;
vector pos = llGetPos();
vector final = vec - pos;
llSetPos(<0.004 * llSqrt( llPow(final.x,2) + llPow(final.y,2) ) *
llCos(llAtan2( final.y,final.x)) + 0.02125),0,
(llSqrt( llPow(final.x,2) + llPow(final.y,2) ) *
llSin(llAtan2( final.y,final.x)) - 0.05)>;

You should be able to skip the trig. Since you are able to generate position vectors - llDetectedPos(), or llGetPos() -, you alread have the 3-space coordinates in the sim. You really just need to translate that to your hud, which is a geometry problem, not a trigonometry problem.

Take the X,Y components (vector.x vector.y), plop them in a new vector aligned with the coordinate system of your hud object, then scale them down to map from sim-space to your hud object's size, and position prims using the results?

It should be much simpler, unless I am missing something here. I wrote a compass that points on a hud to a detected target, and didn't use any trig at all.

I don't think it works that way, since you have to handle the rotation of the avatar.

Have a look at the llRot2Euler and llEuler2Rot functions. http://rpgstats.com/wiki/index.php?title=LlRot2Euler

Lyn

Start with the vector position of something in the sim, call it pos.
Subtract the vector position of you, llGetPos.
We now have a vector pointing from you to the thing in the sim.
Now divide that vector by your rotation, llGetRot.
What this does is that now the vector is relative to your rotation.
Now scale that vector down by some factor and set the z component to 0.

Having coded this up I would play with it on a non hud attachment just to check that it's roughly doing the right thing. Converting the vectors you get out of this to look right on a hud should be just a rotation (if you need one at all), but I don't know off the top of my head what that rotation would be.

It looks like that's getting closer to a solution. It still seems off a bit, I am sure it is a rotation problem. Maybe try multiplying?

Here is what I have atm, still seems to be off, but it looks like it is almost there.

vector vec = <100,100,0>;
vector pos = llGetPos();
pos = <pos.x,pos.y,vec.z>;
vector prelim = vec - pos;
vector final = prelim / llGetRot();
llSetPos(<0.004 * final.x),0,(0.004 * final.y)>;

The off-by-a-bit might be that what you get from llGetRot in an attachment doesn't always look that much like the direction the avatar is facing. Do some experiments with something just copying your Rot and see if it's acting like the hud thing.

In the root prim of an attachment, if you call llGetPos() you will get the offset of the avatar root relative to the world/sim reference frame, not the position of the attachment. If you call llGetLocalPos() you will get the offset of the root prim of the attachment relative to the reference frame of the *joint* to which it is attached.

The burning question is: How do i get the offset of the joint to which I am attached relative to the the root of the avatar that I am attached to.

If anyone knows the answer to the final question, please enlighten me!

(BTW because joints in general move instantaneously relative to the avatar root, I suspect this explains the choice of erroneous return values from these functions).

HTH
/esc

You really can't, because that's (at least logically) influenced at any given point in time by the currently active animation, and animations do not run on the server.

You could possibly calculate a "close enough" value for a static animation by creating said animation yourself and calculating the offset from the values stored in the .bvh file, but I can't see how that'd be helpful and probably still wouldn't work except perhaps in one specific case with one specific avatar.


.

Good point LOL. Seems like there's not really a solution here that even LL could implement on our behalf...