|
In lugnet.cad.dat.parts.primitives, Tore Eriksson wrote:
> In lugnet.cad.dat.parts.primitives, John Riley wrote:
> >
> > It looks like there could be significant use of stud4 groups as well. I'm also
> > thinking that 1 x n rows of stud2 and stud 3 could be useful. Not as high in
> > demand, but the stud4 groups would be really nice. (The version of 700.dat
> > posted is now over half stud4 calls.) (For stug2, I think just a 2x2 and 1x4
> > would be all that is needed)
>
> I've been thinking about groups of stud3 and stud4, but found it not too
> commonly used as the stud.dat. Baseplates for example have no bottom studs.
> There is also a little problem with the odd numbers - four top studs corresponds
> to three bottom studs, 6 to 5, 8 to 7 and so on. I see no natural, generally
> useful numbers.
>
> My thought is that a group of 8 studs is the least number where it's worthwhile.
> You save 7 calls by using such a group. With a group of 4, you only save 3
> lines.
Well, that's 3 lines per instance. It takes 3 calls of a group of 4 to get to
the same line savings as the group of 8. And 1 x 4 and 2 x 2 groups are common
enough to get at least 7 lines saved. In the 700.dat you posted, just using 1 x
4 groups of stud4's will save ~30 lines (40 calls to 10 calls, roughly). Even 1
x 3 groups for stud4's would still save enough lines (all the variations of 2x4
bricks would make this worthwhile).
Personally, I think that a group of 4 (3 for underneath) or larger is
worthwhile. Larger groups can be made from the smaller groups, thus immediately
gaining some line savings (similar to using 1-4 primitives to make 4-4
primitives, though in those cases, the savings are huge). The line savings from
small groups will grow as the smaller groups are implemented into the parts at
large (as it is, I already use stud clusters as subparts when designing complex
or large parts anyway, even if the stud cluster is just 4 studs).
>
> > Would a naming convention of
> > stugNx-z.dat
> > be useful?
> > where
> > N is the corresponding stud type (underscore for stud.dat)
> > x and z are dimensions as before.
>
>
> Well, almost. :) Earlier i this thread, Chris suggested that "The existing
> parts\s\4186a.dat would become p\stuc1-48.dat" (c for cluster, now g for group)
> Together with the suggested N, that would make 9+3, no longer within DOS naming
> covention. How about stNgx-z.dat? Then the numbers are kept apart to avoid
> confusion. All this, of course, if we decide to have groups other than with just
> standard top studs.
I like the stNgX-Z name. Though I was under the impression from an earlier post
that Z was going to be single digit only. (How many times is a 1 x 48 is going
to be used? 48 times in that file. Using 8 x 8 clusters, you'd only need 36
calls. And there are many more pieces that would use an 8x8 than a 1x48).
Of course, what happens if we need clusters of stud11's? (or any future stud
that Lego designs) I'm for planning for possible expansion, that's why I'd like
to see Z remain single digit, so that N can become double digit if needed.
(another scenario: N or Z can be double digit, but not both).
>
> > I like the idea of stud groups; I would just like it spread universally,
>
> Me too. I'm planning to try this idea in the PT as soon as any discussion on
> this subject is finished here.
>
>
> /Tore
It's a good idea. Especially with slews of BFC fixed files on the PT right now.
It'd be nice to resubmit them with stud groups before the next part update
release.
John
|
|
Message has 1 Reply:
Message is in Reply To:
27 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
|
|
|
|