| |
Please read and respond to this message if you are a parts author, particularly
if you have authored any patterned or sticker parts.
The LSC is trying to come up with rules for colors for both LDConfig.ldr and
official parts. We are having an internal disagreement about whether the
so-called “dither” colors are still needed for use in patterned and sticker
parts. Since none of us have much experience with authoring these parts, we
decided that we needed to get the opinions of existing authors of such parts.
Please note: we are specifically looking for opinions from people who have
authored patterned/sticker parts. That isn’t to say that we will ignore other
input, but be aware that such input will have less bearing on our decision than
input from patterned/sticker part authors.
At this point, we’ve come up with three possible options:
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
- Explicitly disallow “dither” colors in all official parts, but allow RGB colors (of the form 0x2RRGGBB) in their place in patterned/sticker parts.
- Explicitly disallow “dither” colors in all official parts, and require all patterned/sticker parts to be created using “brick” colors from LDConfig.ldr.
A few items to clarify:
- I always put “dither” in quotes, because any official recognition of said colors will be as the RGB value that the two colors average together to form, and NOT the dither pattern that was originally used in ldraw.exe.
- We don’t plan to allow non-brick 0 !COLOUR statements in LDConfig.ldr, although that’s a separate but related issue. Hence my putting “brick” in the third option.
--Travis Cobbs (on behalf of the 2009-2010 LSC)
2009-2010 LSC Members (alphabetically by last name):
Travis Cobbs
Michael Heidemann
Santeri Piippo
Allen Smith
Scott Wardlaw
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> At this point, we've come up with three possible options:
For what it counts, I'd go for:
* Explicitly disallow "dither" colors in all official parts, but allow RGB
colors (of the form 0x2RRGGBB) in their place in patterned/sticker parts.
This solution would give me the most freedom. I could just pick the RGB from a
picture/scan and use is without carrying if there is a dithered or brick color
somewhere.
My patterns/stickers: http://www.holly-wood.it/ldraw/authored-en.html (some
would benefit from RBGs if they would have been allowed in the past).
w.
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
The LSC is trying to come up with rules for colors for both LDConfig.ldr and
official parts. We are having an internal disagreement about whether the
so-called “dither” colors are still needed for use in patterned and sticker
parts. Since none of us have much experience with authoring these parts, we
decided that we needed to get the opinions of existing authors of such parts.
Please note: we are specifically looking for opinions from people who have
authored patterned/sticker parts. That isn’t to say that we will ignore
other input, but be aware that such input will have less bearing on our
decision than input from patterned/sticker part authors.
At this point, we’ve come up with three possible options:
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
- Explicitly disallow “dither” colors in all official parts, but allow RGB colors (of the form 0x2RRGGBB) in their place in patterned/sticker parts.
|
It would be very interesting which applications can not work with the (RGB
colors (of the form 0x2RRGGBB)).
Are they useful/necessary/developed?
If someone has those application to test and make a summary of that would be
great.
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts, Willy Tschager wrote:
> For what it counts, I'd go for:
>
> * Explicitly disallow "dither" colors in all official parts, but
> allow RGB colors (of the form 0x2RRGGBB) in their place in
> patterned/sticker parts.
>
> This solution would give me the most freedom. I could just pick the
> RGB from a picture/scan and use is without carrying if there is a
> dithered or brick color somewhere.
I'm not much of a part author, so my opinion probably counts for even
less than usual here, but I actually find myself agreeing with Willy
on a issue involving colors. That never happens! ;) But heck, who
can argue against freedom and simplicity?
Besides, I'd guess that there are probably zero programs where the
dithered colors look good (ie. not really dithered) and the 0x2RRGGBB
colors look bad (ie. not supported). So there's no downside to
selecting this over the first choice. And the third choice is simply
to restrictive for stickers.
The only thing I'd like to add is that maybe we should apply the rules
for printed parts when a sticker pattern is an exact match for a
printed part pattern.
> My patterns/stickers:
> http://www.holly-wood.it/ldraw/authored-en.html (some would benefit
> from RBGs if they would have been allowed in the past).
Have fun,
Don
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
The LSC is trying to come up with rules for colors for both LDConfig.ldr and
official parts. We are having an internal disagreement about whether the
so-called “dither” colors are still needed for use in patterned and sticker
parts. Since none of us have much experience with authoring these parts, we
decided that we needed to get the opinions of existing authors of such parts.
Please note: we are specifically looking for opinions from people who have
authored patterned/sticker parts. That isn’t to say that we will ignore
other input, but be aware that such input will have less bearing on our
decision than input from patterned/sticker part authors.
At this point, we’ve come up with three possible options:
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I don’t know if I got that right. Isn’t Maersk Blue one of those part colors
most wrongfully and misleadingly labeled as a “dithered” color?
| |
- Explicitly disallow “dither” colors in all official parts, but allow RGB colors (of the form 0x2RRGGBB) in their place in patterned/sticker parts.
- Explicitly disallow “dither” colors in all official parts, and require all patterned/sticker parts to be created using “brick” colors from LDConfig.ldr.
A few items to clarify:
- I always put “dither” in quotes, because any official recognition of said colors will be as the RGB value that the two colors average together to form, and NOT the dither pattern that was originally used in ldraw.exe.
- We don’t plan to allow non-brick 0 !COLOUR statements in LDConfig.ldr, although that’s a separate but related issue. Hence my putting “brick” in the third option.
--Travis Cobbs (on behalf of the 2009-2010 LSC)
2009-2010 LSC Members (alphabetically by last name):
Travis Cobbs
Michael Heidemann
Santeri Piippo
Allen Smith
Scott Wardlaw
|
I suggest the 0x2RRGGBB form is recommended for less “basic”/established pattern
and sticker colors. It’s much more future safe than being dependant on using the
correct version of LDConfig.ldr. I may for example use a certain area of color
codes for Modulex colors which may conflict with the next LDConfig update. Other
LDraw users may make their own color definition in LDConfig.
I repeat my opinion when it comes to defining new part color numbers for the
official LDConfig.ldr, that they should be picked from the blended (=”dithered”)
area as long as there are free numbers to choose. Thus, anyone who hasn’t the
latest LDConfig would get a fair closest existing color blend. And, of course,
no programs that support LDConfig will have any problems replacing that blended
color with the LDConfig entry! It sounds like some preople believe that picking
a number from that area would cause any problem, but that is of course not true.
Or is there something I’m unaware of?
/Tore
|
|
| |
In lugnet.cad.dat.parts, Tore Eriksson wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I don’t know if I got that right. Isn’t Maersk Blue one of those part colors
most wrongfully and misleadingly labeled as a “dithered” color?
|
Two things. First of all, is Maersk Blue hard-coded into any part files? I
would expect parts that show up in Maersk Blue to have color 16 encoded in the
file, and the user to select Maersk Blue as the parts’ color when building a
model. Since we are only interested in restrictions on colors for official
parts, this wouldn’t be an issue here.
Secondly, we plan to recommend that LDConfig.ldr contain all “brick” colors,
meaning all colors that LEGO has shipped bricks in (including Maersk Blue). My
original list of options was ambiguous, but as long as a given color shows up in
LDConfig.ldr, we will be allowing it in parts, even if the color code picked
comes from the “dither” range. This will be the case no matter which of the
three options we decide upon. In other words, even if we forbid “dither” colors
from being used, colors in that range that also appear in LDConfig.ldr will
still be allowed.
| |
I repeat my opinion when it comes to defining new part color numbers for the
official LDConfig.ldr, that they should be picked from the blended
(=”dithered”) area as long as there are free numbers to choose. Thus, anyone
who hasn’t the latest LDConfig would get a fair closest existing color blend.
And, of course, no programs that support LDConfig will have any problems
replacing that blended color with the LDConfig entry! It sounds like some
preople believe that picking a number from that area would cause any problem,
but that is of course not true. Or is there something I’m unaware of?
|
What to do in LDConfig.ldr is that other half of our discussion. I can’t
remember the specifics off-hand, but we have pretty much agreed upon what to do
there. We will be releasing rules for LDConfig.ldr at the same time we enact
rules for color usage in official parts. I personally agree that new color
codes should be picked from the “dither” range where possible for maximum
backwards compatibility, but I can’t remember if this is the LSC consensus.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Tore Eriksson wrote:
> > I don't know if I got that right. Isn't Maersk Blue one of those part colors
> > most wrongfully and misleadingly labeled as a "dithered" color?
>
> Two things. First of all, is Maersk Blue hard-coded into any part files? I
> would expect parts that show up in Maersk Blue to have color 16 encoded in
> the file, and the user to select Maersk Blue as the parts' color when
> building a model. Since we are only interested in restrictions on colors for
> official parts, this wouldn't be an issue here.
I didn't get it right at all, but now I think I do. It isn't an issue here and,
believe it or not, I'm cool with it. :)
> Secondly, we plan to recommend that LDConfig.ldr contain all "brick" colors,
> meaning all colors that LEGO has shipped bricks in (including Maersk Blue).
> My original list of options was ambiguous, but as long as a given color shows
> up in LDConfig.ldr, we will be allowing it in parts, even if the color code
> picked comes from the "dither" range. This will be the case no matter which
> of the three options we decide upon. In other words, even if we forbid
> "dither" colors from being used, colors in that range that also appear in
> LDConfig.ldr will still be allowed.
Good! :)
>
> What to do in LDConfig.ldr is that other half of our discussion. I can't
> remember the specifics off-hand, but we have pretty much agreed upon what to
> do there. We will be releasing rules for LDConfig.ldr at the same time we
> enact rules for color usage in official parts. I personally agree that new
> color codes should be picked from the "dither" range where possible for
> maximum backwards compatibility, but I can't remember if this is the LSC
> consensus.
>
> --Travis
I'm glad that at least I'm not alone with this opinion. :)
/T
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I have authored patterned parts, and for me this is the only viable option.
This has worked just fine for the past decade, and I don’t see any good reason
why it should be broken. The second option (using 0x2RRGGBB) would just be very
inconvenient, especially for new authors, and the third option, limiting the
color palette even further, would make it impossible to do good patterned
parts.
What about the fourth option of allowing dithered colors (i.e. keeping the
status quo) but also allowing RGB colors? That would also be fine with me.
| |
- We don’t plan to allow non-brick 0 !COLOUR statements in LDConfig.ldr, although that’s a separate but related issue. Hence my putting “brick” in the third option.
|
I would really rather see every color from 0 to 511 added to the LDConfig file,
with a ~ in front of the name if it’s not an actual brick (or metal, etc) color.
I still don’t see what the objection is to doing it like this; it works out just
fine for part titles.
|
|
| |
Hello,
"Travis Cobbs" <tcobbs@REMOVEgmail.com> schrieb im Newsbeitrag
news:KxEAq2.86J@lugnet.com...
> Please read and respond to this message if you are a parts author,
> particularly
> if you have authored any patterned or sticker parts.
>
> [...]
>
> At this point, we've come up with three possible options:
>
> * Explicitly allow "dither" colors in official patterned/sticker parts.
> Right
> now, they are used, but we could not find anywhere in any specification
> where
> they are even mentioned. This option would essentially officially
> recognize
> the current status quo. (I'm not aware of any "dither" colors being used
> outside of patterns/stickers, but we don't intend to allow that.)
I used dithered colors in the "Flag 2x2 with Goblets and Grapes" (2335p40).
So in this case no other color would match the silver or gold color of the
original part.
Thatswhy my answer, for your question, is the above one.
Regards
Bernd
|
|
| |
In lugnet.cad.dat.parts, Andrew Westrate wrote:
| |
I would really rather see every color from 0 to 511 added to the LDConfig
file, with a ~ in front of the name if it’s not an actual brick (or metal,
etc) color. I still don’t see what the objection is to doing it like this; it
works out just fine for part titles.
|
I hadn’t thought about this, but I kinda like the idea. The original LDRAW
defined values for all color codes, and some of the newer codes were assigned
because they are a variation/change from existing colors.
The downside of this idea is that programs would have to be updated to ignore
the ~colors.
Steve
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
|
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I would go for this option.
I’m not a fan of allowing RGB values in official part files, I’d rather keep it
to color codes.
However, if there could be a standard for texture mapping patterns & stickers
(and parts made by mixing multiple colors of plastic), that would solve this
dilemma -- simple patterns could be modeled with color codes, and advanced
patterns could be modeled with texture maps. But I’m just dreaming there...
Steve
|
|
| |
| |
However, if there could be a standard for texture mapping patterns & stickers
(and parts made by mixing multiple colors of plastic), that would solve this
dilemma -- simple patterns could be modeled with color codes, and advanced
patterns could be modeled with texture maps. But I’m just dreaming there...
|
I heartfully agree !!!
Philo
|
|
| |
In lugnet.cad.dat.parts, Philippe Hurbain wrote:
| |
| |
However, if there could be a standard for texture mapping patterns &
stickers (and parts made by mixing multiple colors of plastic), that would
solve this dilemma -- simple patterns could be modeled with color codes, and
advanced patterns could be modeled with texture maps. But I’m just dreaming
there...
|
I heartfully agree !!!
|
So, to expand a little on my earlier comments -- I think it would be reasonable,
for now, to allow dithered colors1 in pattern/sticker parts and disallow RGB
codes, with the thought that work would go forward on defining a texture mapping
methodology & language extension for official part files.
This approach allows the committee to proceed with the official standards
document on colors, utilizing the most widely supported mode (ie, color codes in
the dithered range).
--
Steve
1) Or, as Andrew suggested, add all color codes to LDConfig.ldr and then
restrict part authors to color codes defined in LDConfig.ldr.
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
|
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I would go for this option.
I’m not a fan of allowing RGB values in official part files, I’d rather keep
it to color codes.
|
Unfortunately, MLCad 3.3’s complete removal of support for dither colors (which
incidentally breaks it for a number of existing official parts) makes this
option less tenable. It’s a bit ironic that most of the people speaking up in
favor of dither colors did so AFTER the MLCad release that makes them not work,
while the people in favor of RGB spoke up before that release.
On a related note, dither colors are almost certainly never going to be added
en-mass to LDConfig.ldr. I believe that everyone in the current LSC is opposed
to that, and agrees that that is not what the file is for. At the very least a
majority of the current LSC feels this way, so the only way it will happen is
via a decision from a future LSC that overrides the official restrictions we
will be adding to what goes in that file.
| |
However, if there could be a standard for texture mapping patterns & stickers
(and parts made by mixing multiple colors of plastic), that would solve this
dilemma -- simple patterns could be modeled with color codes, and advanced
patterns could be modeled with texture maps. But I’m just dreaming there...
|
That could yet happen (and possibly much sooner than you might expect).
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Please read and respond to this message if you are a parts author,
particularly if you have authored any patterned or sticker parts.
|
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I would go for this option.
I’m not a fan of allowing RGB values in official part files, I’d rather keep
it to color codes.
|
Unfortunately, MLCad 3.3’s complete removal of support for dither colors
(which incidentally breaks it for a number of existing official parts) makes
this option less tenable.
|
That is not complete correct. If MLCad does not find a LDConfig.ldr then you
have your old colours back, including the dithered range!
I feel with the majority of the votes in this thread. Allow “Dithered” colours
and looking forward for texture mapping!
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
| |
However, if there could be a standard for texture mapping patterns &
stickers (and parts made by mixing multiple colors of plastic), that would
solve this dilemma -- simple patterns could be modeled with color codes, and
advanced patterns could be modeled with texture maps. But I’m just dreaming
there...
|
|
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
That could yet happen (and possibly much sooner than you might expect).
|
Since the proof-of-concept work for texture mapping took place “out in the open”
on Facebook, Steve is aware of what’s been done so far.
I think the real “dream” here is having it widely available, since to add
texture mapping to MLCAD without upgrading MLCAD to OpenGL would be quite a bit
of work, more than we might hope to see any time soon.
So while there’s a viable syntax and proof waiting to be implemented more
widely, and in fact texture mapping is here, today (my Facebook profile
picture being a very good example), it’s not imminent for widespread use by
everyone without a few more hurdles, unfortunately. :(
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Michael Heidemann wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Unfortunately, MLCad 3.3’s complete removal of support for dither colors
(which incidentally breaks it for a number of existing official parts) makes
this option less tenable.
|
That is not complete correct. If MLCad does not find a LDConfig.ldr then you
have your old colours back, including the dithered range!
|
I stand corrected. However, forcing the user to choose between LDConfig.ldr
support and dither color support pretty much makes dither colors useless in
MLCad 3.3 for a vast majority of users.
| |
I feel with the majority of the votes in this thread. Allow “Dithered”
colours and looking forward for texture mapping!
|
That was my original opinion. However, all the initial posts in this thread
advocated RGB colors, so I was willing to support that. Now MLCad breaks dither
colors for at least 95% of its users, which seems to make them a really bad
idea.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Michael Heidemann wrote:
| |
... and looking forward for texture mapping!
|
Michael (and anyone else), if you’ve got a Facebook account, you can see quite a
few examples of the texture mapping work that I created while working out the
syntax and getting working viewers going. Just send me a facebook invite
(“Joshua Delahunty”) and you can have a look.
Actually, all the photo albums should be public, so you don’t even have to
“Facebook friend” me to check it out.
I just recently gave our once glorious leader (Todd) his own facebook profile
image with a custom mini-figure face and the space cap that only exists as a cap
in the “real world”, not as a mini-figure item. I had also done the red town
torso image (the one with the space logo) in several ‘off’ colors per Abner
Finley’s request. Those are visible there, and I put Todd’s avatar in a couple
of them.
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
| |
However, if there could be a standard for texture mapping patterns &
stickers (and parts made by mixing multiple colors of plastic), that would
solve this dilemma -- simple patterns could be modeled with color codes,
and advanced patterns could be modeled with texture maps. But I’m just
dreaming there...
|
|
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
That could yet happen (and possibly much sooner than you might expect).
|
|
Considering the general pace we’ve alway had with LDraw.org, “sooner than
expected” would be impressive. ;)
| |
Since the proof-of-concept work for texture mapping took place “out in the
open” on Facebook, Steve is aware of what’s been done so far.
|
Actually, I’m not sure I’ve ever seen example source LDR/image files, or even a
definition of the syntax.
| |
I think the real “dream” here is having it widely available, since to add
texture mapping to MLCAD without upgrading MLCAD to OpenGL would be quite a
bit of work, more than we might hope to see any time soon.
So while there’s a viable syntax and proof waiting to be implemented more
widely, and in fact texture mapping is here, today (my Facebook profile
picture being a very good example), it’s not imminent for widespread use by
everyone without a few more hurdles, unfortunately. :(
|
True. But now that you’ve accomplished the POC (and assuming the POC is
sufficient for widespread adoption), the next step (for the parts library) is to
codify a language extension document. Then get it implemented in the software.
Hey! While we’re extending the language, can we also allow MPD in part files?
Steve
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
Hey! While we’re extending the language, can we also allow MPD in part
files?
Steve
|
I’ve been thinking about that as well. But I’m for now a bit of against such due
to the amount of work it’d take and the smallness of the pros in compared to
such. But I may be convinced otherwise fairly easily.
-Santeri
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
|
|
| |
| |
Since the proof-of-concept work for texture mapping took place “out in the
open” on Facebook, Steve is aware of what’s been done so far.
|
Actually, I’m not sure I’ve ever seen example source LDR/image files, or even
a definition of the syntax.
|
Me neither. Nothing on Facebook is “out in the open”, since it is a
walled garden.
Jim
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> Hey! While we're extending the language, can we also allow MPD in part
> files?
>
> Steve
Considering the conservative spirit that rules this community, where it is
preferred to have no-progress over breaking backwards compatibility an where
standards set in LDraw 0.27 should be possibly kept for eternity, such ideas
have to be flagged as quantum leap.
w.
|
|
| |
In lugnet.cad.dat.parts, Willy Tschager wrote:
> In lugnet.cad.dat.parts, Steve Bliss wrote:
> > Hey! While we're extending the language, can we also allow MPD in part
> > files?
> >
> > Steve
>
> Considering the conservative spirit that rules this community, where it is
> preferred to have no-progress over breaking backwards compatibility an where
> standards set in LDraw 0.27 should be possibly kept for eternity, such ideas
> have to be flagged as quantum leap.
I know. It's heresy!
But if there are enough good reasons to make that leap, it might be worth it.
Steve
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> In lugnet.cad.dat.parts, Willy Tschager wrote:
> > In lugnet.cad.dat.parts, Steve Bliss wrote:
> > > Hey! While we're extending the language, can we also allow MPD in part
> > > files?
> > >
> > > Steve
> >
> > Considering the conservative spirit that rules this community, where it is
> > preferred to have no-progress over breaking backwards compatibility an where
> > standards set in LDraw 0.27 should be possibly kept for eternity, such ideas
> > have to be flagged as quantum leap.
>
> I know. It's heresy!
>
> But if there are enough good reasons to make that leap, it might be worth it.
>
> Steve
I don't know why you need this, but I just did a test with LDView and it works.
You can call an mpd file from within a part and the first model in the mpd file
is shown together with the other content of the part file.
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
Hey! While we’re extending the language, can we also allow MPD in part
files?
|
This is the first time I’ve heard this mentioned. Can someone tell me why this
would be useful? I’m certainly open to the possibility, but only if it provides
a concrete benefit, and I’m not having any luck coming up with what that benefit
would be. It would decrease the number of files in the parts library, but it
would also make any internal files inaccessible to other parts. And given that
the internal files would be in the s subpart directory anyway, I’m not sure that
decreasing the number of files is all that useful. But I’m certainly open to
the possibility that I’ve missed something.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Jim DeVona wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
|
|
| |
| |
Since the proof-of-concept work for texture mapping took place “out in the
open” on Facebook, Steve is aware of what’s been done so far.
|
Actually, I’m not sure I’ve ever seen example source LDR/image files, or
even a definition of the syntax.
|
Me neither. Nothing on Facebook is “out in the open”, since it is a
walled garden.
|
By the definitions of that article, *LUGNET* is a walled garden.
<blank stare>
I have put up a step-by-step showing example source LDR/image files. I did it
on Facebook, because it took me almost no time to do. I’d either have had to
set up my own page with captions and HTML and whatnot, or used the arbitrary
walled-garden LUGNET syntax, or perhaps joined FLICKR (its own community) and
figured out those nuances (and I believe I have better control over
text/captions and ordering on Facebook, so the presentation proceeds in the
right order).
I joined Facebook because Todd and Suz were there, and it was how I could
communicate with them. I thought they were downright nuts at first, and had to
be dragged in kicking and screaming. When I did, however, at least 35 invites
flew my way from ALE’s I thought I barely knew (but they knew me).
Now when I post images from the proof-of-concept texture mapping syntax that I
developed -- in private because a) it’d been jump started and failed about 3
times previously because of design-by-committee and b) the fact that attitude
and preference often get in the way of progress and development -- I have 50
ALEs see it immediately, many of them TLG employees.
I also get to drop an f-bomb and have no one freak out, if I want to (not that I
would do so capriciously, but it’s darned nice to have the option).
I respect your opinion, Jim, but this is LUGNET member number 3 insisting that
he chose the right vehicle for the job at hand, without a doubt in his mind.
http://www.facebook.com/album.php?aid=2048041&id=1532162912&l=4199f78c01
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> In lugnet.cad.dat.parts, Willy Tschager wrote:
> > In lugnet.cad.dat.parts, Steve Bliss wrote:
> > > Hey! While we're extending the language, can we also allow MPD in part
> > > files?
> > >
> > > Steve
> >
> > Considering the conservative spirit that rules this community, where it is
> > preferred to have no-progress over breaking backwards compatibility an where
> > standards set in LDraw 0.27 should be possibly kept for eternity, such ideas
> > have to be flagged as quantum leap.
>
> I know. It's heresy!
>
> But if there are enough good reasons to make that leap, it might be worth it.
>
> Steve
HURRAY! And in one go we are also gonna drop dithered colors in favour of RGBs.
We'll have textures, the LSC is finally shaping the LCD - LDraw Connection
Database http://news.lugnet.com/cad/?n=11226 and yourself are going to help
getting LDView working as PT rendering engine
http://news.lugnet.com/cad/?n=16608
Keep your password for the mysql database at hand!
w.
|
|
| |
In lugnet.cad.dat.parts, Willy Tschager wrote:
> HURRAY! And in one go we are also gonna drop dithered colors in favour of RGBs.
Err, what? No, don't mix color codes and RGBs in official parts! This isn't an
issue of backwards compatibility. It's an issue of adding complexity where it
isn't needed (IMO, of course).
> Keep your password for the mysql database at hand!
Ha! I'd have to get it back from Chris...
Steve
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
This is the first time I’ve heard this mentioned. Can someone tell me why
this would be useful? I’m certainly open to the possibility, but only if it
provides a concrete benefit, and I’m not having any luck coming up with what
that benefit would be. It would decrease the number of files in the parts
library, but it would also make any internal files inaccessible to other
parts. And given that the internal files would be in the s subpart directory
anyway, I’m not sure that decreasing the number of files is all that useful.
But I’m certainly open to the possibility that I’ve missed something.
|
I think eliminating part-specific subfiles would be a nice file-management
benefit, if nothing else.
I expect that reducing the number of part-specific subfiles would speed up the
part-approval process, always a good thing.
The most important benefit is that authors would be empowered to fully exploit
the potential of subfiles to speed up authoring, to reduce file size, to reduce
repetitive code.
Think about what software development would be like without
subroutines/functions/methods. You could kind of accomplish the same effect by
writing a number of different programs that all call each other, but it wouldn’t
be as powerful -- and in many cases, wouldn’t work at all. That’s the kind of
difference having MPD part files could have.
Steve
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
I think eliminating part-specific subfiles would be a nice file-management
benefit, if nothing else.
|
I can see that, although a great deal of care would need to be taken to make
sure that the MPD sub-files had no chance of being useful in another part.
| |
I expect that reducing the number of part-specific subfiles would speed up
the part-approval process, always a good thing.
|
I can definitely see that.
| |
The most important benefit is that authors would be empowered to fully
exploit the potential of subfiles to speed up authoring, to reduce file size,
to reduce repetitive code.
Think about what software development would be like without
subroutines/functions/methods. You could kind of accomplish the same effect
by writing a number of different programs that all call each other, but it
wouldn’t be as powerful -- and in many cases, wouldn’t work at all. That’s
the kind of difference having MPD part files could have.
|
I totally disagree with this as an argument for MPDs. We already have the s/
directory for subfiles, and said subfiles (subroutines in your analogy) are
available for use by any other parts that want to use them. In your analogy,
MPD subfiles are private functions, and subfiles in s/ are public functions.
Both do have their place, but I’m still not convinced that private subfiles
wouldn’t cause more harm than good in the context of the parts library.
One reason I think it is potentially bad to make subfiles private via MPD is
that even if the subfile is only used for geometry specific to a single part,
having it be private in an MPD makes it unusable for patterned versions of that
part. And just because no patterned versions exist at the time that the MPD
part was created doesn’t mean that they won’t exist in the future.
I can see that MPDs would simplify the authoring of parts that benefit from
sub-files. However, I’m not sure that simplification counters the fact that
they hide said sub-files.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> In lugnet.cad.dat.parts, Travis Cobbs wrote:
> > This is the first time I've heard this mentioned. Can someone tell me why
> > this would be useful? I'm certainly open to the possibility, but only if it
> > provides a concrete benefit, and I'm not having any luck coming up with what
> > that benefit would be. It would decrease the number of files in the parts
> > library, but it would also make any internal files inaccessible to other
> > parts. And given that the internal files would be in the s subpart
> > directory anyway, I'm not sure that decreasing the number of files is all
> > that useful. But I'm certainly open to the possibility that I've missed
> > something.
>
> I think eliminating part-specific subfiles would be a nice file-management
> benefit, if nothing else.
>
> I expect that reducing the number of part-specific subfiles would speed up
> the part-approval process, always a good thing.
>
> The most important benefit is that authors would be empowered to fully
> exploit the potential of subfiles to speed up authoring, to reduce file size,
> to reduce repetitive code.
>
> Steve
I was about to write the same thing, but you beat me. I think it's a great
idea!
I can think of two potential problems:
1. Programs that create seams between parts but not models. (Are there any more
than L3P?) Depending on how they are programmed, would they treat
<LDrawDir>\Parts\*.mpd as parts or models?
2. Utilities like MkList. Would they sort .mpd files just as if they were .dat
files? Would they label them with correct Description line or something like: "0
FILE: 2222.dat"? Are there other programs that may have to be updated because of
this suggested change?
I think all LDraw modellers and renderers currently in use will handle mpd part
files flawlessly, and with my two question marks straightened out or any
necessary fixes made, I will without a doubt support this idea!
Tore
/Cheif Conservative LDraw User(?) ;)
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> Err, what? No, don't mix color codes and RGBs in official parts! This isn't an
> issue of backwards compatibility. It's an issue of adding complexity where it
> isn't needed (IMO, of course).
I apologize for dreaming out loud. For a sec I've forgotten that we are a
conservative community - at least some of us.
> > Keep your password for the mysql database at hand!
>
> Ha! I'd have to get it back from Chris...
No password, not a single CA-header edit on your agenda nor a library update
since ... was it 2004 or 2005? Steve, please help me out, what is that "LDraw
Parts Tracker Admin" title our still carrying for?
w.
|
|
| |
In lugnet.cad.dat.parts, Willy Tschager wrote:
>
> I apologize for dreaming out loud. For a sec I've forgotten that we are a
> conservative community - at least some of us.
Your passive-aggressive whining wears thin, Willy.
Your chief target laughs it off, but you keep at it.
What little sense of community there might be is not helped by this behavior or
attitude. This approach says a lot more about you (and probably me, for being
the one to point this out) than anyone else.
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> Your passive-aggressive whining wears thin, Willy.
>
> Your chief target laughs it off, but you keep at it.
Joshua,
got a link for you:
http://en.wikipedia.org/wiki/Irony
w.
|
|
| |
In lugnet.cad.dat.parts, Willy Tschager wrote:
> In lugnet.cad.dat.parts, Steve Bliss wrote:
> > Err, what? No, don't mix color codes and RGBs in official parts! This isn't an
> > issue of backwards compatibility. It's an issue of adding complexity where it
> > isn't needed (IMO, of course).
>
> I apologize for dreaming out loud. For a sec I've forgotten that we are a
> conservative community - at least some of us.
Not sure where you're going with that. I think adding RGB colors to official
parts would not be a net improvement to the parts library system. It has
nothing to do with backwards compatibility or conservatism.
Steve
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> Not sure where you're going with that. I think adding RGB colors to official
> parts would not be a net improvement to the parts library system. It has
> nothing to do with backwards compatibility or conservatism.
Steve,
our opposing positions on RGBs are known. What I seek in this very moment is
your position on the second question in this post:
http://news.lugnet.com/cad/dat/parts/?n=6493
"No password, not a single CA-header edit on your agenda nor a library update
since ... was it 2004 or 2005? Steve, please help me out, what is that "LDraw
Parts Tracker Admin" title our still carrying for?"
w.
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> In lugnet.cad.dat.parts, Willy Tschager wrote:
> > In lugnet.cad.dat.parts, Steve Bliss wrote:
> > > Err, what? No, don't mix color codes and RGBs in official parts! This isn't an
> > > issue of backwards compatibility. It's an issue of adding complexity where it
> > > isn't needed (IMO, of course).
> >
> > I apologize for dreaming out loud. For a sec I've forgotten that we are a
> > conservative community - at least some of us.
>
> Not sure where you're going with that. I think adding RGB colors to official
> parts would not be a net improvement to the parts library system. It has
> nothing to do with backwards compatibility or conservatism.
DOH! I forgot to include --
Part of the reason I think RGB colors are not the way to go is because they
don't solve the real problem -- there are a good number of patterns that can't
realistically be modeled in LDraw. Anything with gradients, for example. It
doesn't matter how much resolution your color palette has, gradients are about
pixels. Which leads to texture mapping -- a better solution, and actually
*more* radical. Texture mapping would allow more colors, more resolution, and
less work for authors.
And I'm not against RGB colors entirely, I think they are a great feature in
general. Just not in the official parts library.
Steve
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> In lugnet.cad.dat.parts, Willy Tschager wrote:
> >
> > I apologize for dreaming out loud. For a sec I've forgotten that we are a
> > conservative community - at least some of us.
>
> Your passive-aggressive whining wears thin, Willy.
>
> Your chief target laughs it off, but you keep at it.
>
> What little sense of community there might be is not helped by this behavior or
> attitude. This approach says a lot more about you (and probably me, for being
> the one to point this out) than anyone else.
>
> -- joshuaD
Time for a cadfight! :)
/Tore
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
In lugnet.cad.dat.parts, Michael Heidemann wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
Unfortunately, MLCad 3.3’s complete removal of support for dither colors
(which incidentally breaks it for a number of existing official parts)
makes this option less tenable.
|
That is not complete correct. If MLCad does not find a LDConfig.ldr then you
have your old colours back, including the dithered range!
|
I stand corrected. However, forcing the user to choose between LDConfig.ldr
support and dither color support pretty much makes dither colors useless in
MLCad 3.3 for a vast majority of users.
| |
I feel with the majority of the votes in this thread. Allow “Dithered”
colours and looking forward for texture mapping!
|
That was my original opinion. However, all the initial posts in this thread
advocated RGB colors, so I was willing to support that. Now MLCad breaks
dither colors for at least 95% of its users, which seems to make them a
really bad idea.
--Travis
|
There seems to be support for RGB and also for “Dithered” colour out there.
The problem that we always faced are caused by applications that do not follow
our ideas and so we go limiting our aims.
I feel we should stop doing in that
way without to forget the limitations.
So I would suggest now (I had another
opinion before):
Allow “Dithered” colours.
Allow RGB colours
(both limited to pattern / sticker)
Limit the scope of colours in LDConfig.ldr only to brick colours.
For part authors it should be mentioned that “Dithered” colours will be shown by
all applications (except MLCAD 3.3) and that RGB Colours are only (at present)
supported by two applications.
My reason for this change:
Our main aim is to make picture from our models.
I think most of us uses LDView for this purpose. LDView is open source software
so everybody can contribute.
LDView shows just all of that.
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
I think eliminating part-specific subfiles would be a nice file-management
benefit, if nothing else.
|
I can see that, although a great deal of care would need to be taken to make
sure that the MPD sub-files had no chance of being useful in another part.
|
Sure, doing the right thing in terms of putting the code in the most
advantageous location is always worth the effort.
| |
| |
The most important benefit is that authors would be empowered to fully
exploit the potential of subfiles to speed up authoring, to reduce file
size, to reduce repetitive code.
Think about what software development would be like without
subroutines/functions/methods. You could kind of accomplish the same effect
by writing a number of different programs that all call each other, but it
wouldn’t be as powerful -- and in many cases, wouldn’t work at all. That’s
the kind of difference having MPD part files could have.
|
I totally disagree with this as an argument for MPDs. We already have the s/
directory for subfiles, and said subfiles (subroutines in your analogy) are
available for use by any other parts that want to use them. In your analogy,
MPD subfiles are private functions, and subfiles in s/ are public functions.
Both do have their place, but I’m still not convinced that private subfiles
wouldn’t cause more harm than good in the context of the parts library.
|
Hey, it’s all about namespace management, right?
As a parts author, I avoid using subfiles unless there is a fairly extreme need
for them (except for the case of subfiles created specifically to be used by
multiple part files). And that means that some approaches are skipped.
Here’s an example -- the part file for the crater baseplate, 3974.dat, weighs in
at 1Mb - really big for a part file. A few years ago, I figured out how to cut
it down to 600Kb, through a combination of different techniques. I never
published or submitted the results, because it required splitting the file into
22 subfiles. If I could use MPD, and contain those 22 subfiles within the main
part file, I would be all over this kind of optimization.(1)
Mechanical size reduction is not the major benefit of MPD parts. It’s just an
example I had handy. (OTOH, I can do 1024 studs in 30 lines of MPD code --
depending on the standards for comment lines. That’s a 97% compression, and
doesn’t affect the level of ZIP-style compression that can be performed.)
| |
One reason I think it is potentially bad to make subfiles private via MPD is
that even if the subfile is only used for geometry specific to a single part,
having it be private in an MPD makes it unusable for patterned versions of
that part.
|
Using a subfile to empower patterned part files means the subfile is not
specific to a single part. And why couldn’t subfiles be MPD? Maybe I’m not
getting your point here.
| |
And just because no patterned versions exist at the time that the
MPD part was created doesn’t mean that they won’t exist in the future.
|
At the time a part file is created, the author shouldn’t be expected to
anticipate future patterned versions (or any other versions). So the “it might
happen in the future” isn’t much of a point. Now, someone who makes the first
file for some part that *already* exists with patterned versions is a different
story.
If a future need comes up for sharing the code, then it would make sense to
refactor at that future time.
| |
I can see that MPDs would simplify the authoring of parts that benefit from
sub-files. However, I’m not sure that simplification counters the fact that
they hide said sub-files.
|
I hear you. But-- I don’t think there’s much reuse of subfiles between
dissimilar parts. And I’d expect that authors, when starting a new part, look
for existing similar parts, so they can share code. This is where refactoring
would occur.
Don’t get me wrong -- the real benefit from MPD for authors lies with creating
part files for complex parts, like train tracks and NXT bricks (which has
already been modeled with multiple subfiles). I’m not talking about 2x4
bricks.
Anyway, I think this rant is just about long enough.
Steve
1) This particular change would not benefit the renderer at all, just the
storage and transmission of the part file.
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> As a parts author, I avoid using subfiles unless there is a fairly extreme
> need for them (except for the case of subfiles created specifically to be
> used by multiple part files). And that means that some approaches are
> skipped.
>
> Here's an example -- the part file for the crater baseplate, 3974.dat, weighs
> in at 1Mb - really big for a part file. A few years ago, I figured out how to
> cut it down to 600Kb, through a combination of different techniques. I never
> published or submitted the results, because it required splitting the file
> into 22 subfiles. If I could use MPD, and contain those 22 subfiles within
> the main part file, I would be all over this kind of optimization.(1)
Hey, good point. Since we're on the topic of crater plates, I'd like to
use this part http://peeron.com/inv/parts/3947bpx1 to hijack this thread
and make an observation about part colors. As you can probably see from
the picture, the shark crater plate uses a printed stipple pattern to
produce the illusion of a fade from black to blue along the meandering
edge of the underwater river pattern. I don't think anyone in their right
mind would ever attempt to reproduce all of the stipple dots in ldraw
quads, so the only way left to do this in the current ldraw syntax is by
using many shades of color between black and blue. I'm not sure there are
enough in the 256-512 range to accomplish this, especially if we're gonna
re-purpose some of them for official brick colors.
I've seen lots of stippled fades in the recent printed parts and stickers,
so I suspect we'll eventually be forced to allow direct RGB values for
printed things, one way or another. Maybe the RGBs will be in these
newfangled texture thingies. I don't know.
Have fun,
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> Hey, good point. Since we're on the topic of crater plates, I'd like to
> use this part http://peeron.com/inv/parts/3947bpx1 to hijack this thread
... is it hijacking to put a thread back on topic? (even if the title is
changed, it's still the same thread, right?) ...
> and make an observation about part colors. As you can probably see from
> the picture, the shark crater plate uses a printed stipple pattern to
> produce the illusion of a fade from black to blue along the meandering
> edge of the underwater river pattern. I don't think anyone in their right
> mind would ever attempt to reproduce all of the stipple dots in ldraw
> quads, so the only way left to do this in the current ldraw syntax is by
> using many shades of color between black and blue. I'm not sure there are
> enough in the 256-512 range to accomplish this, especially if we're gonna
> re-purpose some of them for official brick colors.
>
> I've seen lots of stippled fades in the recent printed parts and stickers,
> so I suspect we'll eventually be forced to allow direct RGB values for
> printed things, one way or another. Maybe the RGBs will be in these
> newfangled texture thingies. I don't know.
Which is exactly why I brought up texture mapping. Solving gradients with
texture mapping makes a lot of sense, for the reasons you mention.
Steve
|
|
| |
As has been mentioned already in this thread, there is an ongoing effort to add
support for texture maps to the LDraw format via meta commands. What hasn’t
been mentioned is that the current LSC is basically in favor of ratifying
support for textures. We’re holding off on diving into that until we settle the
other color issues, but the fact that we expect it to happen is being kept in
our minds as we make decisions about colors.
I intentionally didn’t mention textures in my original post because we (the LSC)
wanted to see what the response would be without having mentioned textures. Of
course, a number (all?) of the responses were posted by people who were aware of
the texture work, which hasn’t exactly been secret.
So, given that textures will hopefully be ratified for use in official parts
some time within the next few months, does that change people’s opinion about
RGB vs. dither colors in parts? Please note that the texture commands will
include a provision for fallback geometry. So, even if someone running, say,
LDView were to see the texture maps, someone running, say, MLCad might not.
(Note, I’m not trying to pick on MLCad here, but I acknowledge that adding
texture support to a software renderer like MLCad has is a lot more effort than
adding texture support to a hardware renderer like LDView has.) And if the
textures aren’t supported, the fallback geometry has to be used instead.
Some existing high-quality patterned parts would benefit from textures for the
smooth gradients they enable. (One sample that’s already been done is the 2x2
tile with Star Wars Rebel pattern.) Some new patterned parts would probably
have minimalistic fallback geometry (just enough to identify what the pattern
is, but not really look good; the shark crater baseplate Don linked to would be
a good example of a pattern that likely never be modeled accurately as
geometry). Either way, the fallback geometry would still probably use RGB
colors, “dither” colors, or both, but it does change the equation.
Also, another option was brought up: explicitly allow both RGB and “dither”
colors in official parts.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> <snip> Since we're on the topic of crater plates, I'd like to
> use this part http://peeron.com/inv/parts/3947bpx1 to hijack this thread
> and make an observation about part colors. As you can probably see from
> the picture, the shark crater plate uses a printed stipple pattern to
> produce the illusion of a fade from black to blue along the meandering
> edge of the underwater river pattern. I don't think anyone in their right
> mind would ever attempt to reproduce all of the stipple dots in ldraw
> quads, [...]
No one in his right mind would do this baseplate without using texture mapping.
OK, Philo would, but I question that he's right in the head on a regular basis.
:)
Even so, the question would be, should one duplicate the nature of the stippling
pattern, or go the easier (and some might say, better looking) route of a
gradient in those areas?
-- joshuaD
|
|
| |
First of all, let me say that while my previous post probably implied that I’m
against allowing MPDs as parts, I am in fact still open to the possibility. I’m
just not sure I’m completely convinced by the arguments given so far.
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
One reason I think it is potentially bad to make subfiles private via MPD is
that even if the subfile is only used for geometry specific to a single
part, having it be private in an MPD makes it unusable for patterned
versions of that part.
|
Using a subfile to empower patterned part files means the subfile is not
specific to a single part. And why couldn’t subfiles be MPD? Maybe I’m not
getting your point here.
|
The only place you’re allowed to access the contents of an MPD are inside the
MPD itself. So, lets take the minifig head as an example. You wouldn’t be able
to put its “everything but the face region” subpart into an MPD, because the
only logical candidate for the MPD file is the top-level part. But if the
sub-part is in the MPD, it’s only available to that single top-level part.
Subfiles themselves could be MPD; you just can’t hide the subfiles used by
patterned parts in an MPD. Am I making more sense now?
--Travis
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> No one in his right mind would do this baseplate without using texture
> mapping.
>
> Even so, the question would be, should one duplicate the nature of the
> stippling pattern, or go the easier (and some might say, better looking)
> route of a gradient in those areas?
Well, since the stippling pattern is just an artifact of the printing
process, I'd say it's foolish to reproduce it. Some of the dots on the
newer stippled gradients are so tiny I can't even see them without a huge
magnifier (or maybe I just need bifocals) so it makes absolutely no sense
to reproduce the dots.
Anyhow, if we're gonna allow the full gamut for Textures, why not allow
it for the fallback vector patterns. It hardly seem fair for you young
whipper-snappers with all your fancy new hardware to lord it over us
mere mortals getting by with the lesser equipment. ;) If I can't have
LDraw with textures on my android phoneputer, I still want it to look
pretty good.
Just whip up some official guidelines for the patterns, like say:
if it looks like the printed pattern uses official colors then use the
numbered colors. Otherwise feel free to use the RBG colors.
Works for me...
Don
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
> Be sure to take a look at Joshua's texture mapping primer/exposition on
> Facebook:
>
> http://www.facebook.com/album.php?aid=2048041&id=1532162912&l=4199f78c01
>
> It's good stuff, and could have very good benefits to LDraw.
Yeah, I checked it out the first time it was mentioned. I even poked
around in the LDView CVS archives for a few minutes looking for hints
of the magic syntax before the Walled Garden stuff got posted. Looks
very promising! I guess I'm finally gonna have to crack open that
OpenGL Shading Language book gathering dust bunnies in the corner if
I want to keep the lowest common denominator LDraw editor up to snuff.
Well, maybe slightly below the good snuff...
I do actually have a facebook account and would've asked a few questions
about the syntax, but I have trouble with the facebook interface. It
confuses me, like trying to converse in a large chatty crowd. Plus I
figure I'm most likely part of the problem here at lugnet. Asking so
many questions, slowing down the rate of progress, and all that.
Have fun,
Don
|
|
| |
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> > No one in his right mind would do this baseplate without using texture
> > mapping.
> >
> > Even so, the question would be, should one duplicate the nature of the
> > stippling pattern, or go the easier (and some might say, better looking)
> > route of a gradient in those areas?
In lugnet.cad.dat.parts, Don Heyse wrote:> Well, since the stippling pattern is
just an artifact of the printing
> process, I'd say it's foolish to reproduce it. Some of the dots on the
> newer stippled gradients are so tiny I can't even see them without a huge
> magnifier (or maybe I just need bifocals) so it makes absolutely no sense
> to reproduce the dots.
Interesting. Not the response I was expecting. :)
Back when I was building the first gradient example for the texture mapping
proof
http://www.facebook.com/photo.php?pid=30700113&l=4fdc180c94&id=1532162912
(this was the feature that won over Philo), I used my scanner to scan the image
I needed. In 30 seconds I had a mockup that was nearly as good as the real
thing, IF you didn't need the base color to show through.
[BTW, if you're asking yourself "does that pattern REALLY fade into the
background? Travis asked that too. Use "Next" to see the same item in green]
Then I spent ... I dunno, an hour tops? ... redoing the image in Adobe
Illustrator over the top of the image.
While the stipple dots ARE noticeable with the naked eye, it was the scanning
process that really made them stand out, and I was trying to decide whether they
should stay.
I haven't looked closely at the Aquazone baseplate in a bit, but I thought the
dots were QUITE visible, almost a feature?
I was worried with first cut of the dish I'm linking, because the dots weren't
visible. Would I have complaints it looked "too good?"
This IS the group who argued whether the ice cream sign on a brick should be
drawn "ideally", or offset and corrupted, as every known printed version seemed
to be "out in the wild", after all. :-P
> Anyhow, if we're gonna allow the full gamut for Textures, why not allow
> it for the fallback vector patterns. It hardly seem fair for you young
> whipper-snappers with all your fancy new hardware to lord it over us
> mere mortals getting by with the lesser equipment. ;) If I can't have
> LDraw with textures on my android phoneputer, I still want it to look
> pretty good.
I just did a quick check: The Android supports OpenGL ES. Even the lowliest 1.0
OpenGL ES supports texture mapping (and later versions get fancy in a hurry).
We're not trying to shoot for the moon on our first try here.
Heck, I've even seen software texture mapping routines. This isn't one of those
H/W Transform and Lighting features that didn't exist before hardware, after
all.
I'm certain not a young'n, either. I've struggled with some pretty paltry
hardware over the years. Heck, I used BriCAD and thought that was THE COOLEST
THING EVER (a recent resurrection of that code did NOT live up to expectations).
But the most minimal of systems now come with quite capable graphics. I can say
that because I was witness to Tore getting a system (on the cheap) that does
some nice stuff right out of the box.
<snip>
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> Yeah, I checked it out the first time it was mentioned. I even poked
> around in the LDView CVS archives for a few minutes looking for hints
> of the magic syntax before the Walled Garden stuff got posted. Looks
> very promising! I guess I'm finally gonna have to crack open that
> OpenGL Shading Language book gathering dust bunnies in the corner if
> I want to keep the lowest common denominator LDraw editor up to snuff.
> Well, maybe slightly below the good snuff...
I like your thinking! :)
But Shader Language programming is really more along the lines of what we'll
need for the next step I'd like to see: gloss maps. Those will allow shiny
paint on torsos (for instance) to shine in the light, making gold, silver, and
copper shiny parts do their proper thing.
Far advanced, and not necessary for the current round of improvements.
TEXMAP is OpenGL 101 level, pure and simple.
> I do actually have a facebook account and would've asked a few questions
> about the syntax, but I have trouble with the facebook interface. It
> confuses me, like trying to converse in a large chatty crowd. Plus I
> figure I'm most likely part of the problem here at lugnet. Asking so
> many questions, slowing down the rate of progress, and all that.
Questions got the syntax to a workable state. I actually developed another
syntax extension (still not released or under consideration, requires
large-scale -- but minor -- changes to a large portion of the library, best left
otherwise unmentioned here), so I had SOME experience with improving LDRAW
without breaking it; but we had a full-fledged proof of just about every major
decorated part of LEGO, and many minor ones, plus gradients and other
alpha-channel tricks, and we thought we were ready to roll. It took questions
from Travis and Leonardo Zide to get us to rethinking some of our approach and
even adjust it to get the syntax that's ready to be beat on at this point. And
even though those feel nicely cooked, I bet there's still a "gotcha!" or two out
there waiting to be discovered...
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
The only place you’re allowed to access the contents of an MPD are inside the
MPD itself. So, lets take the minifig head as an example. You wouldn’t be
able to put its “everything but the face region” subpart into an MPD, because
the only logical candidate for the MPD file is the top-level part. But if
the sub-part is in the MPD, it’s only available to that single top-level
part. Subfiles themselves could be MPD; you just can’t hide the subfiles used
by patterned parts in an MPD. Am I making more sense now?
|
Absolutely.
I wasn’t advocating sticking ‘public’ subparts into the part’s MPD. Just to be
clear.
Steve
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> > Anyhow, if we're gonna allow the full gamut for Textures, why not allow
> > it for the fallback vector patterns. It hardly seem fair for you young
> > whipper-snappers with all your fancy new hardware to lord it over us
> > mere mortals getting by with the lesser equipment. ;) If I can't have
> > LDraw with textures on my android phoneputer, I still want it to look
> > pretty good.
>
> I just did a quick check: The Android supports OpenGL ES. Even the
> lowliest 1.0 OpenGL ES supports texture mapping (and later versions
> get fancy in a hurry). We're not trying to shoot for the moon on our
> first try here.
Yeah, I know what's available at the low end of OpenGl. That's where I
live. I was just trying to keep up the curmudgeonly atmosphere of this
place with the whipper-snapper comment. Did I do it wrong?
Oh well, at least there's still that gloss map business to give me an
excuse to crack open the Shading Language book.
Thanks for that,
Don
|
|
| |
In lugnet.cad.dat.parts, Steve Bliss wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
The only place you’re allowed to access the contents of an MPD are inside
the MPD itself. So, lets take the minifig head as an example. You wouldn’t
be able to put its “everything but the face region” subpart into an MPD,
because the only logical candidate for the MPD file is the top-level part.
But if the sub-part is in the MPD, it’s only available to that single
top-level part. Subfiles themselves could be MPD; you just can’t hide the
subfiles used by patterned parts in an MPD. Am I making more sense now?
|
Absolutely.
I wasn’t advocating sticking ‘public’ subparts into the part’s MPD. Just to
be clear.
|
You know, it occurs to me that if MPD’s were allowed as parts, it would be a
GREAT place to put a texture file (properly hex encoded, no doubt). They’re
almost always single-part-only.
And if one wanted better textures than “come standard?” Upgrade the
viewers/editors to search the LDRAW path for a better version, much as they
might hi-res primitives to replace in parts.
This would lower one of the “pain points” of going to texture mapping.
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
First of all, let me say that while my previous post probably implied that
I’m against allowing MPDs as parts, I am in fact still open to the
possibility. I’m just not sure I’m completely convinced by the arguments
given so far.
|
I think this is a good one:
MPD parts would be a great way to store “default” textures for texture mapping
(hex encode them). That would encapsulate the design with the part, overcoming
one of the big “pain points” of adopting textures. Textures could still be
overridden in supporting software through use of an external “hi-res” directory
in the LDRAW search path.
I CAN think of a few issues (but why announce THOSE, right? :)), but it’s
another aspect that might make the idea an acceptable one.
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
First of all, let me say that while my previous post probably implied that
I’m against allowing MPDs as parts, I am in fact still open to the
possibility. I’m just not sure I’m completely convinced by the arguments
given so far.
|
I think this is a good one:
MPD parts would be a great way to store “default” textures for texture
mapping (hex encode them). That would encapsulate the design with the part,
overcoming one of the big “pain points” of adopting textures. Textures could
still be overridden in supporting software through use of an external
“hi-res” directory in the LDRAW search path.
|
I really don’t like this idea. I agree that it has the cool property of
encapsulating everything in one file, but it has three big problems that I can
think of off the top of my head:
- “Hex” encoding of the texture file increases its size by a little over a factor of two. (Two bytes per original byte, plus <CR><LF> at the end of each line and at least 0 <space> at the beginning of each line.) This could be improved by using something like base 64, but that increases the complexity.
- The textures become hidden, and new tools are needed to import them into the part files and extract them back out again.
- The files become a pain to edit, because 90%+ of the file is made of of encoded texture data.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
I really don’t like this idea. I agree that it has the cool property of
encapsulating everything in one file, but it has three big problems that I
can think of off the top of my head:
|
Yeah, what he said.
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
| |
| |
First of all, let me say that while my previous post probably implied that
I’m against allowing MPDs as parts, I am in fact still open to the
possibility. I’m just not sure I’m completely convinced by the arguments
given so far.
|
|
|
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
| |
| |
I think this is a good one:
MPD parts would be a great way to store “default” textures for texture
mapping (hex encode them). That would encapsulate the design with the part,
overcoming one of the big “pain points” of adopting textures. Textures
could still be overridden in supporting software through use of an external
“hi-res” directory in the LDRAW search path.
|
|
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
I really don’t like this idea. I agree that it has the cool property of
encapsulating everything in one file, but it has three big problems that I
can think of off the top of my head:
- “Hex” encoding of the texture file increases its size by a little over a factor of two. (Two bytes per original byte, plus <CR><LF> at the end of each line and at least 0 <space> at the beginning of each line.) This could be improved by using something like base 64, but that increases the complexity.
|
I was actually thinking “uuencode” when I wrote this, and used hex for shorthand
and because I figured it was more universally understood. But I think this
veers slightly off-topic (file size bloat versus utility of feature) -- see
below.
| |
- The textures become hidden, and new tools are needed to import them into the part files and extract them back out again.
|
Textures (especially a “default” texture) will tend to be the kind of thing that
won’t change much. This isn’t a “plug and play” feature. It’s somewhat fixed
(and I mentioned a mechanism to override that doesn’t require extraction or
change)
| |
- The files become a pain to edit, because 90%+ of the file is made of of encoded texture data.
|
If you were to go to MPD parts, they’d become a pain to edit, period. Sections
and references that have to be kept in sync and proper order.
Do you fix this with “won’t do it, too hard for people to hand edit”, or do you
fix this with better tools? MPD parts would, to me it seems, require improved
tools (that handle the side work) on the face of it.
---
IMHO, you argued whether you’d like hex bloat from textures in your parts
library. That’s a different discussion from whether embedding textures with the
parts they map would be an applicable use of MPD part files.
I’ve found that it’s best NOT to design (or un-design) a feature based on how I
think *I’d* use it, but rather whether it would have strong universal appeal and
use. And even then, the market ultimately dictates whether a feature was worth
the trouble. If it wasn’t, then no harm-no foul, if it was, you work to improve
the feature to improve the product.
-- joshuaD
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
This is really interesting work. Just curious, but have you considered how
you’d implement bump mapping as well? (Bump mapping would allow the “rough”
texture on slopes, for instance. I think that would be the only application for
it, but there are patterned slopes, so they would need both a texture and a bump
map.)
|
|
| |
In lugnet.cad.dat.parts, Andrew Westrate wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > <http://www.facebook.com/album.php?aid=2048041&id=1532162912&l=4199f78c01>
>
>
> This is really interesting work. Just curious, but have you considered how
> you'd implement bump mapping as well? (Bump mapping would allow the "rough"
> texture on slopes, for instance. I think that would be the only application
> for it, but there are patterned slopes, so they would need both a texture and
> a bump map.)
If I'm not mistaken, two big pushes were made for texture mapping, in 2004 and
2007. Both failed because of too much committee, too little action. This after
previous attempts were made, of course, but looking at LUGNET, that's when the
big attempts were made to organize and get going.
We (a non-ALE software engineer buddy and I) have actually had texture mapping
working as a proof for one-and-a-half to two years! Before that was done, he
tried writing an application that took a bitmap (of arbitrary resolution) and
created triangles and quads from fields of color within it -- basically what a
part author does when he creates what I term "design by architecture" --
creating the design using the primitives of a mesh; which is how all part
patterns up to now have been done (albeit by hand). [side note that everyone we
showed it to HATED it -- the files bloated quite a bit, and the quality just
wasn't good enough to make it work]
The texture mapping proof that followed sat around for 6 months as I tried to
generate interest; interest that really didn't flower when the demo consisted
more of simply explaining how it could work, and how it should work.
It wasn't until I actually created the right sample texture, using gradients and
alpha channel (stuff that had always been possible, but explaining and showing
are two different things), and showed that working, that a major part author and
a major application writer got on board.
Change comes to LDRAW, but it happens very slowly. I worked with James, I worked
with Terry, I worked with Steve, and I worked with Chris. I have the plans to
go much, much further. When Turbo Pascal and EGA graphics were the norm, LDRAW
was impressive. Now that hardware transform and lighting [which is capability
ranked far beyond the needs of simple texture mapping] are nearly de rigeur, we
seem finally ready for texture mapping. It's a slow process.
I'm loathe to promise ANYTHING considering how long it's taken to get us this
far.
As the texture mapping proof sat in wait, I heard the same thing: time and
again: "MLCAD won't be able to do this; it doesn't use OpenGL, it doesn't use
graphics hardware. No one will adopt this without that." Indeed, that issue
exists.
I finally got over the hump [of convincing people that texture mapping was
"it"], and I said I wanted gloss maps, and I've been told it's not that useful,
that kind of hardware isn't available everywhere, it'll never work.
Well, we'll see. We reserved the tokens in the "language" for texture mapping
to define it, it really won't be that hard, it just takes the first person to
implement the shader language to make it happen.
My understanding of bump mapping is SLIGHTLY fuzzy (I'm not sure whether it fits
into the realm of multi-texturing, or fully in custom shaders), but I feel
FAIRLY confident enough to call that sort of invention an evolution of this
process, rather than a revolution.
Will bump mapping come to LDRAW (or at least LCAD?)?
Well, let's just say I've been paying an awful lot of attention (and drooling)
over the animation found here:
http://technic.lego.com/en-us/Products/default.aspx#8048
(click the yellow (Animation) link, wait for the zoom in on the motor). I think
that animation represents the rubber hitting the road :wink: <pause for
groaning>, and that we'll be able to do that with LCAD tools some day, without a
doubt.
Would that it not take another 15 years :)
-- joshuaD
P.S. put more succinctly, as people see the value in texture mapping, and ask
how they ever did without it, much more will be possible. Getting to where we
are now was an application of existing tools, it wasn't rocket science.
Incrementally improving it can and will happen. And I've obviously had both
gloss maps and bump maps on my mind as we've gone.
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
>
> Will bump mapping come to LDRAW (or at least LCAD?)?
I was under the impression that LDView already uses bump mapping for
the stud logos. Is that wrong?
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > Will bump mapping come to LDRAW (or at least LCAD?)?
>
> I was under the impression that LDView already uses bump mapping for
> the stud logos. Is that wrong?
But that's different from parts authors being able to use bump mapping in a part
file. Or specific colors actually being implemented as bumps/textures -- so
'rubber black' actually looks distinct from 'black'.
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > Will bump mapping come to LDRAW (or at least LCAD?)?
>
> I was under the impression that LDView already uses bump mapping for
> the stud logos. Is that wrong?
Texture maps let us wrap images to polygons. This is great for painted images
on surfaces, such as mini-figure torsos or the sides of walls.
Bump maps describe how each point (texel) in the texture reacts to light, by
describing a virtual "height" to that point. Then when light sources change, the
texture "reacts" more convincingly. This is good for things like orange peel,
rubber, or the textured surfaces we (used to) get with sloping bricks.
There are even more advanced techniques than bump mapping, all of which simulate
an actual texture that can be seen "on edge", reacts to light, and so on, from
normal mapping all the way up to displacement mapping. The cooler the effect,
the more powerful the hardware you need to show it, but the more convincing the
images.
Gloss maps, which I advocate coming into the picture eventually, indicate which
points on a texture reflect light in a specular fashion. This will be good for
gold, silver, and copper paints on patterns that use those paints. The parts of
the pattern that are gold or silver or copper will be "shiny", while the rest
won't. Then, when a part is displayed in a changing environment (like spinning
in LDView, though there are more useful examples too, IMO), the light will shine
off the shiny parts as the object moves in front of light sources.
As for the TEXMAP syntax, we "reserved" space for indicating a gloss map, and
the same can be done for other types of maps as well. Right now, one could do:
0 !TEXMAP START PLANAR 0 0 0 1 1 1 2 2 2 <texture-filename> GLOSSMAP
<glossmap-filename>
* currently GLOSSMAP doesn't actually do anything in any supporting application,
but is planned for future expansion *
It would be very simple to add additional keywords to the !TEXMAP START command
for bump maps, normal maps, even displacement maps.
Implementing these things wouldn't even be all THAT difficult. The points that
are actually at issue are these:
* How widespread is your target audience's "decent" hardware capability?
This is becoming less and less of an issue. Even "entry level" graphics cards
now sport Hardware T&L (transform and lighting) quite capable of the mid-level
(bump-mapping, normal-mapping) features I'm talking about at a really decent
speed. And that's with video games at 30 frames per second and millions of
polygons. LDRAW just isn't that kind of application, ESPECIALLY the number of
objects that need to be textured.
* What condition and quality is your input data in?
I really think this is where we'll need some ramp up. Who has the technical
know-how to get us professional quality textures (and I mean that in the generic
sense -- image, bump, gloss, normals, etc., the whole package) that will produce
top results in the viewers? To me, this is the real challenge. We can get
viewers that show these features with a little bit of R&D (it comes down to
reading up on a technique online and then tweaking the code to fit your input
data; once that's done, it's more work but not insurmountable to make the new
features work with older features in existing renderers).
The hard part is getting all the proper input data prepared so it looks right
and works to everyone's satisfaction.
Check out the date on this proof I did:
http://www.facebook.com/photo.php?pid=30693110&l=94b60efd85&id=1532162912
(I did the back of the torso]
http://www.facebook.com/photo.php?pid=30691970&l=f1243ed558&id=1532162912
That's a 2010 torso and legs, back in November, 2009. It was possible simply
using my scanner and the TEXMAP technology. But does it look pro? To be sure,
to have the figure ready-to-roll 40 minutes after opening the set is a
mind-blower, but long-term, that imagery needs to be redone in
Illustrator->Photoshop to have a really sharp and pro look.
----
This Pirate guy was done in the same way:
http://www.facebook.com/photo.php?pid=30698924&l=ec37e856ea&id=1532162912
(he needs gloss maps, so the gold medallion on his chest, and the buckles on the
bag on his back, will shine properly)
The expertise to get them to the level of attention I gave Indy here:
http://www.facebook.com/album.php?aid=2040316&id=1532162912&l=c7b84a178a
is what will be the challenge (and I'm talking consistency and dedication over
quality -- I'm not perfect at this stuff by any means).
-- joshuaD
LUGNET member #3
P.S. Don, I've had someone suggest that I "encourage" support of this syntax in
LDGlite. Are you up for it? Already working on it?
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> >
> > Will bump mapping come to LDRAW (or at least LCAD?)?
>
> I was under the impression that LDView already uses bump mapping for
> the stud logos. Is that wrong?
As it happens, the stud logos in LDView are just regular textures.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Don Heyse wrote:
> > In lugnet.cad.dat.parts, Joshua Delahunty wrote:
> > >
> > > Will bump mapping come to LDRAW (or at least LCAD?)?
> >
> > I was under the impression that LDView already uses bump mapping for
> > the stud logos. Is that wrong?
>
> As it happens, the stud logos in LDView are just regular textures.
Wow, what a let down! I'm totally disappointed (with my apparently failing
memory, not with you or LDView. Well, ok, maybe I'm just a teeny bit less
impressed with LDView right now, but I'll get over it. :)
Have fun,
Don
|
|
| |
In lugnet.cad.dat.parts, Joshua Delahunty wrote:
>
> P.S. Don, I've had someone suggest that I "encourage" support of this
> syntax in LDGlite. Are you up for it? Already working on it?
I've been tossing this around for a while, and while I'm not sure who'd
really use it in ldglite considering LDView is so much better suited for
modern OpenGL use, it still seems like it'd be fun to experiment with.
So, are there any example files available with the modified .dats and the
.png texture files? Something like this one might be a good start because
then I could compare the texture and the fallback .dat vector rendering.
http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> So, are there any example files available with the modified .dats and the
> .png texture files? Something like this one might be a good start because
> then I could compare the texture and the fallback .dat vector rendering.
>
> http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
You can find some sample files here:
http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
Note that some of the files may have BFC issues. Look at 973pa9.dat for a file
that has fallback geometry. As a side note, rebel_tile.dat (and the part it
points to) have bad texture coordinates, so the texture is mirrored.
--Travis
|
|
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Don Heyse wrote:
> > So, are there any example files available with the modified .dats and the
> > .png texture files? Something like this one might be a good start because
> > then I could compare the texture and the fallback .dat vector rendering.
> >
> > http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
>
> You can find some sample files here:
>
> http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
Thanks, that was quick.
By the way, I'm still not sure whether it's really worth it to attempt
this in ldglite, or if it'd be more worthwhile to try something that
might actually end up being useful, like say a minifig modeler (or maybe
an lsynth GUI) built around LDVlib.dll. Can it process new geometry
fast enough to form the nucleus of a general LDraw editor, with parts
moving around in real time?
Don
|
|
| |
In lugnet.cad.dat.parts, Don Heyse wrote:
> In lugnet.cad.dat.parts, Travis Cobbs wrote:
> > In lugnet.cad.dat.parts, Don Heyse wrote:
> > > So, are there any example files available with the modified .dats and the
> > > .png texture files? Something like this one might be a good start because
> > > then I could compare the texture and the fallback .dat vector rendering.
> > >
> > > http://www.facebook.com/photo.php?pid=30701291&id=1532162912&l=c7b84a178a
> >
> > You can find some sample files here:
> >
> > http://www.halibut.com/~tcobbs/ldraw/private/texmapped.zip
>
> Thanks, that was quick.
>
> By the way, I'm still not sure whether it's really worth it to attempt
> this in ldglite, or if it'd be more worthwhile to try something that
> might actually end up being useful, like say a minifig modeler (or maybe
> an lsynth GUI) built around LDVlib.dll. Can it process new geometry
> fast enough to form the nucleus of a general LDraw editor, with parts
> moving around in real time?
LDVLib doesn't allow you to edit models at all. You point it at an existing
file and tell it to load. Having said that, if you wanted to do some (most?) of
the work, it could probably be made to be usable for a minifig modeler, since
high-performance isn't really an issue with a minifig.
I'd have to tweak the graphics engine side of LDView to have an "edit" mode, and
you'd have to create the C API inside LDVLib to handle editing. You're not the
first person to request editing in LDVLib, but I don't really see myself doing
all the work.
--Travis
|
|
|
