Subject:
|
Re: Using MPD syntax in official part files
|
Newsgroups:
|
lugnet.cad.dat.parts
|
Date:
|
Wed, 10 Feb 2010 21:42:39 GMT
|
Viewed:
|
18340 times
|
| |
|
|
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.
|
|
Message has 2 Replies:
 | | Re: Using MPD syntax in official part files
|
| (...) Hey, good point. Since we're on the topic of crater plates, I'd like to use this part (URL) 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 (...) (15 years ago, 10-Feb-10, to lugnet.cad.dat.parts)
| | | Re: Using MPD syntax in official part files
|
| 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. (...) The only place (...) (15 years ago, 10-Feb-10, to lugnet.cad.dat.parts, FTX)
|
Message is in Reply To:
| | Re: Using MPD syntax in official part files
|
| (...) 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 can definitely see that. (...) I totally disagree with this as an argument for (...) (15 years ago, 10-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
