Subject:
|
Re: Using MPD syntax in official part files
|
Newsgroups:
|
lugnet.cad.dat.parts
|
Date:
|
Thu, 11 Feb 2010 18:28:23 GMT
|
Viewed:
|
19431 times
|
| |
|
|
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
|
|
Message is in Reply To:
 | | Re: Using MPD syntax in official part files
|
| (...) 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 (...) (15 years ago, 11-Feb-10, to lugnet.cad.dat.parts, FTX)
|
68 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
