Stud Groups

[Travis Cobbs]

Tim Gould asked that we come up with an official policy for Stud Groups. Unless I'm misunderstanding, he believes that stud groups of arbitrary X by Y dimensions should be created to fulfill the needs of any individual part, and others disagree.

I personally would lean towards restricting stud groups to 1xX, Xx1, and XxX (square). Most existing plates could be accommodated with at most three stud groups. However, I'm not a parts author, so I don't feel that my opinion on this should carry as much weight as part authors (both here on the LSC and not). Also, I agree with Tim that since there is disagreement about these among existing parts authors, it's better for us to set a standard (either direction) than to leave things like they are now.

Given that this affects parts authors, I invite all parts authors with an opinion on the issue to chime in on Tim's thread, to hopefully help us in our decision-making.

[Roland Melkert]

I think it's like programming, you don't put something in a function unless you use it multiple times or if it helps break something up in more manageable chunks.

But not being a part author ether, I have to read up on past discussions first in order to form an real opinion.

[Allen Smith]

The whole concept of stud groups strikes me as pointless. Then again, I'm not a part author. Perhaps there is some aesthetic zen of part construction. Personally, all I care about is the geometry and the efficiency of graphics-processing it.

The reasons cited so far seem uncompelling:
File Size: this is functionally irrelevant.
Logo Orientation: You can create wrong logo orientations with the limited stud groups as Steffan proposed just as easily as you can by placing all the studs individually. The alternative—creating stud groups for every configuration of studs in existence—seems counterproductive to me.

[Willy Tschager]

Do we agree that this is PT territory and that we do not rule one it?

w.

[Travis Cobbs]

Since they don't seem to be able to make a decision, I still think we should make one for them, so that there's no longer any ambiguity.

[Roland Melkert]

I agree that it's PT Territory, cause the header spec etc doesn't list when to make e.g. subparts either.

But I do think we could help in sort of a 'referee' role, if they are stuck on it. It just won't be added to the spec.

[Willy Tschager]

Roland Melkert Wrote:
-------------------------------------------------------
> But I do think we could help in sort of a
> 'referee' role, if they are stuck on it. It just
> won't be added to the spec.

I disagree. If we are going to make a rule it shouldn't be a mere
suggestion, but added to the LDraw.org File Format Restrictions for the Official Library.

As for the rule itself I'd go with - as Travis has put it:

"restricting stud groups to 1xX, Xx1, and XxX (square)"

which is in sync with Steffen's explanation given here:

http://www.ldraw.org//cgi-bin/ptdetail.c...ug-2x3.dat

Makes the most sense to me.

w.

[Chris Dee]

I agree in principle - "restricting stud groups to 1xX, Xx1, and XxX (square)".

How we document it though is a bit more tricky. We don't define the other primitive naming conventions in the LDraw.org File Format Restrictions for the Official Library. Most of the other guidance is in the Primitives Reference. I don't have a problem adding this information there also.

Chris

[Travis Cobbs]

I think it should be mentioned in the primitives reference, but also included in the official parts file restrictions document so that it becomes LSC-official. The primitives reference is not controlled by the LSC (intentionally). (Take a look a the note at the bottom of any LSC-official document, like the restrictions document.)

[Willy Tschager]

I did some copy'n'paste. Feel free to comment:

********************************************************

Stud group are provided to reduce the size of part files with many regularly spaced studs. The naming convention is as following:

stugN-XxZ.dat

where:

N = type of stud (regular stud, hollow stud, underside stud, …)
X = number of studs on the x axis
Z = number of studs on the z axis

To prevent an overload of the library with all sort of combinations, the numbers on the x and z axis are limited to:

1xZ stugs
Xx1 stugs (Due to stud orientation you cannot rotate a 1xZ stud group by 90 degrees to get a Xx1 stud group)
XxZ stugs where X==Z

These primitives should not be scaled.

********************************************************

[Travis Cobbs]

It sounds good except for two minor things. In the first sentence, "Stud group" should be "Stud groups". In the last sentence, I feel "should" should be "must".

[Chris Dee]

I think the difference in strength of enforcement between "should" and "must" is greater in American English than in UK English. Or maybe it's my personal usage. I tend to treat them as equivalent, with "should" seeming more polite. In refererence to scaling, I think I have used "should" elsewhere in the Primitives Reference, which I assume is where Willy wants this to appear.

[Travis Cobbs]

I was basing it on what I had seen in other specifications. In specifications, there is actually a very big difference between should and must. See RFC 2119.

[Roland Melkert]

This seems very clean and practical.

Only thing I can think of is maybe limit the XxZ variant to even numbers. Just a feeling though.

[Willy Tschager]

In reference to scaling, I think I have used "should" elsewhere in the Primitives Reference, which I assume is where Willy wants this to appear.

This comes directly form your Primitives Reference page. Re-reading the notes in my English lessons book (I remotely remember using it in another life, ages ago) I'm going to agree with Travis:

"Must is stronger than should and ought. Must expresses certainty. Should/ought to expresses probability."

w.

[Chris Dee]

Having done some research of my own, I agree. I have updated the Primitives Reference to use "must".

[Willy Tschager]

Not really a good idea. According tho the Primitives Reference there are already 3x3, 5x5, 7x7, ... out in the wild. Also you could author a:

http://media.peeron.com/ldraw/images/7/3933.png

with 1x8 + 1x6 + 1x4 stugs, but also a combination of 3x3 + 1xZs would do the job, though this would require an additional line.

w.

[Roland Melkert]

You are right. I agree.

Do we vote on this now?

Or do we let it 'settle' some more?

[Travis Cobbs]

We can vote as far as I'm concerned, but I'm open for further discussion, if anyone has anything to say.