 | | | | | |
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
| | | | | | | | | | | | | | | | | | | | | | | | | | |
And again, I forgot to include a bit. And second-posting about something very
cool!
Don,
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.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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, 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, 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
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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, 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, 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
| | | | | | | | | | | | | | | | | |
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, 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, 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
| | | | | | |
