Subject:
|
LDraw part library structure
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 14 Apr 1999 10:33:54 GMT
|
Viewed:
|
885 times
|
| |
|
|
The shape of things to come.........
I have been remiss in posting this. Dang combination of tax-season and my
rampant procrastination. :-)
Anyway, thanks to Joshua Delahunty and his solution for the file-naming of
composite elements, the general plan of organization of categories and naming
of parts has been finalized.
OK, here is the plan in a nutshell:
[All the summaries below are generally true, but not "ironclad".
Exceptions to these "rules" *MIGHT* occasionally be necessary.]
[Most of the following is a rehash summary of previously established structure.
The one new key point is the filenames for #16 color composites]
---- xxx.dat ----
files with 3-digit numbers are considered "temporary".
If we don't know the number, the part will get a 3-digit number (and,
occasionally, 2-digit numbers until those run out).
If we find the "official" number, the part will be updated to match.
3-digit numbers are used only for single-item elements.
These parts will generally use color-code #16.
If/when we "run out" of 3-digit numbers, a suitable substitute will be devised.
---- xxxx.dat & xxxxx.dat ----
The "official" codes.
4-digit codes.
Generally, a part with a 4-digit number is the "official" number.
These parts are usually a single-item element, and usually are in #16 color.
They use #16 because most of these codes refer only to the element, not its
color.
5-digit codes.
These come in different ranges;
The 3xxxx.dat range usually are the equivalent of the 4-digit range.
The 7xxxx.dat range usually reference specific colors and/or finishes and/or
composite elements (elements made of two or more pieces).
The 8xxxx.dat range usually reference a specific color and/or pattern.
Most of the parts added under 7xxxx and 8xxxx codes will be "shortcut" files
that build upon the basic #16 color parts available under 3-,4-, or 5-digit
codes.
There are also some number codes that are longer. These long codes also refer
to very specific element colors/patterns/composites, and will be made and
applied the same way as the 7xxxx and 8xxxx range parts.
The adding of parts having specific colors and/or patterns hard-coded into the
part will be dependant upon knowing the "official" number to match.
That is, we will not add a hard-coded element unless we know its "official"
number. The goal here is accuracy in both number and color/pattern/finish.
And to quell any potential alarmists: we are not going to add colored versions
of all the basic parts now existing. Those parts have "official" number codes
that do not refer to any particular color. Those numbers refer only to its
shape.
---- xxxxPyy.dat ----
This is for Patterned parts that use the #16 color-code.
This could also be xxxPyy.dat and xxxxxPyy.dat.
These are for ease and flexibility in modeling. Allowing users to use
patterned parts even in non-existent colors.
---- xxxxCyy.dat ----
This is the new one.
Parts named using this system will be "Composite" parts using the #16
color-code. "Composite" being two or more parts normally joined together in
real life.
These are also for intended for modeling. We need these because most composite
elements do not have their "official" number molded on. And on those that do
have a molded number, that number refers to the subpart into which it is
molded, not the entire assembly.
The idea is to use that molded-in number that is most visible, BUT also add the
additional "Cyy" to the end. This will be somewhat more intuitive that using a
completely random number. And at the same time *clearly* denote that the part
is a #16 color composite.
But what if the composite element has no number molded into it at all?
Simple. We assign a 3-digit number using the xxxCyy.dat format.
Of course, we try to limit that as much as possible.
This, essentially, is the same thing as the Patterned parts using xxxxPyy.dat.
Using this system will give modelers the flexibility of using #16 color
composite parts, even if they don't actually exist in real life.
---- An example ----
The yellow dinghy.
Under this system, the dinghy would consist of four files:
30086.dat The dinghy bottom half, in #16 color
30087.dat The dinghy top half, in #16 color
4106548.dat The "official" number for a composite dinghy
in Yellow. This would be a shortcut of 30086
& 30087 with a #14 color code applied.
30086C01.dat The composite dinghy in #16 code. Again, as a
shortcut of the two basic files.
Another example:
104.dat The Antenna 6H in #16 color
71185.dat The Antenna 6H Chrome in color #383 (#383 is right, right?)
-----------------------------------------------------------------------
Along with the filename changes there are descriptions that complement them.
Right now, there are two basic description "types" in the ldraw\parts
directory. Those that begin with standard category names such as:
Antenna
Minifig
Wing
And those that begin with the tilde charactor "~". This is used to segregate
these parts from the standard ones. These parts may be "pointer" files:
~Moved To
Or they may be subparts of another part:
~Minifig Torso No Front
~2421 wing
Also notable is that some of the "composite" parts will have there constituent
pieces described with the "~". The dinghy is a good example to use here.
In real life, people do not have the dinghy as two separate pieces. So in
LDraw, those two pieces will have a "~" preceding their descriptions. That will
keep the two pieces "out of site" - they will be there, but not readily
noticeable.
Most users will not have any use for the pieces separately. Most will use the
#16 30086C01.dat or the yellow 4106548.dat.
On the other hand, if a composite piece *does* have a valid modeling use, its
constituent pieces will be placed into a standard category.
A good example of that is the 9244.dat Technic Universal Joint.
Originally, the two pieces of this element were "hidden" with the tilde
character. But in modeling, we needed to have those two pieces available in a
standard category, so the tilde was removed from their descriptions.
This created two "standard" pieces to use as needed.
Obviously, each composite element, and its constituent pieces, will need to be
considered separately as to how it is to be handled.
Now, a third "type" will be added. This is the Underscore Category type. It
will look like the standard categories, but with an underscore character
immediately preceding it:
_Antenna
_Minifig
and so on...
Pieces in these new category types will be the "0fficial" numbered parts that
have specific characteristics hard-coded into them. Such as color and/or
pattern.
In the examples used above, the 71185 would be described as:
_Antenna 6H Chrome - thus placing it into the _Antenna category.
Likewise the 4106548 would be in the the _Boat category.
This method will keep "standard" modeling pieces - in #16 color - separate from
the "reference" hard-coded color pieces. Important when considering the size
that some categories will be.
It also allows users of modeling programs like LDAO to not view these
categories. This can be done by the same method now used to not view the "~"
type category - a simple edit of the programs .ini file.
Of course, if one wishes to see and use these new pieces in models, that is
fine. But doing it this way gives users the *choice* to do it either way.
------------------------------------------------------------------------
Whew! My "summaries" are started to resemble Todd's. :-)
But seriously, I would like to express my thanks to Joshua Delahunty for all
his brainstorming and hard work on formulating these standards. His ideas for
using underscore categories and the xxxxCyy formatting for composites was
pivotal. Although initially, I had my doubts.
Ultimately, Joshua was right of course, and I thank him for being so patient
when I was so adamantly dense.
In my own defense, I sometimes seem to have problems with seeing forests
through all those dang trees. :-)
He also impressed upon me the importance of using "shortcut" files when
creating composites and hard-colored parts. Doing so not only simplifies the
creation of those parts, but ensures the improvements made to the basic parts
are propagated thru all the shortcuts that use them.
And I would also like to thank Steve Bliss for his opinions and inputs through
all this. Steve and Joshua were pretty much at polar opposites on just about
every subject in this debate. But somehow we all managed to finally give a
little here and there and compromise out a solution. Pretty tough going at
times, with me in the middle, vacillating between sides.
(fence sitting is my speciality)
And Kudos to Steve and to Anders Isaksson for promptly making modifications of
LDAO and LDList (respectively) to better handle the underscore categories.
In fact, they made the changes in record time. Wow.
And thanks to everyone who supported this, directly and indirectly. You know
who you are. :-)
So that's it. That is how we will be implementing the addition of hard-coded
parts with official numbers. Overall it is a simple, elegant method which
builds and complements upon the previous structure.
Time to shut up now.
-- Terry K --
|
|
Message has 2 Replies:
 | | Re: LDraw part library structure
|
| (...) You're welcome, Terry. A labor of love, it was. <big snip> (...) Don't even worry about this, Terry. Either we're going to have a 5-digit code for the entire assembly that we can use, or we're going to know the 4-digit codes even if they're (...) (26 years ago, 15-Apr-99, to lugnet.cad.dev)
| | | Re: LDraw part library structure
|
| Terry K (legoverse@geocities.com) wrote a long but clear description of how part numbering and naming is going to be in the future. Good plan! Clear description! [...] (...) Yup! Thanks to Joshua, Steve, and Terry for working this out. Play well, (...) (26 years ago, 15-Apr-99, to lugnet.cad.dev)
|
10 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
