http://wiki.secondlife.com/wiki/Quaternion

Seriously. SL uses these dang things for their rotation matrix, 
apparently due to how the GPU uses them too, also apparently do to it 
being "easier" somehow for the 3D software to work with them. Ok, fine 
so far. But, SL is **notorious** for the fact that lots of scripts doing 
things causes so much lag that just having 10 people in a sim can 
sometimes grind the damn thing to a halt at this point (often do to the 
number of scripts on the avatars). Anything that can "reduce" the number 
of function calls needed in a script to "do" something would help this. 
So, what does that mean in a practical sense.. Lets take something I 
tried:

Make a sphere, hollow it, cut into it, all so you get something that 
looks like you cut an orange in sections, removed the fruit and kept the 
wedge of rind. Add some textures to it. Get permissions, etc. to find 
out where the camera is, read its rotation, rotate your new object to 
"match" that rotation. Watch as the object which was right side up, 
facing forward is now a) 90 degrees out of alignment (i.e.) sideways, b) 
rotated so its pointing "up", and c) reorients the wrong @#$#@$#@ 
fracking direction when ever you change the camera angle...

Now, obviously, there are a few problems here:

1. The existing rotation needs to be preserved.
2. The "correct" rotation has to be applied to the object so it "does" 
face the cameras direction of view properly.
3. What happens to the object has to be either 100% accurate to the 
direction the camera is looking, *or* limits need to be applied, so it 
only rotates as much as 45 degrees up/down, never does so in terms of 
where its top and bottom are (i.e., if its "forward" direction is Y, it 
should **never** rotate on the Y axis at all.), and it should be able to 
rotate 360 degrees the other way.

Problem is, how the frack do you transpose the vectors for X,Y,Z to 
something "valid" for an object using this system, without converting it 
to euler values?

Basically, in the above example, if I remember right, the cutting can 
only happen along the X axis, so the "face" becomes "Z", Z is the 
objects "X", this means that, to map the camera to the object, camera Z 
= object X, camera Y = object Y still, but camera X = object Z. (I 
think, I am trying to visualize this without the actual object/wrong 
result in front of me). With Euler coordinates, this is as simple as 
switching the values. With Quaternions.. well, there may be a dozen ways 
to *rotate* the same object into a particular orientation, so there is 
not "direct" way to just pull the X,Y,Z and switch it to Z,Y,X, at least 
that I can see.

So, I guess, my question is, am I right, and am I *forced* to use the 
conversion functions to get the Euler values, switch things around 
there, then convert back "again" to the system the rotation commands 
use?

I tried asking something similar on the SL forums, but... basically I 
got ignored... Which really irks me, since you would think people 
lagging so bad they can't walk 5 meters in a minute, on really bad sims, 
would *want* to find ways to simplify scripts and reduce the crap the 
servers are running... lol

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> Seriously. SL uses these dang things for their rotation matrix,
> apparently due to how the GPU uses them too,

No, the GPU uses standard 4x4 transformation matrices.  Somewhere in the 
software the conversion must be made from quaternion to matrix to send to 
the GPU.  SL probably does this though, as I assume it handles the 
interpolation between chunks of data.

> also apparently do to it
> being "easier" somehow for the 3D software to work with them.

The good things about quaternions is that it's really easy to interpolate 
between two orientations, it's very easy to check that a quaternion 
represents a valid orientation, and that it is easy to construct one that 
rotates about a vector.  All of these are really hard to do if you are 
dealing with matricies.

> 3. What happens to the object has to be either 100% accurate to the
> direction the camera is looking, *or* limits need to be applied, so it
> only rotates as much as 45 degrees up/down, never does so in terms of
> where its top and bottom are (i.e., if its "forward" direction is Y, it
> should **never** rotate on the Y axis at all.), and it should be able to
> rotate 360 degrees the other way.
>
> Problem is, how the frack do you transpose the vectors for X,Y,Z to
> something "valid" for an object using this system, without converting it
> to euler values?

If I understand correctly, you are trying to set the orientation of an 
object based on the camera position (so it appears to rotate in world space 
as the camera moves), but with some limits etc, and return to SL a 
quaternion that represents this orientation.

