In article <487ef006$1@news.povray.org>, sco### [at] scottcom says...
> >        if (Rot.x > 359)
> >        {
> >            Rot.x = 0;
> >        }
> 
> I think that previous line would be better written as:
> 
> if( Rot.x >= 360 )
> {
>  Rot.x = Rot.x - 360;
> }
> 
Made some adjustments there already, realizing that its wasn't quite 
right.

> It will give the correct transition as it passes 360 degrees.
> 
> > However, I still get some real "odd" behavior if I try to do more than
> > one direction at a time, like RotChange = <10,0,10>. Instead of
> > following the expected path, it seems to curve off in the wrong
> > direction,
> 
> OK, I missed the fact that your llEuler2Rot() function probably is expect
ing 
> Euler angles, which are different from rotations about the global xyz axe
s 
> (like POV uses for "rotate" and what you are doing in those 3 groups of t
rig 
> functions).  To make matters worse, Euler angles are not a universally 
> defined standard, does it say anything about the definition in the functi
on 
> help?
> 
> Try something like the following (hopefully no typos!), which rotates the
 
> point based on the most standard Euler angle system:
> 
>         float xx = llCos(RotAngle.x)*x - llSin(RotAngle.x)*y;
>         float xy = llSin(RotAngle.x)*x + llCos(RotAngle.x)*y;
>         float xz = z;
> 
>         float yx = xx;
>         float yy = llCos(RotAngle.y)*xy - llSin(RotAngle.y)*xz;
>         float yz = llSin(RotAngle.y)*xy + llCos(RotAngle.y)*xz;
> 
>         float zx = llCos(RotAngle.z)*yx - llSin(RotAngle.z)*yy;
>         float zy = llSin(RotAngle.z)*yx + llCos(RotAngle.z)*yy;
>         float zz = yz;
>         npos = <zx,zy,zz>;
> 
> Hopefully that method of rotating will match up with the llEuler2Rot 
> function.
> 
> As always, more info on Wikipedia about Euler angles:
> 
> http://en.wikipedia.org/wiki/Euler_angles
>  
Right. Will try that and see. Also figure on adding 7 more objects at 
the other corners, so I can get a better sense what the frell is really 
going on here. lol The hardest part is going to be, in the end, once I 
have the math working, to adjust the program so that I can actually use 
and arbitrary point as the "center". At the moment I am taking advantage 
of the fact that llGetPos, when applied to linked prims, returns their 
location "relative" to the master prim. If I want to, instead, make 
something more complex, then I will need to have that "center" be the 
location of another prim, or an arbitrary point on it, depending on what 
I am doing. For the sort of "standard" robot, this is easy, since the 
"joint" is going to be centered where the center for the "next" segment 
is. For something other than that, it get a bit.. complicated, since the 
point of rotation is going to be some place on, around, the object in 
question.

Still, getting that right may be possible with existing functions, or, 
if not, its probably not a huge issue. I can get the "existing" rotation 
in Euler from the object itself, its "size", determine where the point 
should be in its non-rotated state, then calculate where that should be, 
by applying the objects own rotations, I think...

-- 
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