| |
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Don Heyse wrote:
> > > To unmirror, the C element should be -1.
> >
> > Err, I'm not sure what you mean by unmirror. I got
> > (0 0 1 0 1 0 1 0 0 0 0 0) for a mirror.ini exception matrix, which
> > looks yours except for the sign of that one number.
>
> Unreflect is a better word--just undo the X coordinate swap that
> -1 0 0 0 1 0 0 0 1 does.
Would that work in general cases, or just for right-left reflection?
> I believe they're equivalent things--I'm doing a clockwise rotation, then
> negating the X coordinate swap, you're doing the opposite rotation. I think
> both work for the part.
Actually, I think they're not - "Steve's algorithm" (ha!) requires that both the
MP and ME transforms be mirroring, so that the MF transform would be
non-mirroring.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Carl Nelson wrote:
> > Unreflect is a better word--just undo the X coordinate swap that
> > -1 0 0 0 1 0 0 0 1 does.
>
> Would that work in general cases, or just for right-left reflection?
It would need to determine the plane of reflection, and do the second reflection
on the X components for left-right or Z components for front-back.
> > I believe they're equivalent things--I'm doing a clockwise rotation, then
> > negating the X coordinate swap, you're doing the opposite rotation. I think
> > both work for the part.
>
> Actually, I think they're not - "Steve's algorithm" (ha!) requires that both the
> MP and ME transforms be mirroring, so that the MF transform would be
> non-mirroring.
I've come up with the same results in all cases so far. I'll do some thinking
as to which is conceptually easier to generate--ideas?
Carl
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> Actually, I think they're not - "Steve's algorithm" (ha!) requires that both the
> MP and ME transforms be mirroring, so that the MF transform would be
> non-mirroring.
Can you or Don check my work? I'm trying to figure out why the ME transform
that I did works in my program and the ME that Don put in mirror.ini works in
his code, but not vice-versa. The most likely explanation is that I'm doing
something stupid.
MP matrix (reflection about the plane containing the Z & Y axes):
-1 0 0
0 1 0
0 0 1
MC matrix (current piece value for a 2357 2 x 2 corner brick)
1 0 0
0 1 0
0 0 1
Don's ME matrix for 2357:
0 0 1
0 1 0
1 0 0
MP * MC =
-1 0 0
0 1 0
0 0 1
(MP * MC) * ME =
0 0 1
0 1 0
-1 0 0
which is a 180-degree rotation out from where it should be. What's my error
here?
Thanks,
Carl
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Steve Bliss wrote:
> > Actually, I think they're not - "Steve's algorithm" (ha!) requires that both the
> > MP and ME transforms be mirroring, so that the MF transform would be
> > non-mirroring.
>
> Can you or Don check my work? I'm trying to figure out why the ME transform
> that I did works in my program and the ME that Don put in mirror.ini works in
> his code, but not vice-versa. The most likely explanation is that I'm doing
> something stupid.
Probably. ;^)
> MP matrix (reflection about the plane containing the Z & Y axes):
> -1 0 0
> 0 1 0
> 0 0 1
>
> MC matrix (current piece value for a 2357 2 x 2 corner brick)
> 1 0 0
> 0 1 0
> 0 0 1
>
> Don's ME matrix for 2357:
> 0 0 1
> 0 1 0
> 1 0 0
>
> MP * MC =
> -1 0 0
> 0 1 0
> 0 0 1
>
> (MP * MC) * ME =
> 0 0 1
> 0 1 0
> -1 0 0
>
> which is a 180-degree rotation out from where it should be. What's my error
> here?
Matrix multiplication is not commutative. (distributive? Err, I
forget my math terms.) You're doing one or more of the multiplications
in the wrong order?
Try ME * (MC * MP) instead. Notice I switched the order inside the
parens, and outside.
Check how I do it in my code. You'll probably have to fetch L3Math.c
and L3Def.h from the ldglite CVS archive on the sourceforge to see
the order, because I think I only put the new stuff in the mirwiz.zip
file.
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> Matrix multiplication is not commutative. (distributive? Err, I
> forget my math terms.) You're doing one or more of the multiplications
> in the wrong order?
It's neither commutative [(a * b) * c != a * (b * c)] nor associative [a * b !=
b * a].
That shouldn't be the problem in the calculation above, since the current matrix
was the identity matrix...
> Try ME * (MC * MP) instead. Notice I switched the order inside the
> parens, and outside.
> Check how I do it in my code. You'll probably have to fetch L3Math.c
> and L3Def.h from the ldglite CVS archive on the sourceforge to see
> the order, because I think I only put the new stuff in the mirwiz.zip
> file.
Looks like you're doing MF = MP * (MC * ME) in the code?
Thanks,
Carl
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> > Check how I do it in my code. You'll probably have to fetch L3Math.c
> > and L3Def.h from the ldglite CVS archive on the sourceforge to see
> > the order, because I think I only put the new stuff in the mirwiz.zip
> > file.
>
> Looks like you're doing MF = MP * (MC * ME) in the code?
Yes, that looks right.
The other thing that messes me up with LDRAW matrices is the row,
column ordering. The ordering in LDRAW files is not what I would
have chosen, so I always have to look it up. From the old FAQ:
http://www.ldraw.org/OLD/community/memorial/archive/FAQ/
Line type 1's format is:
Line Format:
1 colour x y z a b c d e f g h i part.dat
Fields a through i are orientation & scaling parameters, which can be
used in 'standard' 3D transformation matrices. Fields x, y and z also
fit into this matrix:
| a d g 0 |
| b e h 0 |
| c f i 0 |
| x y z 1 |
so that every point (x, y ,z) gets transformed to (x', y', z') :
x' = a*x + b*y + c*z + x
y' = d*x + e*y + f*z + y
z' = g*x + h*y + i*z + z
or, in matrix-math style:
| a d g 0 |
| X' Y' Z' 1 | = | X Y Z 1 | x | b e h 0 |
| c f i 0 |
| x y z 1 |
Now, I'm not actually sure what the row-column order is in the
MLCAD.INI file. Since (x,y,z) was moved to last, maybe the 3x3
is laid out in rows instead of columns. I suppose we should get
that clarified so we use the same format in the MIRROR.INI file.
Here's what MLCAD.INI says:
; <Matrix> a rotation matrix a11 a12 a13 ... a33 for optimal appearance
; at 0 degree rotation angle
; <Offset> The offset of the part to be in place
I don't know if a12 is b, or if a21 is b. It looks like this in the file:
"Cap" "4485.DAT" 0 1 0 0 0 1 0 0 0 1 0 0 0
Is that a b c d e f g h i x y z ???
Or is it a d g b e h c f i x y z ???
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> The other thing that messes me up with LDRAW matrices is the row,
> column ordering. The ordering in LDRAW files is not what I would
> have chosen, so I always have to look it up. From the old FAQ:
>
> http://www.ldraw.org/OLD/community/memorial/archive/FAQ/
>
> Line type 1's format is:
>
> Line Format:
> 1 colour x y z a b c d e f g h i part.dat
Total side note: I agree with Don, row/column ordering is not what I would have
chosen. BUT, it is far easier (IMO) to hand-transform row/column LDraw commands
than the equivalent column/row commands (like I've had to do in POV-Ray code).
Steve
|
|
| |
Hi Don,
now it's getting interesting ...
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:HzrwBF.9t2@lugnet.com...
<SNIP>
> Line type 1's format is:
>
> Line Format:
> 1 colour x y z a b c d e f g h i part.dat
>
> Fields a through i are orientation & scaling parameters, which can be
> used in 'standard' 3D transformation matrices. Fields x, y and z also
> fit into this matrix:
>
> | a d g 0 |
> | b e h 0 |
> | c f i 0 |
> | x y z 1 |
I'm actually reading it in as
| a b c |
| d e f |
| g h i |
and that is also how I'm writing my matrixes of meta commands ....
if that is wrong, why do I not have any problem when reading files?!?!?!? -
I'm a bit confused now ...
<SNIP>
> Here's what MLCAD.INI says:
Please read also the specification of MLCad extensions in the developer
section of my web-pages. It explains nearly everything. - except the read
order shown above.
Regards,
Michael
|
|
|