Does SL provide you with functions to help with creating and manipulating 
quaternions? That would make your life much easier, if not you'll need to 
read up on how to create quaternions for basic things like rotation about an 
axis, combining rotations etc.

If you want to limit the rotations somehow, then I think you'll have to work 
them out as rotations about the X Y and Z axis first, limit them, then 
convert to a quaternion.  I don't see any other way.

You should be able to work out the rotations about each axis that allow the 
object to point directly to the camera using simple trig functions. 
Probably just a pitch rotation about the left/right axis followed by a yaw 
rotation about the "up" axis.

Once you have them, limit them in any way you see fit, then convert those 
two rotations to quaternion form and multiply them!

To create a quaternion that rotates an angle a about a vector v=(vx,vy,vz):

(cos(a/2) , vx sin(a/2) , vy sin(a/2) , vz sin (a/2) )

So to rotate 60 degrees about the x axis, you would use the quaternion:

(0.866,0.5,0,0)

The wikipedia pages on quaternion and quaternion rotations gives some good 
info:

http://en.wikipedia.org/wiki/Quaternion
http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation

Post a reply to this message

In article <48649266$1@news.povray.org>, sco### [at] scottcom says...
> > Problem is, how the frack do you transpose the vectors for X,Y,Z to
> > something "valid" for an object using this system, without converting i
t
> > to euler values?
> 
> If I understand correctly, you are trying to set the orientation of an 
> object based on the camera position (so it appears to rotate in world spa
ce 
> as the camera moves), but with some limits etc, and return to SL a 
> quaternion that represents this orientation.
> 
> Does SL provide you with functions to help with creating and manipulating
 
> quaternions? That would make your life much easier, if not you'll need to
 
> read up on how to create quaternions for basic things like rotation about
 an 
> axis, combining rotations etc.
> 
Umm. Yes, but you missed one of my key points. That being the fact that 
every function that you have to call or action you have to perform in 
the script is going to add to the lag on the server end. From a purely 
practical standpoint, it would have been better to support the standard 
3 value Euler rotations, i.e., X,Y,Z, and do the conversion in the 
client. Instead, you have to do it in the script, using calls that will 
"force" the server to handle the conversion (I think.. Its damn 
confusing how SL handles this, since some stuff "must" run server side, 
but some is handled client side, like position and rotation functions 
for "attached" objects (those you wear).

So, the answer is, yes, they do provide means to do the conversions. I 
am asking if there is some way to do it without those, so I can reduce 
the number of actual functions I call in it. I strongly suspect that the 
way it works won't "allow" it, but I figured it wouldn't hurt to try. 
lol

> If you want to limit the rotations somehow, then I think you'll have to w
ork 
> them out as rotations about the X Y and Z axis first, limit them, then 
> convert to a quaternion.  I don't see any other way.
> 
> You should be able to work out the rotations about each axis that allow t
he 
> object to point directly to the camera using simple trig functions. 
> Probably just a pitch rotation about the left/right axis followed by a ya
w 
> rotation about the "up" axis.
> 
> Once you have them, limit them in any way you see fit, then convert those
 
> two rotations to quaternion form and multiply them!
> 
> To create a quaternion that rotates an angle a about a vector v=(vx,vy,
vz):
> 
> (cos(a/2) , vx sin(a/2) , vy sin(a/2) , vz sin (a/2) )
> 
> So to rotate 60 degrees about the x axis, you would use the quaternion:
> 
> (0.866,0.5,0,0)
> 
> The wikipedia pages on quaternion and quaternion rotations gives some goo
d 
> info:
> 
> http://en.wikipedia.org/wiki/Quaternion
> http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation
>  
> 
> 

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> Umm. Yes, but you missed one of my key points. That being the fact that
> every function that you have to call or action you have to perform in
> the script is going to add to the lag on the server end.

Well I guess if you can't afford to do a few sin/cos operations and a 
handful of adds/multiplies to create the rotation quaternion, it's not going 
to work.  I can't think of any computationally simpler way to create the 
quaternion than that, sorry.

Post a reply to this message

In article <4865dec1$1@news.povray.org>, sco### [at] laptopcom says...
> > Umm. Yes, but you missed one of my key points. That being the fact that
> > every function that you have to call or action you have to perform in
> > the script is going to add to the lag on the server end.
> 
> Well I guess if you can't afford to do a few sin/cos operations and a 
> handful of adds/multiplies to create the rotation quaternion, it's not go
ing 
> to work.  I can't think of any computationally simpler way to create the
 
> quaternion than that, sorry.
>  
Well. Was more wondering if there was some "sane" way to handle them 
without having the convert them at all. Basically, you do something 
like:

a = llGetRot(me);
b = llGetLookAt();

then either do 'llSetRot(a*b);' or 'llSetRot(b);', depending on if you 
want to try to preserve "any" of the original orientation. The problem, 
of course, is simply that 'b' is not oriented to the same up/down or 
even top/bottom as 'a' in the first place. So, you either have to delete 
one of the angles, then apply, or convert to Euler, switch them around, 
then convert back to Quaternian, and *then* apply. The first method 
seems to be impractical, or impossible, take you pick, due to how the 
the stuff works. Its seriously annoying.

Still, didn't figure on getting an answer in the first place. Just kind 
of had a desperate hope of one. ;) lol

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <MPG.22d0a97f20c1451598a16f@news.povray.org>, 
sel### [at] rraznet says...

