1  |   Order by index

Mar 21, 2005, 2:43am

When I move a build with the x1 bots sometimes it will move things that have
move actions on them and other times it will not. Why is this? Should I
remove the move actions before I move a build and then replace them after
it's moved so that at least the object is still there? Will this help or
not? I moved a build and some of the objects with media were not moved also.
Maybe the media file should be removed while moving the build so that at
least the object is still where it is suppose to be located? Maybe it's a
cell data space issue on the new land? How can I work around this if anyone
knows?

Mar 21, 2005, 2:12pm

It is most likely a cell data issue, make sure that when you move it you
align it perfectly to a new cell like it was in the origional location (ie:
move whole cells only). This may help.

- MR


[View Quote]

Mar 22, 2005, 12:08am

OK, Thanks Strike Rapier. Will try

Mar 22, 2005, 1:17am

Hi,

Xelagot does not check the action field when moving objects. As Strike
Rapier said, the issue could be in the cell data limit, as the world
server *does* check the amount of text (model + description + action)
that can fit in a cell when you build new objects, so when you
copy/move objects, make sure that the same objects are reunited in a
cell as they were originally, if the source and destination world have
compatible data limits (i.e., the destination has the same or greater
data limit than the source when the source objects were built). X1
has a button to realign builds to the same cell composition, called
"round off" for when you translate (move) builds.

Hope this helps :)

On 20 Mar 2005 23:43:35 -0500, "HighFlier" <highflier at awgate.com>
[View Quote] >When I move a build with the x1 bots sometimes it will move things that have
>move actions on them and other times it will not. Why is this? Should I
>remove the move actions before I move a build and then replace them after
>it's moved so that at least the object is still there? Will this help or
>not? I moved a build and some of the objects with media were not moved also.
>Maybe the media file should be removed while moving the build so that at
>least the object is still where it is suppose to be located? Maybe it's a
>cell data space issue on the new land? How can I work around this if anyone
>knows?
>

Mar 24, 2005, 6:01am

Thank You for info XelaG. It worked :) I used the round off button like you
said tonight and it worked like a charm. I suspected incorrect cell limit
all along. Before I was not installing the build in the same cell positions
like you said. I guess is how you say it. Now I know some of the other
buttons and they are very useful. I suppose moving an over built build was a
good experience for me and forced me to learn those other buttons. I also
leaned last night how to rotate a build I moved and it was fun to see it in
the different postition with a little different lighting and shadows from
it's changed position which made one build look much better. I also want to
thank tunablues for checking my post and sending me a gram with similar
information.

Mar 26, 2005, 10:20am

Rotating builds work well if the objects are not tilted. Xelagot can
not at present cope with objects that have tilt or roll, it only
handles the yaw parameter, which works fine on untilted/unrolled
objects.

To handle all rotation parameters properly, a rotaion matrix must be
constructed for the Rotation operation. A second matrix must then be
made for each object from its Euler angles (yaw, tilt, roll), and both
matrices must be cross-multiplied, then new Euler angles have to be
extracted from the resulting matrix for that particular object. The
problem is the interaction of Euler angles with complex rotations:
from the original yaw-tilt-roll (which can be in six different
combinations of sequences of rotation axes, for example tilt-yaw-roll,
tilt-roll-yaw etc) a rotation matrix has to be made for each object.
This is not a problem if the combination used by AW is known, which it
isn't officially. After applying the matrix to a particular object's
rotation matrix, the new yaw-tilt-roll must be extracted for that
object, using the same combination sequence. This can produce cases of
Gimbal Lock, where the resulting Euler Angles are undefined. This
always happens when the second rotation axis is rotated 90 or 270
degrees, then the resulting Euler angles can not be calculated.

If I knew the sequence used by AW, I could experiment with this,
although it would take a considerable amount of time to get it right.

Alex

On 24 Mar 2005 03:01:19 -0500, "HighFlier" <highflier at awgate.com>
[View Quote] >Thank You for info XelaG. It worked :) I used the round off button like you
>said tonight and it worked like a charm. I suspected incorrect cell limit
>all along. Before I was not installing the build in the same cell positions
>like you said. I guess is how you say it. Now I know some of the other
>buttons and they are very useful. I suppose moving an over built build was a
>good experience for me and forced me to learn those other buttons. I also
>leaned last night how to rotate a build I moved and it was fun to see it in
>the different postition with a little different lighting and shadows from
>it's changed position which made one build look much better. I also want to
>thank tunablues for checking my post and sending me a gram with similar
>information.
>

Mar 26, 2005, 9:13pm

Hi Alex-

I've looked into this a bit, and I believe the order is yaw-roll-tilt. You
can verify this by manually rotating an object from zero rotation, a known
amount in a given order. Then check the resulting angles according the AW,
and see if it matches the rotations you made.

