 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is what I have:
vector Rot = <0,0,0>;
default
{
state_entry()
{
llSetTimerEvent(0);
}
touch_start(integer total_number)
{
llSetTimerEvent(0.1);
}
timer()
{
vector pos = llGetLocalPos();
vector npos;
float x = pos.x;
float y = pos.y;
float z = pos.z;
Rot = Rot + <0.5,1,1>;
if (Rot.x > 359)
{
Rot.x = 0;
}
if (Rot.y > 359)
{
Rot.y = 0;
}
if (Rot.z > 359)
{
Rot.z = 0;
}
y = llCos(Rot.x)*y - llSin(Rot.x)*z;
z = llSin(Rot.x)*y + llCos(Rot.x)*z;
z = llCos(Rot.y)*z - llSin(Rot.y)*x;
x = llSin(Rot.y)*z + llCos(Rot.y)*x;
x = llCos(Rot.z)*x - llSin(Rot.z)*y;
y = llSin(Rot.z)*x + llCos(Rot.z)*y;
npos = <x,y,z>;
llSetPos(npos);
llSetLocalRot(llEuler2Rot(Rot * DEG_TO_RAD));
}
}
The problem is, when it runs it "starts" where I placed the object, then
the distance from it to the main object shrinks each time. I.e., if the
main object is at <0,0,0> and the "child" is at <0.00809, 0.00888,
1.29409>, then the following passes do this:
[20:43] Object: <-0.25235, -0.23316, 0.69239>
[20:43] Object: <-0.01824, 0.22825, -0.05867>
[20:44] Object: <0.15534, -0.26676, 0.06066>
[20:44] Object: <-0.30133, 0.21328, 0.07791>
[20:44] Object: <0.22322, 0.14242, -0.26685>
[20:44] Object: <0.10885, 0.17888, -0.19385>
[20:44] Object: <-0.16811, -0.19235, -0.21766>
[20:44] Object: <-0.12149, 0.12519, 0.19799>
[20:44] Object: <0.02029, -0.11608, -0.13033>
[20:44] Object: <-0.11644, 0.11593, 0.12039>
[20:44] Object: <0.15958, 0.01220, -0.11591>
[20:44] Object: <0.12300, 0.06275, -0.01218>
[20:44] Object: <-0.05051, -0.04145, -0.06274>
[20:44] Object: <0.00101, 0.03214, 0.04145>
[20:44] Object: <0.03001, -0.03942, -0.03215>
[20:44] Object: <-0.02687, 0.03668, 0.03942>
Getting closer and closer to <0,0,0>.
So, what am I doing wrong here, or what equations do I need instead. The
site I looked at "implied" that the existing "location", i.e., X,Y,Z of
the object would feed through the calculations to end up with something
the same "distance" from the center point as before. However, it was
also code intended to be used in Java or Flash for 3D, so the example
was a mess of crap that involved translating that into 2D points.
Obviosly I am missing something here, but I have no clue why/how the
code is supposed to work, so have no clue why it simply doesn't in this
case. (llGetLocalPos returns the position relative to the location of
the "master" prim, i.e., if the master is at 143,12,23, then the
"local" point is still centered on 0,0,0, supposedly, so that's not
where the issue seems to be coming from. :( )
Help please!!
--
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
|
|
| |
| |
|
|
From: scott
Subject: Re: Trying to code an "offset rotation" for SL.
Date: 15 Jul 2008 03:01:34
Message: <487c4b4e@news.povray.org>
|
|
|
| |
| |
|
|
> y = llCos(Rot.x)*y - llSin(Rot.x)*z;
> z = llSin(Rot.x)*y + llCos(Rot.x)*z;
This is not going to work, because you are setting the new "y" value in the
first line, then using it in the 2nd line (but you should be using the
previous y value).
Try something like
x2 = x;
y2 = llCos(Rot.x)*y - llSin(Rot.x)*z;
z2 = llSin(Rot.x)*y + llCos(Rot.x)*z;
x = llSin(Rot.y)*z2 + llCos(Rot.y)*x2;
y = y2;
z = llCos(Rot.y)*z2 - llSin(Rot.y)*x2;
x2 = llCos(Rot.z)*x - llSin(Rot.z)*y;
y2 = llSin(Rot.z)*x + llCos(Rot.z)*y;
z2 = z;
npos = <x2,y2,z2>;
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <487c4b4e@news.povray.org>, sco### [at] scott com says...
> > y = llCos(Rot.x)*y - llSin(Rot.x)*z;
> > z = llSin(Rot.x)*y + llCos(Rot.x)*z;
>
> This is not going to work, because you are setting the new "y" value in t
he
> first line, then using it in the 2nd line (but you should be using the
> previous y value).
>
> Try something like
>
> x2 = x;
> y2 = llCos(Rot.x)*y - llSin(Rot.x)*z;
> z2 = llSin(Rot.x)*y + llCos(Rot.x)*z;
>
> x = llSin(Rot.y)*z2 + llCos(Rot.y)*x2;
> y = y2;
> z = llCos(Rot.y)*z2 - llSin(Rot.y)*x2;
>
> x2 = llCos(Rot.z)*x - llSin(Rot.z)*y;
> y2 = llSin(Rot.z)*x + llCos(Rot.z)*y;
> z2 = z;
>
> npos = <x2,y2,z2>;
>
Figured it was "something" like that. The code for it, on the site, gave
"no" clue how/where to use the original values, at all. Almost as bad as
the stupid bartender HUD I picked up, which the clowns had popping a
"display next set of items" message to 12 different prims, only one of
which "had" a list to display, and then failing to "check" of the list
was empty. lol Nothing like spamming 11 empty menus to the client for
every page of "people" you had to give drinks out to.
I sometimes wonder if some people use "any" logic when trying writing
documentation, examples, or just coding. lol
Thanks for the fix.
--
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.22e5fee72acf026d98a181@news.povray.org>,
sel### [at] rraznet says...
>
> Thanks for the fix.
>
Actually. It maybe works, and maybe doesn't. lol This is a good start
though, since the real issue may be more subtle. If I am right about
what is going wrong this time, then SL supports:
Rotate everything via base prim.
Rotate locally, as though the base prim moved, but only move the object.
Rotate the object, but not the base prim.
Obviously, this is "still" a problem if your intent is to rotate the
third or forth object out from the center, like if you had body + upper
arm + lower arm, etc., and you want to move the lower arm. (This would
be, presumably an crane, or some other non-player object, just to be
clear.) By using local rotation *and* SetPos, I may have, in effect,
rotated the object to the Rot angle, by positioning it, then rotated it
"again" by that angle, using SetLocalRot. Needless to say, this is
"not" working as I had intended. lol I will have to experiment some more
to see what is really going on.
But, if it is the problem, then at least this math lends itself to
rotation at points "other" than the center of the objects, or around the
base prim, given a "bit" of modification. So, it could be set up to
rotate it at an object corner, a cylinders end cap, or any other
arbitrary point, on or off, the object. Which is a "vast" improvement
over the original situation. Just needs using "SetRot", instead of
"SetLocalRot" to get the right angle for the objects own facing.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, there is a bug in your "fixed" math (mind you, I was also forgetting
to convert to radians when doing the sin/cos, so that was what made it
go completely insane the first attempt... This however, rotating on the
Y axis, goes nuts:
vector Rot = <0,0,0>;
default
{
state_entry()
{
llSetTimerEvent(0);
llSetLocalRot(<0,0,0,0>);
llSetPos(<1,1,1>);
}
on_rez(integer dummy)
{
llSetTimerEvent(0);
}
touch_start(integer total_number)
{
llSetTimerEvent(0.2);
}
timer()
{
vector pos = llGetLocalPos();
vector bpos = llGetRootPosition();
llOwnerSay((string)pos);
//llOwnerSay((string)bpos);
vector npos;
float x = pos.x;
float y = pos.y;
float z = pos.z;
Rot = Rot + <0,1,0>;
if (Rot.x > 359)
{
Rot.x = 0;
}
if (Rot.y > 359)
{
Rot.y = 0;
}
if (Rot.z > 359)
{
Rot.z = 0;
}
float x2 = x;
float y2;
float z2;
y2 = llCos(Rot.x* DEG_TO_RAD)*y - llSin(Rot.x* DEG_TO_RAD)*z;
z2 = llSin(Rot.x* DEG_TO_RAD)*y + llCos(Rot.x* DEG_TO_RAD)*z;
y = y2;
z = llCos(Rot.y* DEG_TO_RAD)*z2 - llSin(Rot.y* DEG_TO_RAD)*x2;
x = llSin(Rot.y* DEG_TO_RAD)*z2 + llCos(Rot.y* DEG_TO_RAD)*x2;
x2 = llCos(Rot.z* DEG_TO_RAD)*x - llSin(Rot.z* DEG_TO_RAD)*y;
y2 = llSin(Rot.z* DEG_TO_RAD)*x + llCos(Rot.z* DEG_TO_RAD)*y;
npos = <x2,y2,z2>;
llSetPos(npos);
//llSetLocalRot(llEuler2Rot(Rot * DEG_TO_RAD));
//llSetRot(llEuler2Rot(Rot * DEG_TO_RAD));
}
}
Note, this is using "Rot = Rot + <0,1,0>;", or changing the rotation by
one degree in the Y axis each time. The result is:
[22:41] Object: <1.00000, 1.00000, 1.00000>
[22:41] Object: <0.99969, 1.01760, 1.00000>
[22:41] Object: <1.01607, 1.03549, 1.00000>
[22:41] Object: <1.04878, 1.05396, 1.00000>
[22:41] Object: <1.09741, 1.07327, 1.00000>
[22:41] Object: <1.16148, 1.09371, 1.00000>
[22:41] Object: <1.24037, 1.11553, 1.00000>
[22:41] Object: <1.33332, 1.13897, 1.00000>
[22:41] Object: <1.43941, 1.16427, 1.00000>
[22:41] Object: <1.55757, 1.19163, 1.00000>
[22:41] Object: <1.68650, 1.22125, 1.00000>
[22:41] Object: <1.82472, 1.25329, 1.00000>
[22:41] Object: <1.97058, 1.28788, 1.00000>
[22:41] Object: <2.12223, 1.32512, 1.00000>
[22:41] Object: <2.27763, 1.36508, 1.00000>
[22:41] Object: <2.43464, 1.40778, 1.00000>
[22:41] Object: <2.59100, 1.45322, 1.00000>
[22:41] Object: <2.74437, 1.50135, 1.00000>
[22:41] Object: <2.89242, 1.55206, 1.00000>
[22:41] Object: <3.03286, 1.60524, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.16347, 1.66070, 1.00000>
[22:41] Object: <3.15236, 1.71598, 1.00000>
[22:41] Object: <3.12541, 1.77079, 1.00000>
[22:41] Object: <3.08492, 1.82491, 1.00000>
[22:41] Object: <3.03322, 1.87813, 1.00000>
[22:41] Object: <2.97264, 1.93031, 1.00000>
[22:41] Object: <2.90536, 1.98131, 1.00000>
[22:41] Object: <2.83341, 2.03107, 1.00000>
[22:41] Object: <2.75858, 2.07953, 1.00000>
[22:41] Object: <2.68245, 2.12667, 1.00000>
[22:41] Object: <2.60630, 2.17249, 1.00000>
[22:41] Object: <2.53117, 2.21700, 1.00000>
[22:41] Object: <2.45784, 2.26024, 1.00000>
[22:42] Object: <2.38688, 2.30225, 1.00000>
[22:42] Object: <2.31867, 2.34307, 1.00000>
[22:42] Object: <2.25339, 2.38276, 1.00000>
[22:42] Object: <2.19114, 2.42137, 1.00000>
[22:42] Object: <2.13189, 2.45895, 1.00000>
[22:42] Object: <2.07555, 2.49556, 1.00000>
[22:42] Object: <2.02198, 2.53123, 1.00000>
[22:42] Object: <1.97101, 2.56602, 1.00000>
[22:42] Object: <1.92247, 2.59997, 1.00000>
[22:42] Object: <1.87616, 2.63311, 1.00000>
[22:42] Object: <1.83194, 2.66549, 1.00000>
[22:42] Object: <1.78962, 2.69714, 1.00000>
[22:42] Object: <1.74905, 2.72808, 1.00000>
[22:42] Object: <1.71012, 2.75834, 1.00000>
[22:42] Object: <1.67268, 2.78796, 1.00000>
[22:42] Object: <1.63664, 2.81695, 1.00000>
[22:42] Object: <1.60189, 2.84534, 1.00000>
[22:42] Object: <1.56834, 2.87315, 1.00000>
[22:42] Object: <1.53593, 2.90040, 1.00000>
[22:42] Object: <1.50456, 2.92710, 1.00000>
[22:42] Object: <1.47419, 2.95328, 1.00000>
In other words, it heads straight out to a corner, *then* starts
rotating.
Rotation in the X and Z vectors works correctly (well, mostly, there
seems to be some precision loss, maybe), though I still need to figure
out how to make the prim face the "direction" that it is supposed to
have moved to. Local rotation didn't seem to want to do that correctly.
Rotation in X:
[22:52] Object: <1.00000, 1.00000, 1.00000>
[22:52] Object: <1.00000, 0.98240, 1.01730>
[22:52] Object: <1.00000, 0.94629, 1.05097>
[22:52] Object: <1.00000, 0.88999, 1.09905>
[22:52] Object: <1.00000, 0.81116, 1.15846>
[22:52] Object: <1.00000, 0.70711, 1.22474>
[22:52] Object: <1.00000, 0.57521, 1.29195>
[22:52] Object: <1.00000, 0.41348, 1.35242>
[22:52] Object: <1.00000, 0.22123, 1.39680>
[22:52] Object: <1.00000, 0.00000, 1.41421>
[22:52] Object: <1.00000, -0.24558, 1.39273>
[22:52] Object: <1.00000, -0.50681, 1.32028>
[22:52] Object: <1.00000, -0.77024, 1.18606>
[22:52] Object: <1.00000, -1.01730, 0.98240>
[22:52] Object: <1.00000, -1.22474, 0.70711>
[22:52] Object: <1.00000, -1.36603, 0.36603>
[22:52] Object: <1.00000, -1.41400, -0.02468>
[22:52] Object: <1.00000, -1.34500, -0.43702>
[22:52] Object: <1.00000, -1.14412, -0.83125>
[22:52] Object: <1.00000, -0.81116, -1.15846>
[22:52] Object: <1.00000, -0.36603, -1.36603>
[22:52] Object: <1.00000, 0.14783, -1.40647>
[22:52] Object: <1.00000, 0.66393, -1.24868>
[22:52] Object: <1.00000, 1.09905, -0.88999>
[22:52] Object: <1.00000, 1.36603, -0.36603>
[22:52] Object: <1.00000, 1.39273, 0.24558>
[22:52] Object: <1.00000, 1.14412, 0.83125>
[22:52] Object: <1.00000, 0.64204, 1.26007>
[22:52] Object: <1.00000, -0.02468, 1.41400>
[22:52] Object: <1.00000, -0.70711, 1.22474>
[22:52] Object: <1.00000, -1.22474, 0.70711>
[22:52] Object: <1.00000, -1.41400, -0.02468>
[22:52] Object: <1.00000, -1.18606, -0.77024>
[22:52] Object: <1.00000, -0.57521, -1.29195>
[22:52] Object: <1.00000, 0.24558, -1.39273>
[22:52] Object: <1.00000, 1.00000, -1.00000>
This doesn't seem to be "exactly" right either, it seems to rotate more
than the one degree I was attempting, so I need to work out why, but its
way closer to what it should be doing than what "Rot = Rot + <0,1,0>;"
ends up generating...
Was right about how the rotations worked though. This method is needed
to rotate off of center, instead of just rotating around the prims own
center...
This is "very" close to what I was trying to do, but, obviously, there
is a bug some place in it. :(
--
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.22e72547d2aee12998a182@news.povray.org>,
sel### [at] rraznet says...
> In article <MPG.22e5fee72acf026d98a181@news.povray.org>,
> sel### [at] rraznet says...
> >
> > Thanks for the fix.
> >
> Actually. It maybe works, and maybe doesn't. lol This is a good start
> though, since the real issue may be more subtle. If I am right about
> what is going wrong this time, then SL supports:
>
> Rotate everything via base prim.
> Rotate locally, as though the base prim moved, but only move the object.
> Rotate the object, but not the base prim.
>
> Obviously, this is "still" a problem if your intent is to rotate the
> third or forth object out from the center, like if you had body + upper
> arm + lower arm, etc., and you want to move the lower arm. (This would
> be, presumably an crane, or some other non-player object, just to be
> clear.) By using local rotation *and* SetPos, I may have, in effect,
> rotated the object to the Rot angle, by positioning it, then rotated it
> "again" by that angle, using SetLocalRot. Needless to say, this is
> "not" working as I had intended. lol I will have to experiment some more
> to see what is really going on.
>
> But, if it is the problem, then at least this math lends itself to
> rotation at points "other" than the center of the objects, or around the
> base prim, given a "bit" of modification. So, it could be set up to
> rotate it at an object corner, a cylinders end cap, or any other
> arbitrary point, on or off, the object. Which is a "vast" improvement
> over the original situation. Just needs using "SetRot", instead of
> "SetLocalRot" to get the right angle for the objects own facing.
>
Was doing the sin/cos wrong. Ignore most of this. lol Still need to mod
it to do "off of center on the object", but its a "hair" more complex
than this, since the LocalRot isn't doing what I thought it did.
--
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
|
|
| |
| |
|
|
From: scott
Subject: Re: Trying to code an "offset rotation" for SL.
Date: 16 Jul 2008 02:51:38
Message: <487d9a7a@news.povray.org>
|
|
|
| |
| |
|
|
> This however, rotating on the
> Y axis, goes nuts:
If you're rotating only the y axis (ie Rot.x and Rot.z are zero), then the y
coordinate shouldn't change.
> y2 = llCos(Rot.x* DEG_TO_RAD)*y - llSin(Rot.x* DEG_TO_RAD)*z;
Since Rot.x is zero, the above line is equivalent to y2 = y
> y = y2;
Obvious.
> y2 = llSin(Rot.z* DEG_TO_RAD)*x + llCos(Rot.z* DEG_TO_RAD)*y;
Again, since Rot.z should be zero here, this line is again equivalent to y2
= y
> [22:41] Object: <1.00000, 1.00000, 1.00000>
> [22:41] Object: <0.99969, 1.01760, 1.00000>
I would suggest you check the values of Rot.x and Rot.z in your code, and
also the xyz coords after each rotation - none of them should modify the y
coordinate if only Rot.y is non-zero.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <487d9a7a@news.povray.org>, sco### [at] scottcom says...
> > This however, rotating on the
> > Y axis, goes nuts:
>
> If you're rotating only the y axis (ie Rot.x and Rot.z are zero), then th
e y
> coordinate shouldn't change.
>
> > y2 = llCos(Rot.x* DEG_TO_RAD)*y - llSin(Rot.x* DEG_TO_RAD)*z;
>
> Since Rot.x is zero, the above line is equivalent to y2 = y
>
> > y = y2;
>
> Obvious.
>
> > y2 = llSin(Rot.z* DEG_TO_RAD)*x + llCos(Rot.z* DEG_TO_RAD)*y;
>
> Again, since Rot.z should be zero here, this line is again equivalent to
y2
> = y
>
> > [22:41] Object: <1.00000, 1.00000, 1.00000>
> > [22:41] Object: <0.99969, 1.01760, 1.00000>
>
> I would suggest you check the values of Rot.x and Rot.z in your code, and
> also the xyz coords after each rotation - none of them should modify the
y
> coordinate if only Rot.y is non-zero.
>
Ok. First off, I am an idiot. The code is based on rotating an object at
a known point, so in theory, I should, I think, always start x,y,z at
1,1,1, the "start point", where the object was in the first place. That
may be having some effect, otherwise, I need to only rotate it by N
degrees every time, not "increase" N each pass. I suppose that "may" be
causing this odd behavior somehow, though, I can't imagine how, since
the vector length for any point on a rotation starting at 1,1,1 *should
be* the same, no matter what position the object occupies, i.e., the
vector length should still average to a line length of "1", not 3, or
what ever it comes out to.
It also seems damn strange to me, if the rotation values where causing
it, for Y to be producing that effect, either by itself, or combined
with any other values.. Hmm.. Will have to get back to you on what
happens when I fix the goof I made in trying to "read" the position
every time, instead of once, but that will be tomorrow. Its after 2am as
of posting this, and I was half asleep when I realized what one of the
places I had screwed up was. 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, this code, finally, mostly works:
vector Rot;
vector RotChange;
vector RotAngle;
float x;
float y;
float z;
default
{
state_entry()
{
llSetTimerEvent(0);
llSetLocalRot(<0,0,0,0>);
llSetPos(<1,1,1>);
Rot = <0,0,0>;
//Change to adjust how it moves.
RotChange = <10,0,0>;
}
on_rez(integer dummy)
{
llSetTimerEvent(0);
}
touch_start(integer total_number)
{
llSetTimerEvent(0.1);
vector pos = llGetLocalPos();
x = pos.x;
y = pos.y;
z = pos.z;
}
timer()
{
vector bpos = llGetRootPosition();
//llOwnerSay((string)pos);
//llOwnerSay((string)bpos);
vector npos;
Rot = Rot + RotChange;
RotAngle = Rot * DEG_TO_RAD;
if (Rot.x > 359)
{
Rot.x = 0;
}
if (Rot.y > 359)
{
Rot.y = 0;
}
if (Rot.z > 359)
{
Rot.z = 0;
}
float xx = x;
float xy = llCos(RotAngle.x)*y - llSin(RotAngle.x)*z;
float xz = llSin(RotAngle.x)*y + llCos(RotAngle.x)*z;
float yy = xy;
float yz = llCos(RotAngle.y)*xz - llSin(RotAngle.y)*xx;
float yx = llSin(RotAngle.y)*xz + llCos(RotAngle.y)*xx;
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>;
llSetPos(npos);
llSetLocalRot(llEuler2Rot(Rot * DEG_TO_RAD));
//llSetRot(llEuler2Rot(Rot * DEG_TO_RAD));
}
}
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, back to the starting point, then around in a curve, ending
up.. Well, its impossible to describe exactly, but, suffice to say that
instead of looping from 1,1,1, ending up at a point diagonal to where it
started, it instead ends up following some other odd path, which doesn't
fit what I expect to see. Would this be the so called "gimble lock"
issue that is sometimes described? I am more confused by what is going
wrong now, or even if it "is" going wrong, than I was before. 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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;
}
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 expecting
Euler angles, which are different from rotations about the global xyz axes
(like POV uses for "rotate" and what you are doing in those 3 groups of trig
functions). To make matters worse, Euler angles are not a universally
defined standard, does it say anything about the definition in the function
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
