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