In cases Gimal Lock you should be able to just choose one of the equivalent
values. If you do figure out the math to extract the angles from the
matrix, please let me know, as I could use it. I haven't had time myself.

I suspect that yaw-only rotation would work fine even on objects that do
have tilt/roll, simply by adding the two yaw values. This is only because
the yaw is applied first, and the build rotation should get applied before
the object rotation.

Maybe AWI could be convinced to document the math they use, or better yet
expose rotation functions in the SDK?

--
Rich

[View Quote]

Mar 27, 2005, 10:48am

[View Quote] >Hi Alex-

Hi Scifair,

>
>I've looked into this a bit, and I believe the order is yaw-roll-tilt. You
>can verify this by manually rotating an object from zero rotation, a known
>amount in a given order. Then check the resulting angles according the AW,
>and see if it matches the rotations you made.

I think Tilt is the second rotation (X-axis), not roll. At least, it
seems to be so in the browser's treatment of the look-up and look-down
functions (Pitch for avatars = Tilt for objects). When the beta
browser allowed looking straight up or down (-90 and +90 degrees),
somewhere in 3.4 I think, Gimbal Lock struck, so they had to reduce
the range. This was confirmed by Shamus in a posting a while ago in
the beta ng.

>
>In cases Gimal Lock you should be able to just choose one of the equivalent
>values. If you do figure out the math to extract the angles from the
>matrix, please let me know, as I could use it. I haven't had time myself.

Unfortunately, chosing equivalent values does not seem to work or, to
put it another way, alternative values can not be found when Gimbal
Lock occurs - in all other cases, there are always 2 sets of (x, y, z)
values which are equivalent for the same rotation. The reason being
that in the process of extracting Euler Angles, a division occurs by
the cosine of the second angle. If the angle is + or - 90, this cosine
is = 0, and you can't divide by 0. A similar thing occurs when
changing from Euler to Matrix notation.

I have a full set of Delphi routines, including Euler to
Matrix/Quaternion and reverse. These Euler chappies are the
problematic ones. If you request by email (xelag at 3dee.nl) I will send
you the unit.

>
>I suspect that yaw-only rotation would work fine even on objects that do
>have tilt/roll, simply by adding the two yaw values. This is only because
>the yaw is applied first, and the build rotation should get applied before
>the object rotation.

It doesn't, as was reported in a recent email by someone who uses
xelagot to move and rotate groups of builds. When tilt and roll are
present in an object (i.e. <> 0), rotating using only the yaw, as
xelagot does, fails to rotate the object properly.

>
>Maybe AWI could be convinced to document the math they use, or better yet
>expose rotation functions in the SDK?

That would be nice, I'd rather have the documentation though :)

Alex

Mar 27, 2005, 8:35pm

Hi Alex-

See my comments inline.

--
Rich

[View Quote] I started with 2 objects, and rotated each 2 clicks (30 deg) on each axis.
The first I did in the order yaw-tilt-roll, the other I did yaw-roll-tilt.
Here are the resulting propdump entries:

41 1111956050 -800 100 250 139 -337 -257 9 13 0 sign3.rwxyaw-tilt-roll
41 1111956095 -788 100 299 300 -300 -300 9 13 0 sign3.rwxyaw-roll-tilt

Oddly enough, I rotated left, +x, and +z, and got negative roll/tilt values.

I believe this means that when you are trying to come up with angles to give
as object properties, you want to extract from the matrix as if applied in
yaw-roll-tilt order. In other words, the rotation determined by a set of
angles in a propdump is equivalent to the 3 separate rotations applied in
yaw-roll-tilt order. When you rotate an entire build, apply the build
rotation first, followed by the object rotation, so that the object gets
rotated in the build frame.

I'm not so sure the avatar pitch problem you mentioned is evidence for a
yaw-tilt-roll order. The avatar's roll is always zero.

>
> Unfortunately, chosing equivalent values does not seem to work or, to
> put it another way, alternative values can not be found when Gimbal
> Lock occurs - in all other cases, there are always 2 sets of (x, y, z)
> values which are equivalent for the same rotation. The reason being
> that in the process of extracting Euler Angles, a division occurs by
> the cosine of the second angle. If the angle is + or - 90, this cosine
> is = 0, and you can't divide by 0. A similar thing occurs when
> changing from Euler to Matrix notation.

What I mean is choose one of those equivalent sets of angles and use it.
Check for gimbal lock and treat it as a special case. This is what I have
seen done in other places, though of course I didn't understand it well
enough to apply the math quickly to a different rotation order. All you
need is one set of angles that results in the desired rotation; it doesn't
matter if it's the "original" one.

> I have a full set of Delphi routines, including Euler to
> Matrix/Quaternion and reverse. These Euler chappies are the
> problematic ones. If you request by email (xelag at 3dee.nl) I will send
> you the unit.

