Wheel+Tyre Shortcuts: to have or not to have?
2012-05-13, 10:29 (This post was last modified: 2012-08-25, 20:50 by Michael Heidemann.)
2012-05-13, 10:29 (This post was last modified: 2012-08-25, 20:50 by Michael Heidemann.)
I have just recently added some Wheel+Tyre Assembly Shortcuts to the PT.
http://www.ldraw.org/cgi-bin/ptdetail.cg...482c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...482c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...996c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...695c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...245c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...715c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...039c01.dat
and
http://www.ldraw.org/cgi-bin/ptdetail.cg...27ac01.dat
, which has sparked this discussion:
Magnus questions if having these makes sense.
I'd like to answer that question with my reasoning here.
The reason behind creating these shortcuts was that when building models,
I again and again found myself in 2 actions:
(a) searching the matching tyre for a wheel (because in MLCad all parts get scaled in the parts library preview, so all wheels and tyres look the same size)
(b) after I had found them, I to each model added a "wheel+tyre" assembly submodel
After having done this some times, I was asking myself why the assembly of (b)
was not part of the library.
Of course, the answer is: avoid clutter. As some wheels can carry different tyres, a combinatoric explosion
might occur. This prevented me some time from creating these shortcuts.
I then discovered that e.g. SR3DBuilder contains a separate database for this purpose: "TireManager.txt" (see attachment).
It is a simple text file which lists wheels plus their matching tyres.
When I saw that, I felt reminded of the discussion about 2 other things:
(i) alias part numbers
(ii) physical color shortcuts
There, the discussion was just the same: should we track this data somewhere?
The discussion about these 2 mainly went like this at those times:
First, an agreement was achieved that this information is quite valuable and needs to be stored somewhere.
The initial idea then was to have a separate database.
It then turned out that that separate database was nothing else than simple redirections
of part number to other part numbers, or of part numbers plus a certain color to other part numbers.
Then the question arose why we would create all the effort to maintain tooling etc. for a separate database,
when the existing mechanisms (i.e., LDRAW lines of type "1", part usage) would do everything we need.
Voila, a prefix was added to easily distinguish these files, and later, even an !LDRAW_ORG header type was added
(which I consider even better), and that was it. I find this solution very elegant, as it is self-contained and does
not add a secondary database.
When I remembered that, I felt that at least for the "usual" wheel+tyre assemblies, i.e., such that occur
in official LEGO models, we should have these shortcuts, basically for the same reasoning:
there is only a limited number of combinations possible, and that number is not too high:
SR3DBuilder's text file for example currently counts 165 such combinations.
Another disadvantage of that file is that it only lists matching part numbers, but it does not carry
information about the offset and orientation, and the color of the tyre. In fact, that text file is a stripped-down
instance of an LDRAW line type "1" (part usage), but without positioning, matrix and coloring element.
I felt that being a loss, and a step backward behind what our library already can do.
And I felt that these combinations should not be a private detail of tool SR3DBuilder, but of the library itself.
I cannot really see the "clutter" argument, as the number of these assemblies will be small, compared
to the plenty of physical color shortcut files we already have.
To make a long story short:
I would very much like to have these shortcuts in our library, at least for the wheel+tyre combinations
that occured in official LEGO models.
I'd like to hear your thoughts on this.
http://www.ldraw.org/cgi-bin/ptdetail.cg...482c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...482c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...996c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...695c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...245c02.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...715c01.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg...039c01.dat
and
http://www.ldraw.org/cgi-bin/ptdetail.cg...27ac01.dat
, which has sparked this discussion:
Magnus questions if having these makes sense.
I'd like to answer that question with my reasoning here.
The reason behind creating these shortcuts was that when building models,
I again and again found myself in 2 actions:
(a) searching the matching tyre for a wheel (because in MLCad all parts get scaled in the parts library preview, so all wheels and tyres look the same size)
(b) after I had found them, I to each model added a "wheel+tyre" assembly submodel
After having done this some times, I was asking myself why the assembly of (b)
was not part of the library.
Of course, the answer is: avoid clutter. As some wheels can carry different tyres, a combinatoric explosion
might occur. This prevented me some time from creating these shortcuts.
I then discovered that e.g. SR3DBuilder contains a separate database for this purpose: "TireManager.txt" (see attachment).
It is a simple text file which lists wheels plus their matching tyres.
When I saw that, I felt reminded of the discussion about 2 other things:
(i) alias part numbers
(ii) physical color shortcuts
There, the discussion was just the same: should we track this data somewhere?
The discussion about these 2 mainly went like this at those times:
First, an agreement was achieved that this information is quite valuable and needs to be stored somewhere.
The initial idea then was to have a separate database.
It then turned out that that separate database was nothing else than simple redirections
of part number to other part numbers, or of part numbers plus a certain color to other part numbers.
Then the question arose why we would create all the effort to maintain tooling etc. for a separate database,
when the existing mechanisms (i.e., LDRAW lines of type "1", part usage) would do everything we need.
Voila, a prefix was added to easily distinguish these files, and later, even an !LDRAW_ORG header type was added
(which I consider even better), and that was it. I find this solution very elegant, as it is self-contained and does
not add a secondary database.
When I remembered that, I felt that at least for the "usual" wheel+tyre assemblies, i.e., such that occur
in official LEGO models, we should have these shortcuts, basically for the same reasoning:
there is only a limited number of combinations possible, and that number is not too high:
SR3DBuilder's text file for example currently counts 165 such combinations.
Another disadvantage of that file is that it only lists matching part numbers, but it does not carry
information about the offset and orientation, and the color of the tyre. In fact, that text file is a stripped-down
instance of an LDRAW line type "1" (part usage), but without positioning, matrix and coloring element.
I felt that being a loss, and a step backward behind what our library already can do.
And I felt that these combinations should not be a private detail of tool SR3DBuilder, but of the library itself.
I cannot really see the "clutter" argument, as the number of these assemblies will be small, compared
to the plenty of physical color shortcut files we already have.
To make a long story short:
I would very much like to have these shortcuts in our library, at least for the wheel+tyre combinations
that occured in official LEGO models.
I'd like to hear your thoughts on this.