 | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
> In lugnet.cad, Carl Nelson wrote:
> > In lugnet.cad, Dave Schuler wrote:
> > > For simple mirroring of the parts from left-to-right. This only works for parts
> > > oriented along the X, Y, and Z axes. If parts are rotated at odd angles (like
> > > 30 degrees, or whatever), then this won't quite work, but it should get you
> > > started.
>
> > Dave, I tried your method in Excel and it appears to work with some caveats,
> > though I don't really understand the column mappings:
> >
> > For left-to-right, you said to use columns D and G--that's corresponding to the
> > Y position and the B rotation parameter. Shouldn't that be the X position and C
> > parameter?
>
> You know, I think you're correct about that. I think I'm the last person who
> still uses LEdit as his primary LDraw platform, and for reasons of my own I
> always orient my parts and models rotated 90 degrees relative to the true LDraw
> standard orientation.
>
> Maybe I should give a specific example of the default orientation, with the 2x4
> brick at cursor position x=100, y=0, and z=-10. The letters correspond to the
> Excel columns:
>
> A B C D E F G H I J K L M N O P
>
> 1 16 100 0 -10 1 0 0 0 1 0 0 0 1 3001.DAT
>
> The mirrored left-to-right, the line would read this way:
>
> A B C D E F G H I J K L M N O P
>
> 1 16 100 0 -10 -1 0 0 0 1 0 0 0 -1 3001.DAT
Dumb, dumb, dumb. To be a true "mirror" as you've requested, the second example
should have read this way:
A B C D E F G H I J K L M N O P
1 16 -100 0 -10 -1 0 0 0 1 0 0 0 -1 3001.DAT
The way I originally posted it, the 3001 brick would be flipped left-to-right,
but it would be at the same location as the non-flipped brick.
Sorry about that.
Dave!
| | | | | | | | | | | | | | |
In lugnet.cad, Dave Schuler wrote:
> Dumb, dumb, dumb. To be a true "mirror" as you've requested, the second example
> should have read this way:
>
> A B C D E F G H I J K L M N O P
>
> 1 16 -100 0 -10 -1 0 0 0 1 0 0 0 -1 3001.DAT
>
> The way I originally posted it, the 3001 brick would be flipped left-to-right,
> but it would be at the same location as the non-flipped brick.
>
> Sorry about that.
Wouldn't that still be a 180 degree rotation rather than a flip, since
-1 0 0
(x y z) * 0 1 0 = (-x y -z)
0 0 -1
?
Or am I laying out my rotation matrix incorrectly (is the first line a b c or a
d g)?
Sorry for all the stupid questions, I'm still trying to dredge my linear algebra
out of the dark recesses of my memory.
Thanks,
Carl
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Carl Nelson wrote:
> Or am I laying out my rotation matrix incorrectly (is the first line a b c or a
> d g)?
I found the answer to this
(http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45), the
first column should be a d g. My poor layout doesnn't change the rotation
matrix (I think).
Carl
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Carl Nelson wrote:
> I found the answer to this
> (http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=45), the
> first column should be a d g. My poor layout doesnn't change the rotation
> matrix (I think).
Darn it, I meant the first ROW. (Doesn't show that I have a math degree, eh?
;-)
Carl
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Dave Schuler wrote:
> > Dumb, dumb, dumb. To be a true "mirror" as you've requested, the second example
> > should have read this way:
> >
> > A B C D E F G H I J K L M N O P
> >
> > 1 16 -100 0 -10 -1 0 0 0 1 0 0 0 -1 3001.DAT
> >
> > The way I originally posted it, the 3001 brick would be flipped left-to-right,
> > but it would be at the same location as the non-flipped brick.
> >
> > Sorry about that.
>
>
> Wouldn't that still be a 180 degree rotation rather than a flip, since
>
> -1 0 0
> (x y z) * 0 1 0 = (-x y -z)
> 0 0 -1
>
> ?
>
> Or am I laying out my rotation matrix incorrectly (is the first line a b c or a
> d g)?
>
> Sorry for all the stupid questions, I'm still trying to dredge my linear algebra
> out of the dark recesses of my memory.
When you ask a stupid question, I'll let you know! 8^)
You're right--it would rotate the brick 180 degrees, but I think that's
necessary sometimes (like for the 2x2 slope bricks mirrored left-to-right). But
you're also right that this isn't desireable in the case of bricks mirrored
front-to-back. That's where my clunky explanation really breaks down.
You'd probably want to avoid a "flip," because that would cause the stud-logos
to be reversed. I think basically you'll need to rotate some bricks 180 degrees
for the second tower, and you'll simply move other bricks (along the axes from
the first tower's location to the second, without rotating the brick along the
way).
Sadly, I can't help you with the formal matrix rotation or linear algebra--my
understanding of all of this comes from picking at LDraw parts until I get what
I'm looking for...
The more I look at this, the more I see what Dan was saying--this is a
cumbersome method!
Dave!
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dave Schuler wrote:
> You're right--it would rotate the brick 180 degrees, but I think that's
> necessary sometimes (like for the 2x2 slope bricks mirrored left-to-right). But
> you're also right that this isn't desireable in the case of bricks mirrored
> front-to-back. That's where my clunky explanation really breaks down.
>
> You'd probably want to avoid a "flip," because that would cause the stud-logos
> to be reversed. I think basically you'll need to rotate some bricks 180 degrees
> for the second tower, and you'll simply move other bricks (along the axes from
> the first tower's location to the second, without rotating the brick along the
> way).
Now that I've done that, I agree with you. The true proper thing to do is to
adjust the rotation matrix of all parts by
-a d -g
(x, y, z) * -b e -h = (-ax-by-cz, dx+ey+fz, -gx-hy-iz)
-c f -i
and create a list of exceptions that would be a rotation matrix plus a
translation, for example a 2 x 2 corner reflected on a horizontal axis should be
rotated by:
0 0 -1
0 1 0
-1 0 0
giving (x' = -z, y' = y, z' = -x)
and then translated in X and Z axes to put it in the right place.
Basically that would mean that any part having a rotation point not at its
geometric center would need a custom rotation and translation.
> Sadly, I can't help you with the formal matrix rotation or linear algebra--my
> understanding of all of this comes from picking at LDraw parts until I get what
> I'm looking for...
Don't worry--I actually have a math degree and did most of my work in linear
algebra & analytical geometry and, um, it took far longer to understand this
than I care to admit...
> The more I look at this, the more I see what Dan was saying--this is a
> cumbersome method!
Ah, it's not too bad, especially when I did my program to automate it. It has
shortcomings, but it works for the majority and the rest is merely exception
processing.
Carl
| | | | | | | | | | | | | | | | | |
| |
|
n lugnet.cad, Carl Nelson wrote:
> The true proper thing to do is to adjust the rotation matrix of all
> parts by
>
> -a d -g
> (x, y, z) * -b e -h = (-ax-by-cz, dx+ey+fz, -gx-hy-iz)
> -c f -i
>
> and create a list of exceptions that would be a rotation matrix plus
> a translation, for example a 2 x 2 corner reflected on a horizontal
> axis should be rotated by:
>
> 0 0 -1
> 0 1 0
> -1 0 0
>
> giving (x' = -z, y' = y, z' = -x)
>
> and then translated in X and Z axes to put it in the right place.
>
> Basically that would mean that any part having a rotation point not
> at its geometric center would need a custom rotation and
> translation.
>
> > Sadly, I can't help you with the formal matrix rotation or linear
> > algebra--my understanding of all of this comes from picking at
> > LDraw parts until I get what I'm looking for...
>
> Don't worry--I actually have a math degree and did most of my work
> in linear algebra & analytical geometry and, um, it took far longer
> to understand this than I care to admit...
>
> > The more I look at this, the more I see what Dan was saying--this
> > is a cumbersome method!
>
> Ah, it's not too bad, especially when I did my program to automate
> it. It has shortcomings, but it works for the majority and the rest
> is merely exception processing.
Take a peek at the MLCAD.INI file for minifig posing. Could you
use a config file like this to handle the exceptions? I'd imagine
if you pick one axis for mirroring that works best with most parts,
(I think Travis said most were symmetric across the Z axis?) then
you could give a rotation matrix for the exceptions to make them
line up correctly. Then to get a mirror over another axis you
mirror over the standard axis and and apply a rotation to the
results.
It'd be really nice to create a MIRROR.INI file, put it in the ldraw
directory and keep it updated with the parts. Then if you could put
some wrappers around your program to allow it to be used as an MLCAD
generator and an LDDP plugin, that'd be fantastic.
Have you considered making the source code available?
Enjoy,
Don
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> > Ah, it's not too bad, especially when I did my program to automate
> > it. It has shortcomings, but it works for the majority and the rest
> > is merely exception processing.
>
> Take a peek at the MLCAD.INI file for minifig posing. Could you
> use a config file like this to handle the exceptions? I'd imagine
> if you pick one axis for mirroring that works best with most parts,
> (I think Travis said most were symmetric across the Z axis?) then
> you could give a rotation matrix for the exceptions to make them
> line up correctly. Then to get a mirror over another axis you
> mirror over the standard axis and and apply a rotation to the
> results.
Oh yeah, the other exception would be a part substitution, like
left minifig arm for right arm, or left wing plates for right wing
plates.
But watch out, some folks might object to substituting left-wing
for right-wing of anything. ;^)
> It'd be really nice to create a MIRROR.INI file, put it in the ldraw
> directory and keep it updated with the parts. Then if you could put
> some wrappers around your program to allow it to be used as an MLCAD
> generator and an LDDP plugin, that'd be fantastic.
>
> Have you considered making the source code available?
>
> Enjoy,
>
> Don
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Don Heyse wrote:
Talking to myself...
Here's what I'm talking about. Completely ripped off from the
MLcad.ini file.
http://ldglite.sf.net/mirror.ini
That one contains an entry every part in my parts.lst file. It
needs to have the changes made for the exceptions, but here's
how it starts.
;
; Mirror.ini
;
; ============================================================================
; This file is read by subfile mirror programs
; ============================================================================
; Lines beginning with ; are comments ...
; Empty lines are ignored
; This file contains information used to mirror a subfile across the Z axis.
; Many parts are symmetric across the Z axis and can be mirrored by simply
; negating the Z coordinate of the part in the subfile.
; Other parts need additional rotation, translation, and possibly substitution.
; This file tells what to do for those exceptional parts.
;
; Each line has the following format:
; PARTNAME MIRRORPART <Flags> <Matrix> <Offset>
; <PARTNAME> The name of the part file
; <MIRRORPART> The file name of the substutute part.
; (It's the same as PARTNAME if no substitution is required.
; <Flags> always 0 reserved for future use
; <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
;
[MIRRORSETTINGS]
2546.DAT 2546.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
2546P01.DAT 2546P01.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
6029A.DAT 6029A.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> Here's what I'm talking about. Completely ripped off from the
> MLcad.ini file.
>
> http://ldglite.sf.net/mirror.ini
>
> That one contains an entry every part in my parts.lst file. It
> needs to have the changes made for the exceptions, but here's
> how it starts. • [...]
> 2546.DAT 2546.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
> 2546P01.DAT 2546P01.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
> 6029A.DAT 6029A.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
I think I've got a more general solution, but first a quick thought: You could
make mirror.ini more human-readable if the 'normal' parts were just flagged.
Something like:
2546.DAT default
41770.DAT exception 41769.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
On to the weird stuff, apologies if the following covers ground already
discussed.
It seems like mirror.ini will work for the basic case, where parts are not
rotated (or only rotated by 90 degree increments around the Y-axis). But what
about exception parts at arbitrary orientations? I'm not very good at thinking
in terms of matrix math, so I worked through a concrete example.
I used the 2x4 wings, 41770 and 41769. I mirrored along the X axis (my
mistake), but I'll get back to Z axis mirroring in a bit. The 41770's
X-axis-style entry in MIRROR.INI would be like:
41770.DAT 41769.DAT 0 -1 0 0 0 1 0 0 0 1 0 0 0
So I put a 41770 in a model file and postioned it like this:
1 4 130 -70 -130 .39 -.64 -.66 .6 .72 -.34 .7 -.27 .66 41770.dat
Then I tried to mirror it cleanly. That is, I wanted to end up with 41769 in
the position/orientation corresponding to my 41770, which means that its final
transformation matrix would be 'non-mirroring'. What I ended up with is this
LDLite language:
0 TRANSFORM 0 0 0 -1 0 0 0 1 0 0 0 1
0 TRANSFORM 130 -70 -130 .39 -.64 -.66 .6 .72 -.34 .7 -.27 .66
1 3 0 0 0 -1 0 0 0 1 0 0 0 1 41769.dat
0 TRANSFORM END
0 TRANSFORM END
Translated back to simple LDraw, this code turns into:
1 3 -130 -70 -130 .39 .64 .66 -.6 .72 -.34 -.7 -.27 .66 41769.dat
Getting back to mirroring along the Z axis: I figured out that the correct
equivalent Z axis mirror operation looks like this:
0 TRANSFORM 0 0 0 1 0 0 0 1 0 0 0 -1
0 TRANSFORM 130 -70 -130 .39 -.64 -.66 .6 .72 -.34 .7 -.27 .66
1 3 0 0 0 -1 0 0 0 1 0 0 0 1 41769.dat
0 TRANSFORM END
0 TRANSFORM END
What's interesting is the pre-mirrored part (41769) is inlined with the same transformation as before (-1 0 0 0 1 0 0 0 1). I expected that I'd have to rotate 41769 180 degrees, and then reposition it, to make things work.
After thinking about it, I think what happened is this: instead of trying to map 41770 to 41769 in some way that is equivalent to a mirroring operation, I actually replaced the original part with an already-mirrored equivalent statement. That is, I replaced the '41770.dat' in the first statement with '1 16 0 0 0 -1 0 0 0 1 0 0 0 1 41769.dat', like an inlined subfile. Since this part was pre-mirrored, applying the mirroring transformation actually 'un-mirrored' the 41769.
So, to make a long story short - I don't think MIRROR.INI should specify how to
transform part A into part B without a mirror operation. It should specify the
opposite: how to mirror part B into part A with a mirroring operation, so
mirroring-programs can take the transformation being used on part A in the model
file and wrap it around the mirrored part B.
The main practical effect on MIRROR.INI would be that normal parts would have a mirroring transform (1 0 0 0 1 0 0 0 -1) instead of the standard transform.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > Here's what I'm talking about. Completely ripped off from the
> > MLcad.ini file.
> >
> > http://ldglite.sf.net/mirror.ini
> >
> > That one contains an entry every part in my parts.lst file. It
> > needs to have the changes made for the exceptions, but here's
> > how it starts. [...]
> > 2546.DAT 2546.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
> > 2546P01.DAT 2546P01.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
> > 6029A.DAT 6029A.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
>
> I think I've got a more general solution, but first a quick thought:
> You could make mirror.ini more human-readable if the 'normal' parts
> were just flagged. Something like:
>
> 2546.DAT default
> 41770.DAT exception 41769.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
Actually I was thinking of deleting them from the file to make it
smaller. The only problem is remembering which ones were deleted and
which ones are new at update time. I'm not sure how to automate
additions either way. Probably have to use the sorted properties of
parts.lst
> So, to make a long story short - I don't think MIRROR.INI should
> specify how to transform part A into part B without a mirror operation.
> It should specify the opposite: how to mirror part B into part A with
> a mirroring operation, so mirroring-programs can take the
> transformation being used on part A in the model file and wrap it
> around the mirrored part B.
>
> The main practical effect on MIRROR.INI would be that normal parts
> would have a mirroring transform (1 0 0 0 1 0 0 0 -1) instead of the
> standard transform.
I think that makes sense. Apply the mirror transform and/or substitution
from MIRROR.INI individually to all parts in the subfile, then apply a
global mirror (across whatever axis you want) to the whole subfile.
It sounds so simple. Could it be?
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Steve Bliss wrote:
> > You could make mirror.ini more human-readable if the 'normal' parts
> > were just flagged. Something like:
> >
> > 2546.DAT default
> > 41770.DAT exception 41769.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
>
> Actually I was thinking of deleting them from the file to make it
> smaller. The only problem is remembering which ones were deleted and
> which ones are new at update time. I'm not sure how to automate
> additions either way. Probably have to use the sorted properties of
> parts.lst
Keep a full.mirror.ini, with all the default entries. A simple grep drop the
extra lines, giving us mirror.ini.
> I think that makes sense. Apply the mirror transform and/or substitution
> from MIRROR.INI individually to all parts in the subfile, then apply a
> global mirror (across whatever axis you want) to the whole subfile.
>
> It sounds so simple. Could it be?
Well, it depends entirely on whether or not applying two mirroring
transformations always gives an un-mirrored result. If that's true, then we're
good.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > In lugnet.cad, Steve Bliss wrote:
> > > You could make mirror.ini more human-readable if the 'normal' parts
> > > were just flagged. Something like:
> > >
> > > 2546.DAT default
> > > 41770.DAT exception 41769.DAT 0 1 0 0 0 1 0 0 0 1 0 0 0
> >
> > Actually I was thinking of deleting them from the file to make it
> > smaller. The only problem is remembering which ones were deleted and
> > which ones are new at update time. I'm not sure how to automate
> > additions either way. Probably have to use the sorted properties of
> > parts.lst
>
> Keep a full.mirror.ini, with all the default entries. A simple grep
> drop the extra lines, giving us mirror.ini.
Or generate a parts.lst (and stash it somewhere) before adding parts,
then diff it with the new parts.lst. I'm not sure how grep fits into
your plan though...
> > I think that makes sense. Apply the mirror transform and/or substitution
> > from MIRROR.INI individually to all parts in the subfile, then apply a
> > global mirror (across whatever axis you want) to the whole subfile.
> >
> > It sounds so simple. Could it be?
>
> Well, it depends entirely on whether or not applying two mirroring
> transformations always gives an un-mirrored result. If that's true,
> then we're good.
My math intuition says it should be. There are only two choices for
the sign of the determinant, and I think multiplying a negative matrix
by a negative matrix must result in a positive. Two wrongs *do* make
a right. Right?
Don
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Steve Bliss wrote:
> The main practical effect on MIRROR.INI would be that normal parts
> would have a mirroring transform (1 0 0 0 1 0 0 0 -1) instead of the
> standard transform.
Err, Shouldn't that be (-1 0 0 0 1 0 0 0 1)? You have to negate the
X coordinate to mirror across the Z axis.
Don
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Steve Bliss wrote:
> > The main practical effect on MIRROR.INI would be that normal parts
> > would have a mirroring transform (1 0 0 0 1 0 0 0 -1) instead of the
> > standard transform.
>
> Err, Shouldn't that be (-1 0 0 0 1 0 0 0 1)? You have to negate the
> X coordinate to mirror across the Z axis.
Sorry, I misunderstood the terminology. I figured you could either mirror
across a plane, or along a line. You can't mirror across a line - it's 1D. So
I assumed when people were writing about mirroring 'across the Z axis', they
meant to use the XY plane as the mirror.
So, yeah - for right/left mirroring, you'd negate the X coordinate.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > In lugnet.cad, Steve Bliss wrote:
> > > The main practical effect on MIRROR.INI would be that normal parts
> > > would have a mirroring transform (1 0 0 0 1 0 0 0 -1) instead of the
> > > standard transform.
> >
> > Err, Shouldn't that be (-1 0 0 0 1 0 0 0 1)? You have to negate the
> > X coordinate to mirror across the Z axis.
>
> Sorry, I misunderstood the terminology. I figured you could either mirror
> across a plane, or along a line. You can't mirror across a line - it's 1D.
> So I assumed when people were writing about mirroring 'across the Z axis',
> they meant to use the XY plane as the mirror.
Heh, I was thinking 2-dimensionally. It's easier for my tired old
brain. All my sketches were happening on the XZ plane so mirroring
across the Z axis made total sense to me. Oh well.
> So, yeah - for right/left mirroring, you'd negate the X coordinate.
Ok, now I have to follow through and actually make a reference program
which uses the MIRROR.INI file, or this will all be for nothing.
Don
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> It'd be really nice to create a MIRROR.INI file, put it in the ldraw
> directory and keep it updated with the parts. Then if you could put
> some wrappers around your program to allow it to be used as an MLCAD
> generator and an LDDP plugin, that'd be fantastic.
Is there any documentation about what functionality needs to be exposed to make
an MLCAD plugin?
I've been playing with this in a class-based architecture, that has an
LMirrorExceptionList that contains an array of LMirrorExceptionPart. I've been
using XmlSerializer to write this to an XML file that looks like:
<?xml version="1.0" encoding="utf-8" ?>
<LMirrorPartList xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
SerialNumber="2004062104">
<ExceptionPartList>
<Part>
<PartFile>3045.dat</PartFile>
<SubstitutePartNumber>3045.dat</SubstitutePartNumber>
<Translation>
<X>0</X>
<Y>0</Y>
<Z>0</Z>
</Translation>
<XReflectionMatrix>
<A>1</A>
<B>0</B>
<C>0</C>
<D>0</D>
<E>1</E>
<F>0</F>
<G>0</G>
<H>0</H>
<I>1</I>
</XReflectionMatrix>
<ZReflectionMatrix>
<A>0</A>
<B>0</B>
<C>-1</C>
<D>0</D>
<E>1</E>
<F>0</F>
<G>1</G>
<H>0</H>
<I>0</I>
</ZReflectionMatrix>
<ReverseTransformFor90Rotations>false</ReverseTransformFor90Rotations>
</Part>
<Part>
<PartFile>2357.dat</PartFile>
<SubstitutePartNumber>2357.dat</SubstitutePartNumber>
<Translation>
<X>0</X>
<Y>0</Y>
<Z>0</Z>
</Translation>
<XReflectionMatrix>
<A>0</A>
<B>0</B>
<C>1</C>
<D>0</D>
<E>1</E>
<F>0</F>
<G>-1</G>
<H>0</H>
<I>0</I>
</XReflectionMatrix>
<ZReflectionMatrix>
<A>0</A>
<B>0</B>
<C>-1</C>
<D>0</D>
<E>1</E>
<F>0</F>
<G>1</G>
<H>0</H>
<I>0</I>
</ZReflectionMatrix>
<ReverseTransformFor90Rotations>true</ReverseTransformFor90Rotations>
</Part>
</ExceptionPartList>
</LMirrorPartList>.
It's easy enough to add a SaveText() method that would do it as a single-line
text format like your mirror.ini file too, but it's easier to deal with XML than
text parsing!
Ideally, the LMirror program could include an exception list editor. I can
expose a web service to receive updates to the mirror list and retrieve the most
current list to client apps--that'd be my preferred way to deal with that
problem.
Now that I've played with the problem some more in code, I'm thinking the
approach of defining a rotation + translation to accurately depict the part may
be addressing the symptom, rather than the problem. Really, the trick is under
what conditions we ignore a part rather than applying a rotation. Universally
applying a rotation works for the majority of parts for a simple reason: most
parts exhibit symmetry of the X and Z axes about their center of rotation.
If we take, for example, 3747 (slope 33 3 x 2 inverted) being mirrored about the
Z axis (left-to-right mirroring), the 180-degree rotation is desirable for a
part oriented 3 studs across by 2 high but not for one oriented 2 studs across
by 3 high. (That's what the
<ReverseTransformFor90Rotations>true</ReverseTransformFor90Rotations> element
above was intended to deal with, by applying a 180-degree rotation after the
initial 180-degree rotation for parts oriented under certain conditions--but I
have not thoroughly identified those conditions nor arrived at an optimal
solution yet.)
Please pardon any errors above, and feel free to correct my misunderstandings!
I've only really looked at the LDraw format since last week and am completely
given to errors.
> Have you considered making the source code available?
Absolutely. I'm a little loathe to do so anonymously until I'm at some more
stable code, but if you want it now send me an e-mail and I'll post it when it's
a little more polished. I've also started a .NET class library to deal with
LDraw data that anyone is welcome to receive.
This brings up a larger question. LDraw.org is a great resource for anyone
wanting to get started as a user or those dealing with the parts library, but
doesn't contain much information for developers other than the file
specification. It would be especially instructive to me to see how others have
coped with these rotation/graphics matrix issues, and I can benefit from either
public inspection of my own source or being able to see others' source. What
resources exist for LDraw developers? None of the committees really seem
appropriate--the LSC is concerned with the file specification, the Tech List
with the website operations, the Content List with the website contents, and the
parts reviewers for parts issues.
Thanks for humoring my random queries!
Carl
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Carl Nelson wrote:
> In lugnet.cad, Don Heyse wrote:
> > It'd be really nice to create a MIRROR.INI file, put it in the ldraw
> > directory and keep it updated with the parts. Then if you could put
> > some wrappers around your program to allow it to be used as an MLCAD
> > generator and an LDDP plugin, that'd be fantastic.
> Is there any documentation about what functionality needs to be
> exposed to make an MLCAD plugin?
Hmm, I don't know. I'm pretty sure there's documentation on language
DLL creation, but I'm not so sure about the generators. Ask this on the
.mlcad group.
> I've been playing with this in a class-based architecture, that has an
> LMirrorExceptionList that contains an array of LMirrorExceptionPart.
> I've been using XmlSerializer to write this to an XML file
XML works, but it's harder for humans (ie. me) to read.
> <PartFile>3045.dat</PartFile>
> <SubstitutePartNumber>3045.dat</SubstitutePartNumber>
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
> It's easy enough to add a SaveText() method that would do it as a
> single-line text format like your mirror.ini file too, but it's
> easier to deal with XML than text parsing!
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.
> Ideally, the LMirror program could include an exception list editor.
> I can expose a web service to receive updates to the mirror list and
> retrieve the most current list to client apps--that'd be my
> preferred way to deal with that problem.
Sounds like it could work.
> Now that I've played with the problem some more in code, I'm
> thinking the approach of defining a rotation + translation to
> accurately depict the part may be addressing the symptom, rather
> than the problem. Really, the trick is under what conditions we
> ignore a part rather than applying a rotation. Universally applying
> a rotation works for the majority of parts for a simple reason: most
> parts exhibit symmetry of the X and Z axes about their center of
> rotation.
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.
> If we take, for example, 3747 (slope 33 3 x 2 inverted)
Under Steve's algorithm, this part is ordinary because of the symmetry
and doesn't need any special considerations, so we could leave it
out of MIRROR.INI.
> Please pardon any errors above, and feel free to correct my
> misunderstandings! I've only really looked at the LDraw format
> since last week and am completely given to errors.
> > Have you considered making the source code available?
> Absolutely. I'm a little loathe to do so anonymously until I'm at
> some more stable code, but if you want it now send me an e-mail and
> I'll post it when it's a little more polished. I've also started a
> .NET class library to deal with LDraw data that anyone is welcome to
> receive.
> This brings up a larger question. LDraw.org is a great resource for
> anyone wanting to get started as a user or those dealing with the
> parts library, but doesn't contain much information for developers
> other than the file specification. It would be especially
> instructive to me to see how others have coped with these
> rotation/graphics matrix issues, and I can benefit from either
> public inspection of my own source or being able to see others'
> source. What resources exist for LDraw developers?
This is the resource. lugnet.cad.dev. If you want code, it's
available for many of the programs. Which ones were you looking for?
Ldglite code is available here.
http://cvs.sourceforge.net/viewcvs.py/ldglite/ldglite/
I think the L3P parser and matrix functions are fairly easy to follow.
Better than anything I've written, anyways.
You can also look at the old ldraw FAQ.
http://www.ldraw.org/OLD/community/memorial/archive/FAQ/
It seems to have some info that I can't always find in the newer
divided FAQs and specs.
Enjoy, Don
| | | | | | | | | | | | | | | | | | |
| |
|
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, 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
| | | | | | | | | | | | | | | | | | | | | | | | | |
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, 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, 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, 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
| | | | | | | | | | | | | | | | | | | | | | |
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:
> 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:
> 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
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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, 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, 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
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Carl Nelson wrote:
> I've put the newest executable & source code at:
>
> http://www.carlnelson.com/page.asp?SID=1&Page=43
Before I forget, Steve finished examining all the parts, so
I've put the complete mirror.ini file here for now.
http://ldglite.sourceforge.net/mirwiz.zip
Enjoy,
Don
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Carl Nelson wrote:
> > In lugnet.cad, Don Heyse wrote:
> > > It'd be really nice to create a MIRROR.INI file, put it in the ldraw
> > > directory and keep it updated with the parts. Then if you could put
> > > some wrappers around your program to allow it to be used as an MLCAD
> > > generator and an LDDP plugin, that'd be fantastic.
>
> > Is there any documentation about what functionality needs to be
> > exposed to make an MLCAD plugin?
>
> Hmm, I don't know. I'm pretty sure there's documentation on language
> DLL creation, but I'm not so sure about the generators. Ask this on the
> .mlcad group.
I forwarded this question to here because I don't know the answer.
Apparently there has been some discussion in the past about developing
plugins for MLCAD:
http://news.lugnet.com/cad/mlcad/?n=177
Is there a specification for plugin development?
Thanks,
Don
| | | | | | | | | | | | | | | | |
Done,
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hzrprv.14sB@lugnet.com...
<SNIP>
>
> Is there a specification for plugin development?
No sorry, MLCad does not support plugins yet, currently I have a very quick
way introducing new generators and pseudo commands by hand - but I'll check
if I could do some more automation here to be able to load such things as
plugins.
> Thanks,
>
> Don
Regards,
Michael
| | | | | | | | | | | | | | | | |
In lugnet.cad, Michael Lachmann wrote:
> > Is there a specification for plugin development?
>
> No sorry, MLCad does not support plugins yet, currently I have a very quick
> way introducing new generators and pseudo commands by hand - but I'll check
> if I could do some more automation here to be able to load such things as
> plugins.
While you're checking, think about this. What if the MLCad generators
were reconfigured as some sort of plugins, and the plugin specs were
documented? Then everyone could use your generators. You know, weird
people like me who are frightened off by too many toolbars, or those
crazy people who insist on editing their LDRAW code in a text editor
like LDDP. ;^)
Enjoy,
Don
| | | | | | | | | | | | | | | | |
Don,
"Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
news:Hztzr8.y0t@lugnet.com...
<SNIP>
> While you're checking, think about this. What if the MLCad generators
> were reconfigured as some sort of plugins, and the plugin specs were
> documented? Then everyone could use your generators. You know, weird
> people like me who are frightened off by too many toolbars, or those
> crazy people who insist on editing their LDRAW code in a text editor
> like LDDP. ;^)
>
> Enjoy,
>
> Don
That will be documented anyway - sure. But for that feature I have to think
even more ...
but I have already an idea how that could work.
I just need to find a spare hour where I can hack a quick prototype, to see
the cons and pros of this
idea.
Best regards,
Michael
| | | | | | |
