 | | | | | |
Hi,
I would like to announce that I've just released a new version of MLCad!
MLCad V3.30
What's new:
- Development environment was changed to Visual Studio 2005
- Support for color definitions in LdConfig.ldr
- Empty lines are no longer removed (for part authoring)
- New default groups (Minifig, Slope and Tile)
- Several bug fixes
More detailed informations can be found in the release notes of the package.
Best regards,
Michael
| | | | | | | | | | | | | | | |
You made my day!
Thanks, Michael!!!
Philo
| | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hi,
>
> I would like to announce that I've just released a new version of MLCad!
>
> MLCad V3.30
Thank you for this long awaited release!
Now let's spread the word!
Jetro
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Jetro de Chateau wrote:
> In lugnet.cad.mlcad, Michael Lachmann wrote:
> > Hi,
> >
> > I would like to announce that I've just released a new version of MLCad!
> >
> > MLCad V3.30
>
> Thank you for this long awaited release!
>
> Now let's spread the word!
>
> Jetro
BTW, this really deserves being posted on lugnet.announce as well!!
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hi,
>
> I would like to announce that I've just released a new version of MLCad!
>
> MLCad V3.30
>
> What's new:
> - Development environment was changed to Visual Studio 2005
> - Support for color definitions in LdConfig.ldr
> - Empty lines are no longer removed (for part authoring)
> - New default groups (Minifig, Slope and Tile)
> - Several bug fixes
>
> More detailed informations can be found in the release notes of the package.
>
> Best regards,
> Michael
You just ground my yawn to a halt.
LDConfig support is something I've been wanting for a *very* long time. Now I
can define my own background colour by using the unused colour 31. :P
Love it.
-Santeri
| | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hi,
>
> I would like to announce that I've just released a new version of MLCad!
>
> MLCad V3.30
>
> What's new:
> - Development environment was changed to Visual Studio 2005
> - Support for color definitions in LdConfig.ldr
> - Empty lines are no longer removed (for part authoring)
> - New default groups (Minifig, Slope and Tile)
> - Several bug fixes
>
> More detailed informations can be found in the release notes of the package.
>
> Best regards,
> Michael
Thank you very much for updating MLCad to support LDConfig.ldr.
I hope that this will not be the last update to this wonderful application.
Now I have to see how it works.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Heidemann wrote:
> In lugnet.cad.mlcad, Michael Lachmann wrote:
> > Hi,
> >
> > I would like to announce that I've just released a new version of MLCad!
> >
> > MLCad V3.30
> >
> > What's new:
> > - Development environment was changed to Visual Studio 2005
> > - Support for color definitions in LdConfig.ldr
> > - Empty lines are no longer removed (for part authoring)
> > - New default groups (Minifig, Slope and Tile)
> > - Several bug fixes
> >
> > More detailed informations can be found in the release notes of the package.
> >
> > Best regards,
> > Michael
>
> Thank you very much for updating MLCad to support LDConfig.ldr.
>
> I hope that this will not be the last update to this wonderful application.
>
> Now I have to see how it works.
>
> cu
> mikeheide
Now that I have installed MLCad and read all informations I hope we can get an
update soon. I have two reason:
1) Implementation of language support is different to what we have implemented.
2) I miss the "dithered" colours. Not the dithered itself, but the range of
colours I could choose from to make pattern parts.
Additionally (maybe a bug)
If I go to MLCad setting, tab Rendering and choose "Background color" in that
color dialog I can not browse through the colors.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Heidemann wrote:
> In lugnet.cad.mlcad, Michael Heidemann wrote:
> > In lugnet.cad.mlcad, Michael Lachmann wrote:
> > > Hi,
> > >
> > > I would like to announce that I've just released a new version of MLCad!
> > >
> > > MLCad V3.30
> > >
> > > What's new:
> > > - Development environment was changed to Visual Studio 2005
> > > - Support for color definitions in LdConfig.ldr
> > > - Empty lines are no longer removed (for part authoring)
> > > - New default groups (Minifig, Slope and Tile)
> > > - Several bug fixes
> > >
> > > More detailed informations can be found in the release notes of the package.
> > >
> > > Best regards,
> > > Michael
> >
> > Thank you very much for updating MLCad to support LDConfig.ldr.
> >
> > I hope that this will not be the last update to this wonderful application.
> >
> > Now I have to see how it works.
> >
> > cu
> > mikeheide
>
> Now that I have installed MLCad and read all informations I hope we can get an
> update soon. I have two reason:
> 1) Implementation of language support is different to what we have implemented.
> 2) I miss the "dithered" colours. Not the dithered itself, but the range of
> colours I could choose from to make pattern parts.
>
> Additionally (maybe a bug)
> If I go to MLCad setting, tab Rendering and choose "Background color" in that
> color dialog I can not browse through the colors.
That's something that has been around in the last version too.
>
> cu
> mikeheide
I have another bug... in some cases I cannot manipulate the rotation matrix
because the angle value in the vector field (which I never saw much use of
anyhow) is something like -9.223372 * 10^n and MLCad does not understand it. So
whenever I try to open up the rotation matrix field I get a dialog saying that
the angle should be between -180 and 180 and the field remains disabled. What's
worse, the same is for the vector fields and thus I cannot reset the angle! All
I can do is reset the matrix manually in LDDP. *Highly* annoying.
-Santeri
| | | | | | | | | | | | | | | | | | | | | | | | | | |
Hello Santeri,
> I have another bug... in some cases I cannot manipulate the rotation
> matrix
> because the angle value in the vector field (which I never saw much use of
> anyhow) is something like -9.223372 * 10^n and MLCad does not understand
> it. So
> whenever I try to open up the rotation matrix field I get a dialog saying
> that
> the angle should be between -180 and 180 and the field remains disabled.
> What's
> worse, the same is for the vector fields and thus I cannot reset the
> angle! All
> I can do is reset the matrix manually in LDDP. *Highly* annoying.
Could you please save your file in such a case and send it to me for
reproduction and testing?
That would be of great help!
Thanks for reporting!
Best regards,
Michael
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Hi Michael,
> Could you please save your file in such a case and send it to me for
> reproduction and testing?
> That would be of great help!
I just stumbled on the same problem. This single line is enough to show the
problem (Impossible to change the transformation matrix):
1 1 0 0 -25 38 0 0 0 0 -38 0 1 0 48\4-4edge.dat
Philo
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hello Santeri,
>
> Could you please save your file in such a case and send it to me for
> reproduction and testing?
> That would be of great help!
>
> Thanks for reporting!
>
> Best regards,
> Michael
Philo beat me to it but here's mine anyway:
1 4 0 0 -5 2 0 0 0 1 0 0 0 2 4-4disc.dat
1 2 0 0 -10 4 0 0 0 0 -4 0 1 0 4-4disc.dat
1 14 0 0 -15 5 0 0 0 0 5 0 -1 0 4-4disc.dat
-Santeri
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Hello Michael
> In lugnet.cad.mlcad, Michael Heidemann wrote:
> Now that I have installed MLCad and read all informations I hope we can
> get an
> update soon. I have two reason:
> 1) Implementation of language support is different to what we have
> implemented.
I'm currently looking into that.
> 2) I miss the "dithered" colours. Not the dithered itself, but the range
> of
> colours I could choose from to make pattern parts.
? I cannot understand.
There is no such range, MLCad takes that what comes from LDConfig nothing
more, nothing less.
Dithered colors originally have been according to the original definition of
LDraw. MLCad now no longer uses them, but only the
definition from LDConfig.
If you feel that colors are missing, than we should add them to this file
...
>
> Additionally (maybe a bug)
> If I go to MLCad setting, tab Rendering and choose "Background color" in
> that
> color dialog I can not browse through the colors.
Thanks for mentioning, I've already corrected that - it will be available
with the next release.
Best regards,
Michael
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Lachmann wrote:
> In lugnet.cad.mlcad, Michael Heidemann wrote:
> > I miss the "dithered" colours. Not the dithered itself, but the
> > range of colours I could choose from to make pattern parts.
> ? I cannot understand. There is no such range, MLCad takes that
> what comes from LDConfig nothing more, nothing less. Dithered
> colors originally have been according to the original definition of
> LDraw. MLCad now no longer uses them, but only the definition from
> LDConfig. If you feel that colors are missing, than we should add
> them to this file ...
I noticed that when I remove LDConfig.ldr the old dithered colors are
available, but no longer dithered. They're now solid colors. That's
a big improvement! It makes the 256-511 rance of colors much nicer
for printed patterns. (Dithered colors need a few consecutive pixels
to look good, and the small triangles in the printed patterns aren't
big enough for this at a normal viewing scale).
However I think what everyone wants is to have these available even
when the LDconfig file is found. What would be best is if MLCad could
replace only the colors that have been "refined" by LDconfig.ldr, and
leave the others still defined with the new solid versions of the old
dithered colors. That would be perfect!
Enjoy,
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | |
Hello Don,
> "Don Heyse" <dheyse@hotmail.spam.go.away.com> schrieb im Newsbeitrag
> news:KxLH93.EEK@lugnet.com...
> However I think what everyone wants is to have these available even
> when the LDconfig file is found. What would be best is if MLCad could
> replace only the colors that have been "refined" by LDconfig.ldr, and
> leave the others still defined with the new solid versions of the old
> dithered colors. That would be perfect!
I thought the LDraw group doesn't allow any other colors than the standard
ones?
Even so I was in the assumption that I didn't create any special colors, but
I toulk them over from some
old spec where these colors where mentioned.
I got confused about this discussion with colors anyway - but here is my
opinion:
- MLCad should not automatically provide any none standard colors
- But maybe we should have a look at the ldconfig.ldr file and check wether
we realy got all colors or if we are missing some ...
Best regards,
Michael
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Lachmann wrote:
> I thought the LDraw group doesn't allow any other colors than the standard
> ones?
As it happens, the LSC has been dealing with this very issue for the past few
months. There is no mention made of dither colors in any of the current LDraw
specs (including the official parts restrictions). They somehow got dropped
(accidentally) from the LDraw 1.0 spec (they were in the LDraw 0.27 spec). I
know that they were dropped accidentally because I was a member of the LSC that
ratified the LDraw 1.0 spec, and "dither" and "dithered" were never once
mentioned in the discussions that ratified that.
Having said that, they are used in a number of official parts, they are used in
parts on the tracker, and as such they have to be considered to be implicitly
allowed.
> Even so I was in the assumption that I didn't create any special colors, but
> I toulk them over from some
> old spec where these colors where mentioned.
I'm guessing you took them from the behavior of ldraw.exe. They were supported
there, so you supported them. Having said that, despite their lack of
up-to-date documentation, they are required by official parts.
Because of this, I would strongly recommend using the old dither algorithm for
the default color of all colors in the 256-511 color number region. Entries in
LDConfig.ldr would then override these default colors. Please note that entries
in this region are designed to be similar to the original dither color. The
color numbers were picked so that software that didn't support LDConfig.ldr
would produce similar output.
> I got confused about this discussion with colors anyway - but here is my
> opinion:
> - MLCad should not automatically provide any none standard colors
> - But maybe we should have a look at the ldconfig.ldr file and check wether
> we realy got all colors or if we are missing some ...
The LSC is strongly opposed to non-brick colors going into LDConfig.ldr (with a
few exceptions). This hasn't been ratified as a requirement yet, but it almost
certainly will be. Patterned parts require non-brick colors, and up until now
that has been accomplished mainly with "dither" colors.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
"Travis Cobbs" <tcobbs@REMOVEgmail.com> schrieb im Newsbeitrag
news:Kxn3yE.p2D@lugnet.com...
> Because of this, I would strongly recommend using the old dither algorithm
> for
> the default color of all colors in the 256-511 color number region.
> Entries in
> LDConfig.ldr would then override these default colors. Please note that
> entries
> in this region are designed to be similar to the original dither color.
> The
> color numbers were picked so that software that didn't support
> LDConfig.ldr
> would produce similar output.
So I will take over parts of the build in color table in the range of 256 to
511. During this step the programm
will convert these dittered colors into a single color which is than a
mixture of both colors.
I guess this is what we all would like to have.
Alternativly I can load the internal color table and just overwrite colors
defined in ldconfig.ldr
I'm open at this point ... however you like
Michael
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Lachmann wrote:
> "Travis Cobbs" <tcobbs@REMOVEgmail.com> schrieb im Newsbeitrag
> news:Kxn3yE.p2D@lugnet.com...
> > Because of this, I would strongly recommend using the old dither algorithm
> > for
> > the default color of all colors in the 256-511 color number region.
> > Entries in
> > LDConfig.ldr would then override these default colors. Please note that
> > entries
> > in this region are designed to be similar to the original dither color.
> > The
> > color numbers were picked so that software that didn't support
> > LDConfig.ldr
> > would produce similar output.
>
> So I will take over parts of the build in color table in the range of 256 to
> 511. During this step the programm
> will convert these dittered colors into a single color which is than a
> mixture of both colors.
>
> I guess this is what we all would like to have.
>
> Alternativly I can load the internal color table and just overwrite colors
> defined in ldconfig.ldr
>
> I'm open at this point ... however you like
>
> Michael
Hmm. "You may think this is easy, but wait 'til I've explained it to you!" (One
of my father's favourite standard joke.)
I don't know how much difference it will make, but current standard colors are
much better than the 16 original LDraw color palette. Most of the colors are
significantly darker, some are very different. The dithering was made with the
original palette, now should we use these or the new, improved colors as
components in the dithering?
/Tore
Chief LDraw Complicator
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Tore Eriksson wrote:
> The dithering was made with the
> original palette, now should we use these or the new, improved colors as
> components in the dithering?
>
> /Tore
> Chief LDraw Complicator
Of course, I mean the blending, not the dithering...
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
--SNIP--
> Most of the colors are
> significantly darker, some are very different. The dithering was made with the
> original palette, now should we use these or the new, improved colors as
> components in the dithering?
>
> /Tore
> Chief LDraw Complicator
Good thinking. Since the old colours were derived from the EGA colour palette I
reckon the dithers would have to be derived from it too. Otherwise you could end
up with some very different blends.
I like your signature ;)
Tim
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Timothy Gould wrote:
> --SNIP--
>
> > Most of the colors are
> > significantly darker, some are very different. The dithering was made with the
> > original palette, now should we use these or the new, improved colors as
> > components in the dithering?
> >
> > /Tore
> > Chief LDraw Complicator
>
>
> Good thinking. Since the old colours were derived from the EGA colour palette I
> reckon the dithers would have to be derived from it too. Otherwise you could end
> up with some very different blends.
>
> I like your signature ;)
>
> Tim
Also I am thinking that we have to use the original color values for the color 0
- 15 to build the blended colors. Otherwise we get other colors.
This range should be known by every LDraw related application.and only
overwritten by entries found in the LDConfig.ldr.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Travis wrote:
> > Because of this, I would strongly recommend using the old dither
> > algorithm for the default color of all colors in the 256-511 color
> > number region. Entries in LDConfig.ldr would then override these
> > default colors. Please note that entries in this region are
> > designed to be similar to the original dither color. The color
> > numbers were picked so that software that didn't support
> > LDConfig.ldr would produce similar output.
>
> So I will take over parts of the build in color table in the range of
> 256 to 511. During this step the programm will convert these dittered
> colors into a single color which is than a mixture of both colors.
>
> I guess this is what we all would like to have.
>
> Alternativly I can load the internal color table and just overwrite
> colors defined in ldconfig.ldr
I think Travis' wording may be confusing. Don't use "the old dither
algorithm". MLCad 3.30 draws colors 256-511 as *solid* colors. That's
better than using the stippling algorithm from previous MLCad versions.
(No new/current software stipples the colors in the 256-511 range.)
However the colors in the 256-511 region *are* standard colors and should
be available (using the solid mixed colors). Some of these colors may
be overridden by slightly modified hues in LDConfig.ldr, just like the
colors in the 0-32 range.
I don't know if that's any clearer than what Travis wrote...
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Don Heyse wrote:
> I think Travis' wording may be confusing. Don't use "the old dither
> algorithm". MLCad 3.30 draws colors 256-511 as *solid* colors. That's
> better than using the stippling algorithm from previous MLCad versions.
> (No new/current software stipples the colors in the 256-511 range.)
> However the colors in the 256-511 region *are* standard colors and should
> be available (using the solid mixed colors). Some of these colors may
> be overridden by slightly modified hues in LDConfig.ldr, just like the
> colors in the 0-32 range.
>
> I don't know if that's any clearer than what Travis wrote...
>
> Don
How about just "use the 'dithered' range but apply LDConfig on top of them,
overriding any colour that gets in the way"?
-Santeri
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Santeri Piippo wrote:
> In lugnet.cad.mlcad, Don Heyse wrote:
> > I think Travis' wording may be confusing. Don't use "the old dither
> > algorithm". MLCad 3.30 draws colors 256-511 as *solid* colors. That's
> > better than using the stippling algorithm from previous MLCad versions.
> > (No new/current software stipples the colors in the 256-511 range.)
> > However the colors in the 256-511 region *are* standard colors and should
> > be available (using the solid mixed colors). Some of these colors may
> > be overridden by slightly modified hues in LDConfig.ldr, just like the
> > colors in the 0-32 range.
> >
> > I don't know if that's any clearer than what Travis wrote...
> >
> > Don
>
> How about just "use the 'dithered' range but apply LDConfig on top of them,
> overriding any colour that gets in the way"?
>
> -Santeri
That is exactly what I was thinking about last days.
First load MLCad standard colours (like they have been for year).
Then replace all the colors for that you will find an entry in the LDConfig.ldr.
I would prefer to really keep the blended colors based on the old values, as
otherwise we change a lot of colors and maybe break some pattern.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Travis Cobbs wrote:
> They somehow got dropped
> (accidentally) from the LDraw 1.0 spec (they were in the LDraw 0.27 spec). I
> know that they were dropped accidentally because I was a member of the LSC that
> ratified the LDraw 1.0 spec, and "dither" and "dithered" were never once
> mentioned in the discussions that ratified that.
I can confirm that. While the LSC may have dithered over the spec, we certainly
didn't drop "dither" intentionally.
(Mind you, given the number of referenced specs we had to ratify first before we
could get onto "the biggie", I'm surprised we only missed one thing - and it's
taken several years to spot that!)
William
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> In lugnet.cad.mlcad, Michael Lachmann wrote:
> > I thought the LDraw group doesn't allow any other colors than the standard
> > ones?
In lugnet.cad.mlcad, Travis Cobbs wrote:
> As it happens, the LSC has been dealing with this very issue for the past few
> months. There is no mention made of dither colors in any of the current LDraw
> specs (including the official parts restrictions). They somehow got dropped
> (accidentally) from the LDraw 1.0 spec (they were in the LDraw 0.27 spec). I
> know that they were dropped accidentally because I was a member of the LSC that
> ratified the LDraw 1.0 spec, and "dither" and "dithered" were never once
> mentioned in the discussions that ratified that.
I've been surprised by some of this discussion of dithered colors, because when
Foundry was created (not by me), it was done as a "clean room" project, based
entirely off of specs, so it's the closest thing out there to a reference
parser, and it's always supported the colors.
Now that you mentioned this, Travis, I recall that we did hit this roadblock and
noticed that missing piece of the puzzle. If I recall correctly, LDView code
was used as our reference on how to handle things. When that appeared to have a
few puzzling questions, we went to some of the specs around (as I recall)
ldlite, and used the various approaches that seemed most in common to codify how
to handle colors.
In addition, I asked that it support alphanumeric color names from ldconfig.ldr,
especially in its user interface, but also in code because we needed that for
the OBI project.
-- joshuaD
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Joshua Delahunty wrote:
> Now that you mentioned this, Travis, I recall that we did hit this roadblock and
> noticed that missing piece of the puzzle. If I recall correctly, LDView code
> was used as our reference on how to handle things. When that appeared to have a
> few puzzling questions, we went to some of the specs around (as I recall)
> ldlite, and used the various approaches that seemed most in common to codify how
> to handle colors.
LDView's blending code was originally written to handle LDLite's 0 COLOR syntax,
since that is what was originally used in LDConfig.ldr. LDLite's syntax allows
for the dithering of two arbitrary colors, either or both of which can
themselves be transparent (although I'm not sure that was intentional). So
LDView's blend code pays attention to the alpha value of both incoming colors.
This is unnecessary for the original LDraw.exe "dither" colors, and is also
unnecessary for 0 !COLOUR colors.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hello Michael
>
> > In lugnet.cad.mlcad, Michael Heidemann wrote:
> > Now that I have installed MLCad and read all informations I hope we can
> > get an
> > update soon. I have two reason:
> > 1) Implementation of language support is different to what we have
> > implemented.
> I'm currently looking into that.
If you have any question regarding this, please don't hesitate to contact me, as
I have already made DATHeader using this new feature.
>
> > 2) I miss the "dithered" colours. Not the dithered itself, but the range
> > of
> > colours I could choose from to make pattern parts.
> ? I cannot understand.
> There is no such range, MLCad takes that what comes from LDConfig nothing
> more, nothing less.
> Dithered colors originally have been according to the original definition of
> LDraw. MLCad now no longer uses them, but only the
> definition from LDConfig.
> If you feel that colors are missing, than we should add them to this file
Yes, I miss that as they are used in parts already. But others already have
answered this question very well, so nothing new from my side.
Thanks for having an open ear for all our wishes.
cu
mikeheide
I had also detected some other issue (bugs?) but can at present not reproduce
that. Will try to find that again. It has been during my playing around with the
colors.
As soon as I found it again, I'll let you know.
| | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Lachmann wrote:
> Hi,
>
> I would like to announce that I've just released a new version of MLCad!
>
> MLCad V3.30
>
> What's new:
> - Development environment was changed to Visual Studio 2005
> - Support for color definitions in LdConfig.ldr
> - Empty lines are no longer removed (for part authoring)
> - New default groups (Minifig, Slope and Tile)
> - Several bug fixes
>
> More detailed informations can be found in the release notes of the package.
>
> Best regards,
> Michael
This is excellent news Michael! Thank you so much for all of your hard work.
We couldn't ask for anything more, especially since you do this for free!
I hope that you know how much the entire community appreciates your effort!
Many thanks,
Scott W.
| | | | | | | | | | | | | | | | | |
Hello Michael,
I just want to thank you for the constant work you’re doing to develop and
upgrade this tremendous tool!
Regards
Marco
| | | | | | | | | | | | | | | | | |
There is a bug in the generated partslist when using a new color.
For example when I use a part with color 81 Metalic_Green it reports as
Chrome_Black.
See: http://www.binarybricks.nl/test/colorerror.gif
Can this be resolved with a change in ldconfig or is a real bug in MLCad 3.30?
Jaco
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Jaco van der Molen wrote:
> There is a bug in the generated partslist when using a new color.
> For example when I use a part with color 81 Metalic_Green it reports as
> Chrome_Black.
> See: http://www.binarybricks.nl/test/colorerror.gif
> Can this be resolved with a change in ldconfig or is a real bug in MLCad 3.30?
>
> Jaco
I duplicated the error, and it looks to be a bug in MLCAD.
Scott W.
| | | | | | | | | | | | | | | | | | |
| |
|
Hi,
This is something that's been bugging me for a while, but since MLCAD is free
software and very useful even without this feature, I haven't made much of a
fuss about it. However, I thought I'd throw it out here so others can comment
on it and so Mike L. can pick it up and implement it if he wants to.
A little background:
I like to build (and therefore draw) complex mechanical contraptions that
require lots of odd angles to make the pins line up. My latest one, for
example, is a pneumatic train locomotive with working (not just decorative)
Walschaerts valve gear. To draw something like this accurately, I currently
have to:
1. Select all the parts that make up a push-pull link, starting with the pin
that is already lined up (or set the rotation point manually)
2. Zoom in on the other end of the link, which is not lined up yet
3. Rotate by sub-degree increments until it's "close enough"
4. Do this again with the lever that it's supposed to attach to
5. Add some more parts and repeat
6. Guess at how it's going to work in real life
My idea:
Add a feature to MLCAD that would allow me to:
1. Define the link as a physical unit (however that's done)
2. Attach one end of the link (however that's done)
3. Attach the other end of the link (however that's done)
4. Add some more parts and repeat
5. Move any part (rotate the wheels in my example) and see exactly how it's
going to work (or at least catch some of the bigger bugs)
Basically, it's a motion simulator.
For what I need right now, simply joining pairs of parts at user-defined points
(relative to each part, not the origin) is good enough. More points would make
a more rigid connection. The simulator would then move any part(s)
automatically to satisfy all such points in the model. Eventually, I'd like to
simulate gears and other parts that aren't always connected at the same
point(s), but let's keep it simple for now.
What do you think?
Thanks,
Aaron
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Aaron Duerksen wrote:
> Hi,
>
> This is something that's been bugging me for a while, but since MLCAD is free
> software and very useful even without this feature, I haven't made much of a
> fuss about it. However, I thought I'd throw it out here so others can comment
> on it and so Mike L. can pick it up and implement it if he wants to.
>
> A little background:
> I like to build (and therefore draw) complex mechanical contraptions that
> require lots of odd angles to make the pins line up. My latest one, for
> example, is a pneumatic train locomotive with working (not just decorative)
> Walschaerts valve gear. To draw something like this accurately, I currently
> have to:
> 1. Select all the parts that make up a push-pull link, starting with the pin
> that is already lined up (or set the rotation point manually)
> 2. Zoom in on the other end of the link, which is not lined up yet
> 3. Rotate by sub-degree increments until it's "close enough"
> 4. Do this again with the lever that it's supposed to attach to
> 5. Add some more parts and repeat
> 6. Guess at how it's going to work in real life
>
> My idea:
> Add a feature to MLCAD that would allow me to:
> 1. Define the link as a physical unit (however that's done)
> 2. Attach one end of the link (however that's done)
> 3. Attach the other end of the link (however that's done)
> 4. Add some more parts and repeat
> 5. Move any part (rotate the wheels in my example) and see exactly how it's
> going to work (or at least catch some of the bigger bugs)
> Basically, it's a motion simulator.
>
> For what I need right now, simply joining pairs of parts at user-defined points
> (relative to each part, not the origin) is good enough. More points would make
> a more rigid connection. The simulator would then move any part(s)
> automatically to satisfy all such points in the model. Eventually, I'd like to
> simulate gears and other parts that aren't always connected at the same
> point(s), but let's keep it simple for now.
>
> What do you think?
>
> Thanks,
> Aaron
That would be a great enhencement for MLCad and it should be possible. But I do
not know how many hours Michael L. has to spend for that.
If you want to try another application please try SR3DBuilder. As fas as I can
see the required feature is exacly what that app does.
Here the link to that app http://staff.polito.it/sergio.reano/
cu
mikeheide
| | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Michael Heidemann wrote:
> If you want to try another application please try SR3DBuilder. As fas as I can
> see the required feature is exacly what that app does.
> Here the link to that app http://staff.polito.it/sergio.reano/
>
> cu
> mikeheide
Wow! I think you're right! SR3DBuilder looks exactly like what I'm looking
for...except I'm on Ubuntu Linux and it doesn't work in Wine, where MLCAD is
flawless. I asked Sergio about this through his website, so I'll see what he
says.
Thanks Mike!
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Aaron Duerksen wrote:
> In lugnet.cad.mlcad, Michael Heidemann wrote:
> > If you want to try another application please try SR3DBuilder. As fas as I can
> > see the required feature is exacly what that app does.
> > Here the link to that app http://staff.polito.it/sergio.reano/
> >
> > cu
> > mikeheide
>
> Wow! I think you're right! SR3DBuilder looks exactly like what I'm looking
> for...except I'm on Ubuntu Linux and it doesn't work in Wine, where MLCAD is
> flawless. I asked Sergio about this through his website, so I'll see what he
> says.
>
> Thanks Mike!
Well, after a long discussion with Sergio via e-mail and a period of trying
different things, it appears that SR3DBuilder will only run (both now and in the
future) on a native installation of Windows (not even a virtual machine) that
has a fairly recent version of Microsoft's .NET framework and DirectX. It also
needs a video card that supports that version of DirectX. Any old machine that
you pull out of the closet and set up in the play room will not work.
The installer displays an error message and exits if it doesn't find the .NET
framework, and the program crashes on startup (displays Windows' standard
"encountered a problem and needs to close" message) if it doesn't find the
DirectX software or a video card that supports it. There is a debug version as
well, but it does the same thing.
There is another program that Sergio suggested, called LD4DStudio. It does run
in Wine, but most of its interconnections seem to be based on user-written
scripts. Yes, it would work, but it seems like a lot more work than necessary.
So unless someone can prove me wrong, it looks like I'm back to requesting these
features in MLCAD.
Thanks,
Aaron
| | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Aaron Duerksen wrote:
> unless someone can prove me wrong, it looks like I'm back to requesting
> these features in MLCAD.
You could try to track down a copy of leoCAM. Maybe that'll do it.
Or perhaps some of the leoCAM features have migrated back into leocad?
I don't know, but it might be worth a look.
Good luck,
Don
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.mlcad, Don Heyse wrote:
> In lugnet.cad.mlcad, Aaron Duerksen wrote:
> > unless someone can prove me wrong, it looks like I'm back to requesting
> > these features in MLCAD.
>
> You could try to track down a copy of leoCAM. Maybe that'll do it.
> Or perhaps some of the leoCAM features have migrated back into leocad?
> I don't know, but it might be worth a look.
>
> Good luck,
>
> Don
LeoCAM had a really rudimentary "snap-to" functionality added to LeoCAD. It
didn't work entirely well, and was never entirely completed (as it was an
academic proof, rather than an actual attempt to create a functionality).
The sources have been captured, but none of it has migrated to LeoCAD yet.
(I'm speaking to this because I spent some time to try to encourage migration of
the functionality to LeoCAD, and was also lined up to help the translation
efforts of the manual to better english. Since the source became very difficult
to get ahold of online, and Leonardo wanted to add the same functionality to
LeoCAD but in a different way, I let it drop).
-- joshua
| | | | | | | | | | | | | | | | | |
In lugnet.cad.mlcad, Don Heyse wrote:
> In lugnet.cad.mlcad, Aaron Duerksen wrote:
> > unless someone can prove me wrong, it looks like I'm back to requesting
> > these features in MLCAD.
>
> You could try to track down a copy of leoCAM. Maybe that'll do it.
> Or perhaps some of the leoCAM features have migrated back into leocad?
> I don't know, but it might be worth a look.
>
> Good luck,
>
> Don
Well, it's been a while since I've checked, and now there's a forum dedicated to
SR3DBuilder, which looks like the best solution by far to what I'm looking for.
It still doesn't run on Linux, but that is exactly one of the topics on the
forum:
http://sr3d.spoonclan.com/viewtopic.php?f=15&t=11
Maybe that'll come to something?
| | | | | | |