Now, this though looks interesting and helpful:

http://johannahyacinth.blogspot.com/2007/05/sculpted-prims-with-pov-
ray.html

Any interesting isosurfaces that might work in SL? lol

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> Well. Was more wondering if there was some "sane" way to handle them
> without having the convert them at all. Basically, you do something
> like:
>
> a = llGetRot(me);
> b = llGetLookAt();
>
> then either do 'llSetRot(a*b);' or 'llSetRot(b);', depending on if you
> want to try to preserve "any" of the original orientation. The problem,
> of course, is simply that 'b' is not oriented to the same up/down or
> even top/bottom as 'a' in the first place. So, you either have to delete
> one of the angles, then apply, or convert to Euler, switch them around,
> then convert back to Quaternian, and *then* apply. The first method
> seems to be impractical, or impossible, take you pick, due to how the
> the stuff works. Its seriously annoying.

The 2nd method you propose seems feasible.

I would rotate the "forward" direction of your model (eg the axis vector 
(1,0,0)) by the quaternion "a".  Maybe your script language lets you do this 
just with a *, if not you need to look up how to rotate a vector by a 
quaternion - it's not hard or expensive.

Then with this vNew, you can work out the two rotation angles, limit them to 
whatever ranges you see fit, then create a new quaternion from these angles.

Post a reply to this message

In article <4868a1bc@news.povray.org>, sco### [at] laptopcom says...
> > Well. Was more wondering if there was some "sane" way to handle them
> > without having the convert them at all. Basically, you do something
> > like:
> >
> > a = llGetRot(me);
> > b = llGetLookAt();
> >
> > then either do 'llSetRot(a*b);' or 'llSetRot(b);', depending on if you
> > want to try to preserve "any" of the original orientation. The problem,
> > of course, is simply that 'b' is not oriented to the same up/down or
> > even top/bottom as 'a' in the first place. So, you either have to delet
e
> > one of the angles, then apply, or convert to Euler, switch them around,
> > then convert back to Quaternian, and *then* apply. The first method
> > seems to be impractical, or impossible, take you pick, due to how the
> > the stuff works. Its seriously annoying.
> 
> The 2nd method you propose seems feasible.
> 
> I would rotate the "forward" direction of your model (eg the axis vector
 
> (1,0,0)) by the quaternion "a".  Maybe your script language lets you do t
his 
> just with a *, if not you need to look up how to rotate a vector by a 
> quaternion - it's not hard or expensive.
> 
> Then with this vNew, you can work out the two rotation angles, limit them
 to 
> whatever ranges you see fit, then create a new quaternion from these angl
es.
>  
Yeah. I know that will work, but it adds more math and function calls, 
which means more script execution to do it, and thus "possibly" added 
lag on the server end, where the script runs. Its a catch-22.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message