 | | | | | | |
| |
|
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.
| | | | | | |
