 | | | | | | |
| |
|
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.
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.
> > Works like a charm so far, and I haven't found any parts that
> > aren't solvable by a single exception matrix yet.
>
> Me neither.
Yeah, and we don't need no models with no funky new parts that don't mirror
right anyway! ;-)
> And generating the MIRROR.INI file. I did some corner parts, some
> triangular wings, some minifig arms and legs, and some technic liftarms.
> I also created a tiny C program to parse MIRROR.INI and use it to mirror
> a file across the ZY plane. It seems to work so far. The source, ini,
> and a windows command line executable is here:
>
> http://ldglite.sf.net/mirwin.zip
>
> If anyone wants to update MIRROR.INI for all 2500 parts, that'd be
> fantastic.
Can't promise that--I am adding an exception matrix editor to my program that
should make the task easier though!
Carl
| | | | | | | | | | | | | | | |
In lugnet.cad, Carl Nelson wrote:
> Yeah, and we don't need no models with no funky new parts that don't
> mirror right anyway! ;-)
We already got some of them. The 4360 Space laser gun with side sight
is gonna to be a problem. You just *know* someone out there'll hook
it up to something by the stud on the asymetric sight portion. And
there'll be no end to the whining when it mirrors itself right into
some adjacent part. Oh well.
> > If anyone wants to update MIRROR.INI for all 2500 parts, that'd be
> > fantastic.
>
> Can't promise that--I am adding an exception matrix editor to my
> program that should make the task easier though!
Don't forget to add a way to keep track of parts that have been
cleared to use the default mirror matrix. That way we'll know when
the job is done. (yeah right :^)
Don
PS. I like your lmirror icon. How'd you make it?
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
> We already got some of them. The 4360 Space laser gun with side sight
> is gonna to be a problem. You just *know* someone out there'll hook
> it up to something by the stud on the asymetric sight portion. And
> there'll be no end to the whining when it mirrors itself right into
> some adjacent part. Oh well.
Yup, oh well. I guess the mirror specification could always translate it with
no rotation, or add a comment to the LDraw file saying that this part needs to
be checked for proper placement.
> PS. I like your lmirror icon. How'd you make it?
Thanks! I put a 2 x 2 red brick by a 1 x 6 x 5 white brick and rendered it with
-lgeo, then Photoshopped it to icon size.
BTW, thanks for the source code! Makes me realize how rusty my C++ is these
days, since it's been a year or two since I've written anything in it...
Carl
| | | | | | | | | | | | | | | | | |
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
| | | | | | |