Will do.

>
> It doesn't, as was reported in a recent email by someone who uses
> xelagot to move and rotate groups of builds. When tilt and roll are
> present in an object (i.e. <> 0), rotating using only the yaw, as
> xelagot does, fails to rotate the object properly.

Does your code sum the yaws (or subtract them depending on Xelagot's
definition of positive yaw) and leave the tilt/roll as-is? Note that
something is funny with the signs of the angles AW expects. A quick test
changing the yaws in a propdump by hand seems to behave as expected for me.

>
> That would be nice, I'd rather have the documentation though :)
>
> Alex

Mar 27, 2005, 10:42pm

[View Quote] Quick reply, its late, 2:30 am here :)

The rotations in AW (and in RWX and openGL) are right-handed (say
positive from North to West for yaw), so the signs are opposite to
many other systems, included many scientific ones.

As for using the browser to apply yaw/tilt/roll, it is no indication.
If I have rolled an object, and then with the browser apply a yaw
(middle 2 rotation buttons in the browser's thingy), the yaw is
applied along the tilted yaw axis, i.e. in the object's local "rolled"
coord system: it applies the "browser" yaw before the other.Just check
that, you can see it visually, the Y or yaw axis remains tilted in
exactly the same position no matter how many clicks you apply.This is
fine for browser use, but is not what I need, because I have to rotate
around the new yaw axis, the one pointed vertically up, not around the
original yaw axis which is now rolled.

As for avatar's pitch, in fact the camera is tilted, which means
simply that the world is tilted for the camera. This is equivalent to
rotating all objects vertically in the oposite direction of the
camera.

I'll have to sleep over it a few nights, and I'm hoping to get some
more insight in the actual rotation order.

I've sent you the requested unit in Delphi pascal.

Mar 28, 2005, 1:40am

Hi Alex-

The use of the browser is informative. Each rotation in the browser is in
fact a separate rotation, applied in the order in which I do them. However,
putting a set of angles in an object's attributes (using a bot or loading a
propdump) is a compound rotation that will be calculated in the order in
which AW applies the rotations. Therefore, if I apply 3 separate yaw, tilt
and roll rotations in sequence in the browser, and the propdump shows the
rotation as the exact amounts in my manual rotation, then I have used the
same order of rotation that AW uses. If I see values that are different,
then I must have applied the rotations in a different order. This match
occurs with the order yaw-roll-tilt.

What you need to do to calculate the angle for an object in a rotated build
is first calculate the matrix for the build's overall rotation, and then
rotate the object relative to it (of course you also need to calculate the
new position, but that's relatively easy). So, lets say you want to rotate
a build by angle (yb, tb, rb), and it contains an object at angle
(yo,to,ro). To calculate the resulting angle, start with the matrix for no
rotation, then apply the rotations yb, rb, tb, yo, ro, to (in other words,
apply the entire build angle followed by the object angle, using
yaw-roll-tilt order). Then convert the resulting matrix back to angles,
checking for and dealing with gimbal lock conditions. Of course, you should
save the result of the first rotation because it will be the same for every
object and you only need to calculate it once.

If you are only applying world-up (world frame) yaw rotation to objects, you
can simply do this by adding that yaw value to the one recorded by AW,
regardless of tilt/roll values (which should remain unchanged). This is
different from opening the browser and clicking the rotate yaw button, in
that it is equivalent to applying your additional yaw rotation BEFORE the
object's existing tilt/roll. This is because yaw is applied first. The
tilt and roll thus occur in the yaw-rotated frame of reference you with to
create; this will work regardless of whether tilt or roll is applied first.
You must be sure the yaw value you add has a sign that is consistent with
the calculation you use for position.

The avatar pitch is equivalent to tilting all the objects in the world
(about the origin), prior to applying each object's individual rotation.
The reason it doesn't help to determine the rotation order is that the
avatar's orientation always has a roll of zero, and so you cannot tell
whether the tilt or roll is being applied first from this.

Note that the order I gave here may seem backwards depending on which way
you multiply the matrices; I'm not remembering all the details of
transformation matrix stacks very clearly right now.

My point about the negative rotation values was that I rotated in what the
browser called the positive direction, and yet it actually rotated in the
negative direction. A right-handed system makes sense, but labeling +X
rotation -X does not, and could lead to confusion in tests.

I got the code, thanks.

--
Rich

[View Quote]

Mar 28, 2005, 4:00pm

[View Quote] >My point about the negative rotation values was that I rotated in what the
>browser called the positive direction, and yet it actually rotated in the
>negative direction. A right-handed system makes sense, but labeling +X
>rotation -X does not, and could lead to confusion in tests.

You are perfectly right there, AW buttons invert the signs of
right-handed rotations around the X and Z axes, plus should be minus
and vice versa :)

1  |   Order by index