LISP: how to convert UCS to XYZ angles?
Crystal Interactive Design
Can anybody help me with solving the riddle of how to convert the 210
group of an entity, into normal world XYZ rotations in degrees/radians
using AutoLISP???
I know that the UCS (= 210 group) describes a vector of length=1, from
which I can derive the angles, but how? Tried many roads, but all
dead-ending..
Any small AutoLISP routine or pseudo code is welcomed very very much.
Thanks in advance.
Jo Mantelers
--
Crystal Interactive Design
De Run 2180
5503 LE Veldhoven
The Netherlands
Phone: +31-40-2549088
Fax: +31-40-2549099
Jon Fleming
Coordinate System (ECS).
I am not sure what angles you are looking for. Are you trying to find the
three rotations involved in transforming WCS to OCS? The three components
of the 210 group are the cosines of the angles. For arc-cosine:
;;; arccosine (inverse cosine) accepts an argument in the
;;; range -1.0 to 1.0 inclusive, and returns an angle in
;;; radians in the range pi to 0 inclusive
(defun acos (z /)
(atan (sqrt (- 1.0 (* z z))) z)
) ;_ end defun
jrf
Member of the Autodesk Discussion Forum Moderator Program
Pierre Cardinal
Give a look at the AutoLISP function "(trans ... )".
Good luck,
Pierre
Crystal Interactive Design <c...@iaehv.nl> a écrit dans le message :
374E6D17...@iaehv.nl...
> Hi,
>
> Can anybody help me with solving the riddle of how to convert the 210
> group of an entity, into normal world XYZ rotations in degrees/radians
> using AutoLISP???
>
> I know that the UCS (= 210 group) describes a vector of length=1, from
> which I can derive the angles, but how? Tried many roads, but all
> dead-ending..
>
Crystal Interactive Design
Thanks for your reply. I immedialtelly tried your suggestion, but still have
not found the key to my problem. Let me explain the goal first:
I am making an exporter to write block insertion data (pos, rot, scale) to
another (ascii) file, in a format similar to VRML. The exporter we are using
now (3rd party product), converts the correct data using a DXF file as input
format, but we try to recreate and customize this exporter.
Because the result of this 3rd party converter is correct, I use that output
to check the result of my routine. Your suggestion gave different results.
I hope by giving you a 210 group value and the corresponding 3rd party
converter output, you can tell me what to do.
The 210 group values are
(210 0.707107 -0.353553 0.612372)
The resulting 3D world angles should become:
(51.2908, 11.7009, 78.2991)
I hope you can help.
Thanks in advance,
Jo Mantelers
Jon Fleming schreef:
> Actually, the 210 group is Object Coordinate System (OCS), nee Entity
> Coordinate System (ECS).
>
> I am not sure what angles you are looking for. Are you trying to find the
> three rotations involved in transforming WCS to OCS? The three components
> of the 210 group are the cosines of the angles. For arc-cosine:
>
> ;;; arccosine (inverse cosine) accepts an argument in the
> ;;; range -1.0 to 1.0 inclusive, and returns an angle in
> ;;; radians in the range pi to 0 inclusive
>
> (defun acos (z /)
> (atan (sqrt (- 1.0 (* z z))) z)
> ) ;_ end defun
>
> jrf
> Member of the Autodesk Discussion Forum Moderator Program
>
> In article <374E6D17...@iaehv.nl>, Crystal Interactive Design wrote:
> > Hi,
> >
> > Can anybody help me with solving the riddle of how to convert the 210
> > group of an entity, into normal world XYZ rotations in degrees/radians
> > using AutoLISP???
> >
> > I know that the UCS (= 210 group) describes a vector of length=1, from
> > which I can derive the angles, but how? Tried many roads, but all
> > dead-ending..
--
Jon Fleming
Calculating the rotation is a little more complex than you realize. This is
because of the way Autodesk chose to implement arbitrary orientations in 3D.
The 210 group stores a unit vector that is specified in World Coordinate
System (WCS) and points along the Z axis of the Object Coordinate System
(OCS). This unit vector stores two-point-something units of information
(since once you know two components you know the third except for its sign).
As you no doubt know, six units of information (three translations and three
rotations) are required to transform between two arbitrary same-handedness
same-scale coordinate systems. (The scaling can be done after the coordinate
transformation). So where do the other 3-point-something units of information
come from?
Well, three of them come from an arbitrary decision; the origin of the OCS is
at the origin of the WCS. Now for the point-something ...
Enter the "Arbitrary Axis Algorithm" (AAA). This is a method for deriving the
OCS X-axis from the OCS Z-axis and the WCS Z-axis. If the absolute value of
the X component of the 210 group is less than 1/64 _and_ the absolute value of
the Y component of the 210 group is less than 1/64, then the OCS X axis is
obtained from the cross-product of the OCS Z-axis and the WCS Y-axis.
Otherwise, the OCS X axis is obtained from the cross product of the OCS Z-axis
and the WCS Z-axis. This is equivalent to supplying the final needed
information. You seldom need to actually _use_ the AAA, but you need to
understand that it exists, and the consequences.
There are a few consequences of this specification. One is that it is
impossible to recreate the UCS that was in effect when an entity was created.
The consequence that is of most importance to you is that the rotation angle
of the block insert (contained in the 50 group and specified in radians) is
_not_ the rotation angle that the user specified when inserting the block! It
is that rotation angle plus the angle between the OCS X-axis and the X-axis of
the UCS that was in effect when the user inserted the block.
So, finally, you probably need to look at the 50 group as well as the 210
group.
I am still not sure _exactly_ what you want. I think you are trying to
calculate the rotations between WCS and what I call "Natural Coordinate
System" (NCS). In NCS the insert has a rotation of zero, so NCS is just OCS
rotated by the amount contained in the 50 group. Is this what you are looking
for?
If you are working in LISP or can read LISP, you with want to look at
BIXFORM.ZIP from http://www.cadalog.com
jrf
Member of the Autodesk Discussion Forum Moderator Program
Jo Mantelers
Thanks again. I looked at your BIXFORM.lsp and understand it (my lisp is pretty
ok, but not my matrix math ...). Unfortunatelly it didn't bring me much closer to
my target, because also in these routines you work with unit vectors along NCS
axis (XA, YA, ZA) expressed in WCS, and not with angles....For use inside AutoCAD,
this works great, but in my case I just want 3 angles...
Also, to be clear, I don't want to transform entities inside AutoCAD, I just want
to scan the drawing (ssget), and then output the 3D rotation of every INSERT
entity to another external ascii file, meaning I have to convert the 210 and 50
group of the INSERT somehow (via your bixform.lsp?),
and do (princ xrot fd)(princ yrot fd)(princ zrot fd), where xrot is x rotation in
real world degrees of the INSERT (so _not_ relative to a OCS), and fd the file
descr.
As I said before, I am not that great in matrix math, so I cannot derive from your
routines the correct rotations, but I suspect it is somewhere in the matrix
composed from XA,YA, ZA. Am I right? As I can see you're an expert in matrix, this
might be easy for you to answer, so if you can, thanks very much.
Sorry to keep on bothering you, and thanks again for the help.
Jo Mantelers
Jon Fleming
you want. See http://learn.lboro.ac.uk/olmp/chap9/9_3.html or
http://freeabel.geom.umn.edu/docs/reference/CRC-formulas/node52.html. Unfortunately
I used th internal AutoCAD (trans ...) function, but maybe it'll be a start on
deriving your own formulas. Taking the 50 group into account is the key concept ...
jrf
Member of the Autodesk Discussion Forum Moderator Program
Reini Urban
>The components of the unit vectors along the NCS axes are the cosines of the angles
>you want. See http://learn.lboro.ac.uk/olmp/chap9/9_3.html or
>http://freeabel.geom.umn.edu/docs/reference/CRC-formulas/node52.html. Unfortunately
>I used th internal AutoCAD (trans ...) function, but maybe it'll be a start on
>deriving your own formulas. Taking the 50 group into account is the key concept ...
better use TRANS because it is much easier and you won't loose any
precision (numeric over- or underflow). matrix algebra is not quite
suitable for autolisp without proper scaling and preparation. TRANS
handles all this.
doing it by hand the precision will most likely degrade from 14 to about
6 digits, esp. with numbers like these.
--
Reini
Jon Fleming
> better use TRANS because it is much easier and you won't loose any
> precision (numeric over- or underflow). matrix algebra is not quite
> suitable for autolisp without proper scaling and preparation. TRANS
> handles all this.
You can't use (trans ...) to convert a point in "block coordinates" (e.g.
obtained form the block table) into the corresponding point in an insert's
OCS or WCS. The transformation carried out by (trans ..) isn't general
enough.
(trans ...) is useful in setting up the matrices, though.