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