llFrand Rotation?

hi everyone,

im kinda of stumped here. I can llFrand a position with no problems, but when i try to llFrand a rotation just cant seem to get it... any suggestions? thanx

You need to provide more details on what your trying to do... Maybe post a sample of what your trying? and explain it?

Are you trying to produce a random orientation for some object?

You can probably do ok by inserting a random float between -1 and 1 into each of the 4 fields in a rotation, then normalising... but if you want uniform distribution then you should throw away results outside of a spherically symmetric region and resample. Like this:

float quat_mag_sq(rotation rot) //magnitude of quaternion, squared
{
return rot.s*rot.s + rot.x*rot.x + rot.y*rot.y + rot.z*rot.z;
}

rotation quat_divide(rotation q, float f)
{
return <q.x / f, q.y / f, q.z / f, q.s / f>;
}

rotation rand_rot2()
{
rotation rot;
rot.s = llFrand(2.0) - 1.0;
rot.x = llFrand(2.0) - 1.0;
rot.y = llFrand(2.0) - 1.0;
rot.z = llFrand(2.0) - 1.0;
return rot;
}

rotation rand_rot()
{
rotation r = rand_rot2();
float mag_sq = quat_mag_sq(r);
while(mag_sq < 0.001 || mag_sq > 1.0)
{
r = rand_rot2();
mag_sq = quat_mag_sq(r);
} //we now have a quat within the unit sphere and not too near 0
return quat_divide(r,llSqrt(mag_sq));
}

default
{
touch_start(integer total_number)
{
rotation rot = rand_rot();
llOwnerSay((string)rot);
llSetRot(rot);
}
}

ahhhhh Perfect Seifert,

Thank you thats exactly what i need, Thanx!

Why not normalize it if it has a magnitude greater then one? Or would that mess up the statistical distribution?

Right. Imagine we are in 3 dimensions for a second, trying to find a random point on the sphere. If you take a random point in a 2x2x2 cube then normalise you'll get more points in the directions of the corners of the cube. Unit quaternions are just points on the unit sphere in 4 dimensions, and the same issue applies.

Couldn't you use axis-angle to reduce the LSL required?

rotation rand_rot()
{
    vector axis;
    float mag;
    do
        mag = llVecMag(axis = <llFrand(2.0) - 1.0, llFrand(2.0) - 1.0, llFrand(2.0) - 1.0>);
    while(mag < 0.01 || mag > 1.0);
    return llAxisAngle2Rot(axis / mag, llFrand(TWO_PI)>;
}

Good question. I'm not sure if that's quite the same distribution. I could imagine that it isn't uniform... If your angle is near zero then no matter what your axis is, the output will be near ZERO_ROTATION. Which might unfairly favour those rotations over ones further away, for which you need the right axis and the right angle.

Might be good enough for the application though.

*face palms* Yes you are right.

would a random vector with ranges in +/-PI converted to a rotation suffer the same problems with distribution? seems like it wouldn't but I've had a bit of early liquid christmas cheer =)

I ask because I used that in a project before (trek style target practice simulator)

I think yes, for the same kind of reason. That is that when some of the parameters are near certain areas, it affects how much the other parameters can affect things. E.g. if you rez a prim and colour it so you can see whats going on, if the Y rotation is around 90 degrees, then the X and Z rotations do approximately the same thing as each other. If all of X and Y and Z are near zero, then they all do different things. So I would expect that near Y = 90 there is around twice as much probability density as near Y = 0.

Gimbal lock sucks.

This might be wrong for the same reason the others were wrong, but how about using llEuler2Rot() with random components between -PI and PI?

I think that is the question that Void just asked and Seifert answered.

Oops, I thought Void was still talking llAxisAngle2Rot(). Now I feel doubly silly ;)

nope but I'm glad I'm not the only one that had the thought...

statistics never was my bag, but a furthe though crosses my mind, does it make a difference if said vector is applied locally or globally? I've noticed that when gimbal lock occurs in the editor interface that it's automatically converted which seems to suggest an implicit quaternion use behind the scenes (or maybe just some clever conversions)

is that where we'd see the overlap in positions? with those conversions being the extra density in certain directions?