| |
In lugnet.cad, Don Heyse wrote:
> Under Steve's scheme the exception matrix for 3045.dat would be
> created by multiplying a mirror matrix by a rotate 90 matrix. This
> would create a part that looks identical, but is in fact mirrored. So
> I don't think you need more than one exception matrix per part. Look
> at this. The second part looks similar, but is actually mirrored.
> That's the exception matrix for MIRROR.INI (except for the -32 Z
> offset).
>
> 1 2 0 0 0 1 0 0 0 1 0 0 0 1 3045.dat
> 1 1 0 -32 0 0 0 -1 0 1 0 -1 0 0 3045.dat
>
> Here's Steve's method using homogeneous 4x4 matrices (because they
> make the math pretty):
>
> Default = MD = (-1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1)
> Exception = ME = (a, d, g, 0, b, e, h, 0, c, f, i, 0, x, y, z, 1)
>
> For a typical (left right symmetric) part ME = MD
>
> Current = MC = (A, D, G, 0, B, E, H, 0, C, F, I, 0, X, Y, Z, 1)
> Mirror across an arbitrary plane = MP = (...)
> see http://www.geocities.com/SiliconValley/2151/matrices.html
> (or use a simple mirror across the xy, yz, or xz plane).
>
> For each part, calculate MF (final matrix) where:
> Mirrored (with no mirrored parts) = MF = MP * MC * ME
Steve, Don--thanks for the explanations; this now makes complete sense to me
(finally!).
For a reflection about the plane containing the Z & Y axes (left-to-right), the
reflection matrix (Mp) should be:
-1 0 0
0 1 0
0 0 1
Then Mp * (part-file rotation matrix from LDraw file) * Mp works for most parts.
Substitute the second Mp for the exception matrix for the exception parts. The
exception matrix needs to rotate to proper orientation and unmirror the
part--for 2357 (brick 2 x 2 corner), the rotation matrix is:
0 0 -1
0 1 0
1 0 0
To unmirror, the C element should be -1.
Works like a charm so far, and I haven't found any parts that aren't solvable by
a single exception matrix yet.
Anybody see a problem with the algorithm to generate the rotation matrix setting
A = -A and C = -C every time? One should always be 0, right?
> Unless the text parsing code is already written. Then it's the same.
> I put the MLCAD.INI (minifig configurator) file parsing in CVS on the
> sourceforge, and the proposed MIRROR.INI file uses the same format.
> However if you want to convert to and from XML, that's ok with me.
OK, I haven't done anything else about the config file, but I'll stick with text
if everyone thinks that's a better idea.
> Sounds like it could work.
Now I just have to program it! ;-)
> Forget about rotation and use Steve's plan. Universally applying
> 2 mirror matrices works for all parts. In this case, the exceptions
> use a default left-right mirror matrix for the initial mirror.
Yup. Far easier!
I better get busy coding...
Thanks,
Carl
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Don Heyse wrote:
> > Under Steve's scheme the exception matrix for 3045.dat would be
> > created by multiplying a mirror matrix by a rotate 90 matrix. This
> > would create a part that looks identical, but is in fact mirrored. So
> > I don't think you need more than one exception matrix per part. Look
> > at this. The second part looks similar, but is actually mirrored.
> > That's the exception matrix for MIRROR.INI (except for the -32 Z
> > offset).
> >
> > 1 2 0 0 0 1 0 0 0 1 0 0 0 1 3045.dat
> > 1 1 0 -32 0 0 0 -1 0 1 0 -1 0 0 3045.dat
> >
> > Here's Steve's method using homogeneous 4x4 matrices (because they
> > make the math pretty):
> >
> > Default = MD = (-1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1)
> > Exception = ME = (a, d, g, 0, b, e, h, 0, c, f, i, 0, x, y, z, 1)
> >
> > For a typical (left right symmetric) part ME = MD
> >
> > Current = MC = (A, D, G, 0, B, E, H, 0, C, F, I, 0, X, Y, Z, 1)
> > Mirror across an arbitrary plane = MP = (...)
> > see http://www.geocities.com/SiliconValley/2151/matrices.html
> > (or use a simple mirror across the xy, yz, or xz plane).
> >
> > For each part, calculate MF (final matrix) where:
> > Mirrored (with no mirrored parts) = MF = MP * MC * ME
>
> Steve, Don--thanks for the explanations; this now makes complete sense
> to me (finally!).
>
> For a reflection about the plane containing the Z & Y axes
> (left-to-right), the reflection matrix (Mp) should be:
>
> -1 0 0
> 0 1 0
> 0 0 1
>
> Then Mp * (part-file rotation matrix from LDraw file) * Mp works for
> most parts.
>
> Substitute the second Mp for the exception matrix for the exception
> parts. The exception matrix needs to rotate to proper orientation
> and unmirror the part--for 2357 (brick 2 x 2 corner), the rotation
> matrix is:
>
> 0 0 -1
> 0 1 0
> 1 0 0
>
> 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.
> 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.
> Anybody see a problem with the algorithm to generate the
> rotation matrix setting
> A = -A and C = -C every time? One should always be 0, right?
> > Unless the text parsing code is already written. Then it's the same.
> > I put the MLCAD.INI (minifig configurator) file parsing in CVS on the
> > sourceforge, and the proposed MIRROR.INI file uses the same format.
> > However if you want to convert to and from XML, that's ok with me.
>
> OK, I haven't done anything else about the config file, but I'll
> stick with text if everyone thinks that's a better idea.
>
> > Sounds like it could work.
>
> Now I just have to program it! ;-)
> I better get busy coding...
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.
Enjoy,
Don
|
|
| |
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, Don Heyse wrote:
> 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.
Dibs on Wings and files starting with 1!
How hard would it be to support normal, self-referential reflections for
patterned parts? So we could map all 973*.dat parts to themselves, with a
default mirror.
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, Don Heyse wrote:
> If anyone wants to update MIRROR.INI for all 2500 parts, that'd be
> fantastic.
In mirror.ini, you noted:
; NOTE: I started using the Flags to keep track of which parts I checked.
; 0 = not checked.
; 1 = substitute part
; 2 = mirror across XY plane instead of default of ZY plane
; 3 = mirror and rotate a bit.
; 4 = mirror across XZ plane. (common for studless technic liftarms)
I'm adding another flag value:
; 5 = checked (ie, reflect across YZ plane)
Some of the flag values should be combinable. 2 and 4 are mutually exclusive,
but 2 and 3 can go together. So maybe this would be a more rational mapping:
; 0 = not checked.
; 1 = mirror across YZ plane (standard)
; 2 = mirror across XY plane
; 3 = mirror across XZ plane (common for studless technic liftarms)
; 4 = substitute part
; 8 = rotate a bit
Then the 4 and 8 values can be added to the mirror bits.
HTH,
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> I'm adding another flag value:
> ; 5 = checked (ie, reflect across YZ plane)
and another two:
; 6 = asymmetric
; 7 = asymmetric, but in a non-significant way
Part 108 (a shock absorber spring) is getting a 7.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > 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.
>
> Dibs on Wings and files starting with 1!
Read the comments at the top of MIRROR.INI in the zip file. I
already did a bunch of wings. Only tested one though...
Is there something special about files starting with 1, or
are you taking an alphabetical approach? Sadly, I created my
sample MIRROR.INI from a PARTS.LST sorted by description, not
part name. :^(
> How hard would it be to support normal, self-referential reflections
> for patterned parts? So we could map all 973*.dat parts to themselves,
> with a default mirror.
That was my plan, and it takes almost no work. We just have to mark
them as done somewhere and eventually remove them from MIRROR.INI when
all the parts have been checked. See the comments in MIRROR.INI to
see how I've been marking the flag field to tag parts I've worked on.
I suppose you could use a flag of 9 to indicate a part that fits the
default profile, so we know we've made a decision on it. We'll know
we're done when there are no 0 flags left.
Have you tested the mirwiz.exe program on any .LDR files yet? It's one
way to spot the exceptions not yet handled in MIRROR.INI. And it's
kinda fun.
Enjoy,
Don
|
|
| |
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, Don Heyse wrote:
> I suppose you could use a flag of 9 to indicate a part that fits the
> default profile, so we know we've made a decision on it. We'll know
> we're done when there are no 0 flags left.
Ignore the 9 suggestion, I see you're already way ahead of me on
flag definition.
Don
|
|
| |
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
|
|
| |
What about a flag for default behavior? I've been coding to ignore ones with default rotations, but there are plenty of parts (especially slopes) that need a (-1 0 0 0 1 0 0 0 1) rotation applied when reflected front-to-back and it would be nice to have a flag to distinguish those needing default behavior from those where the true correction matrix is (-1 0 0 0 1 0 0 0 1).
Carl
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> What about a flag for default behavior? I've been coding to ignore ones with default rotations, but there are plenty of parts (especially slopes) that need a (-1 0 0 0 1 0 0 0 1) rotation applied when reflected front-to-back and it would be nice to have a flag to distinguish those needing default behavior from those where the true correction matrix is (-1 0 0 0 1 0 0 0 1).
Never mind. 5 would be the correct value for this, right?
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> What about a flag for default behavior? I've been coding to ignore
> ones with default rotations,
Why? I have a slow PC, and running the mirwiz.exe program is
nearly instantaneous. It's a lookup and 2 matrix multiplies per
part. If the exception matrix lookup fails, use the default matrix.
It would take extra, unneeded code to ignore things. Resist the
urge...
> but there are plenty of parts (especially slopes) that need a
> (-1 0 0 0 1 0 0 0 1) rotation
Stop saying rotation. It makes me think you're not doing it right.
That's a mirror matrix.
> applied when reflected front-to-back
> and it would be nice to have a flag to distinguish those needing
> default behavior from those where the true correction matrix is
> (-1 0 0 0 1 0 0 0 1).
If you *always* do the same matrix math there's no need to
distinguish. If you're not, then you're making extra busy work
for yourself and possibly introducing bugs. Here's the pseudo code.
for (*ALL* parts in the subfile)
{
float m[4][4]; // Tempory working matrix.
float md[4][4] = { // Default = left-right mirror
{-1.0,0.0,0.0,0.0},
{0.0,1.0,0.0,0.0},
{0.0,0.0,1.0,0.0},
{0.0,0.0,0.0,1.0}
};
float *me = md; // Init exception mirror to left-right (the default).
float *mp = md; // Init global subfile mirror to left-right.
for( i=0; i< numExceptions; i++ )
{
if (exception[i] matches this part)
{
// Use the matrix from the exception list (instead of md).
me = exception[i].matrix
// Also use the substitute partname
strcpy(datname, exception[i].datname);
break;
}
}
M4M4Mul(m,LinePtr->v,me); // Run the initial mirror on the part
M4M4Mul(LinePtr->v,mp,m); // Apply global subfile mirror to part
// NOTE: You can set mp to mirror across whatever plane you want.
// The example here mirrors the subfile across the YZ plane.
}
It's simple and it's all done with mirrors, except for a few weird
parts which might contain a rotation and/or translation component
mixed in with the mirroring in the me matrix.
So far I've only found a few door parts that need a translation
component. See http://ldglite.sf.net/mirror.ini for details on
the doors.
Enjoy,
Don
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Carl Nelson wrote:
> > What about a flag for default behavior? I've been coding to ignore
> > ones with default rotations, but there are plenty of parts
> > (especially slopes) that need a (-1 0 0 0 1 0 0 0 1) rotation
> > applied when reflected front-to-back and it would be nice to have a
> > flag to distinguish those needing default behavior from those where
> > the true correction matrix is (-1 0 0 0 1 0 0 0 1).
>
> Never mind. 5 would be the correct value for this, right?
I don't think so. 5 is for keeping track of which parts we've looked
at, not which ones to ignore when your run your mirror program.
Eventually I think we'll remove all the ones marked with a 5 from the
MIRROR.INI file. (And that includes the left-right symmetric slopes
because they use the default matrix).
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Carl Nelson wrote:
> > What about a flag for default behavior? I've been coding to ignore
> > ones with default rotations,
>
> Why? I have a slow PC, and running the mirwiz.exe program is
> nearly instantaneous. It's a lookup and 2 matrix multiplies per
> part. If the exception matrix lookup fails, use the default matrix.
> It would take extra, unneeded code to ignore things. Resist the
> urge...
Why process something as an exception when the default behavior is needed? It's
all in what one sees as extra, unneeded code. ;-)
Though I just did some timing and I don't see any performance differences
between ignoring them and not.
> > but there are plenty of parts (especially slopes) that need a
> > (-1 0 0 0 1 0 0 0 1) rotation
>
> Stop saying rotation. It makes me think you're not doing it right.
> That's a mirror matrix.
Exception matrix would probably be the best term, since it *always* mirrors and
*may* rotate.
> If you *always* do the same matrix math there's no need to
> distinguish. If you're not, then you're making extra busy work
> for yourself and possibly introducing bugs. Here's the pseudo code.
>
> for (*ALL* parts in the subfile)
> {
> float m[4][4]; // Tempory working matrix.
> float md[4][4] = { // Default = left-right mirror
> {-1.0,0.0,0.0,0.0},
> {0.0,1.0,0.0,0.0},
> {0.0,0.0,1.0,0.0},
> {0.0,0.0,0.0,1.0}
> };
> float *me = md; // Init exception mirror to left-right (the default).
> float *mp = md; // Init global subfile mirror to left-right.
>
> for( i=0; i< numExceptions; i++ )
> {
> if (exception[i] matches this part)
> {
> // Use the matrix from the exception list (instead of md).
> me = exception[i].matrix
> // Also use the substitute partname
> strcpy(datname, exception[i].datname);
> break;
> }
> }
> M4M4Mul(m,LinePtr->v,me); // Run the initial mirror on the part
> M4M4Mul(LinePtr->v,mp,m); // Apply global subfile mirror to part
>
> // NOTE: You can set mp to mirror across whatever plane you want.
> // The example here mirrors the subfile across the YZ plane.
> }
>
> It's simple and it's all done with mirrors, except for a few weird
> parts which might contain a rotation and/or translation component
> mixed in with the mirroring in the me matrix.
My reservation about doing it this way is that it is exclusively tied to a reflection matrix of (-1 0 0 0 1 0 0 0 1)--please see my response to your 2nd message.
> So far I've only found a few door parts that need a translation
> component. See http://ldglite.sf.net/mirror.ini for details on
> the doors.
Same here. BTW, do you want me to send you the parts that I've changed
mirror.ini for already? I've also confirmed some as correct by rotating
different models.
Carl
|
|
| |
In lugnet.cad, Don Heyse wrote:
> I don't think so. 5 is for keeping track of which parts we've looked
> at, not which ones to ignore when your run your mirror program.
> Eventually I think we'll remove all the ones marked with a 5 from the
> MIRROR.INI file. (And that includes the left-right symmetric slopes
> because they use the default matrix).
IMO there *is* value to knowing that the proper exception matrix is indeed an
exception rather than coincidentally the same as the default matrix. If the 5
is not the place for this, there should be a new flag for it.
It's especially important if all the 5s are removed. If so, the left-right symmetric slopes with an exception matrix of -1 0 0 0 1 0 0 0 1 will only function properly for left-right reflections because that's the only case where their exception matrix would equal the "default" matrix. ("Default" in quotes because it should probably be the mirror-plane matrix or some other term that describes what it is.)
Of course, this supports your methodology of treating every part listed in
mirror.ini as an exception regardless of whether it happens to use the
reflection matrix. ;-) But it would still fail if those true exceptions were
removed.
Thanks,
Carl
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Don Heyse wrote:
> > I don't think so. 5 is for keeping track of which parts we've looked
> > at, not which ones to ignore when your run your mirror program.
> > Eventually I think we'll remove all the ones marked with a 5 from the
> > MIRROR.INI file. (And that includes the left-right symmetric slopes
> > because they use the default matrix).
> IMO there *is* value to knowing that the proper exception matrix is
> indeed an exception rather than coincidentally the same as the
> default matrix. If the 5 is not the place for this, there should be
> a new flag for it.
Sure, but you still haven't convinced me there's any difference
between a 2x2 brick and a 2x2 slope brick. I must be getting senile
in my old age, because I just don't get it.
Anyhow, use 55 if it makes you happy. We'll figure out what to do
with it later when my brain starts working. Steve's already switched
over to some other weird notation for the flag field. Maybe you
should send him a note and you two can duke it out. And perhaps you
can send my your code and it'll all become clear to me. I don't know.
> It's especially important if all the 5s are removed. If so, the
> left-right symmetric slopes with an exception matrix of -1 0 0 0 1 0
> 0 0 1 will only function properly for left-right reflections because
> that's the only case where their exception matrix would equal the
> "default" matrix. ("Default" in quotes because it should probably be
> the mirror-plane matrix or some other term that describes what it
> is.)
What do you mean by function properly? As far as I know, I can
change the global subfile mirror matrix (mp in my code sample) to a
mirror across *any* arbitrary plane and it should still work. I've
compiled mirwiz.c with a front-back mp and it still works.
float mm[4][4] = { // Front-back mirror
{1.0,0.0,0.0,0.0},
{0.0,1.0,0.0,0.0},
{0.0,0.0,-1.0,0.0},
{0.0,0.0,0.0,1.0}
};
//float *mp = md; // Init global mirror to left-right.
float *mp = mm; // Init global mirror to front-back.
What else do you need to function properly? The whole point of the
exception matrix is to prepare each part so that the *real* mirror
(the global subfile mirror operation) is in fact an UNmirror operation
because all the parts are already mirrored. You just can't tell
they're already mirrored unless you look at the backwards logos in
MLCAD or POV output.
Go ahead and try it. Just apply the exception matrices to a
subfile. It should come out looking identical. But if you look
really close at the logos in MLCAD you'll see they're backwards,
ready to be fixed by *any* mirror operation. (Don't use ldview
or ldglite though because they fix the logos on the fly if they
detect a negative determinant.)
Am I mistaken about this somehow? Does it somehow produce parts
that aren't mirrored, but also aren't real? Show me the mangled
LDR file.
> Of course, this supports your methodology of treating every part
> listed in mirror.ini as an exception regardless of whether it happens
> to use the reflection matrix. ;-) But it would still fail if those
> true exceptions were removed.
I'm still not seeing that. Steve? Help me out here. What am I
missing?
> BTW, do you want me to send you the parts that I've changed
> mirror.ini for already? I've also confirmed some as correct by
> rotating different models.
You're not a SourceForge member, are you? This merging would be so
much simpler if we could just let CVS merge the changes for us.
Since you're probably not, maybe you could send the changes to Steve.
(and send me a copy too) He's taking a rational approach. Doing
the ones and then the two's, whereas I just fool around and look
at wings or doors or whatever strikes my fancy.
Have fun,
Don
|
|
| |
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
|
|
| |
In lugnet.cad, Carl Nelson wrote:
> Why process something as an exception when the default behavior is needed?
> It's all in what one sees as extra, unneeded code. ;-)
Well, yeah. But it's simpler to process it all -- the only exceptional
processing you need is "look for the part in mirror.ini. If not found, use the
default settings".
With your method, you have to also add "if the matrix looks like MD, then
process with method_a; otherwise, use method_b".
HOWEVER, you should process all parts through the mirroring operation -
otherwise, you can't handle parts at arbitrary orientations. And if you apply
just the reflection matrix (MP), you'll get reversed stud-logos in your
renderings.
> Exception matrix would probably be the best term, since it *always* mirrors > and *may* rotate.
Or transformation matrix, or pre-reflection matrix.
Steve
|
|
| |
Oops, I missed replying to one point.
In lugnet.cad, Carl Nelson wrote:
> My reservation about doing it this way is that it is exclusively tied to a
> reflection matrix of (-1 0 0 0 1 0 0 0 1)--please see my response to your
> 2nd message.
If you mean (-1 0 0 0 1 0 0 0 1) as the 'default' matrix, my response is: that default matrix works for *any* reflection across any arbitrary plane.
If you mean (-1 0 0 0 1 0 0 0 1) as the reflection matrix, my response is: Don's algorithm works for *any* reflection across any arbitrary plane.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> Oops, I missed replying to one point.
>
> In lugnet.cad, Carl Nelson wrote:
> > My reservation about doing it this way is that it is exclusively tied to a
> > reflection matrix of (-1 0 0 0 1 0 0 0 1)--please see my response to your
> > 2nd message.
>
> If you mean (-1 0 0 0 1 0 0 0 1) as the 'default' matrix, my response is:
> that default matrix works for *any* reflection across any arbitrary plane.
>
> If you mean (-1 0 0 0 1 0 0 0 1) as the reflection matrix, my response is:
> Don's algorithm works for *any* reflection across any arbitrary plane.
Uh, I thought we were refering to it as "Steve's algorithm". Are you
having 2nd thoughts? ;^)
Enjoy,
Don
PS. Why am I constantly seeing really long lines in the browser for this
thread. It makes things really hard to read when I have to scroll 2
miles to the right.
|
|
| |
In lugnet.cad, Don Heyse wrote:
> Uh, I thought we were refering to it as "Steve's algorithm". Are you
> having 2nd thoughts? ;^)
Sorry, I should have said "Don's pseudo-code". ;)
> PS. Why am I constantly seeing really long lines in the browser for this
> thread. It makes things really hard to read when I have to scroll 2
> miles to the right.
I don't know - I'm replying via the web interface, posting with plain text.
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> Oops, I missed replying to one point.
>
> In lugnet.cad, Carl Nelson wrote:
> > My reservation about doing it this way is that it is exclusively tied to a
> > reflection matrix of (-1 0 0 0 1 0 0 0 1)--please see my response to your
> > 2nd message.
>
> If you mean (-1 0 0 0 1 0 0 0 1) as the 'default' matrix, my response is: that default matrix works for *any* reflection across any arbitrary plane.
>
> If you mean (-1 0 0 0 1 0 0 0 1) as the reflection matrix, my response is: Don's algorithm works for *any* reflection across any arbitrary plane.
Alright, I give up then. I've accomplished my original goal of mirroring a
model, and I'm just confusing and frustrating myself and wasting your and Don's
time with stupid questions.
I've put the newest executable & source code at:
http://www.carlnelson.com/page.asp?SID=1&Page=43
Thanks,
Carl
|
|
|
