Standards for stud groups

[Tim Gould]

Firstly, hello and congratulations to the new LSC.

Secondly... stud groups. I'd really appreciate some clarity.

Personally I think any basic plate should potentially have an equivalent stud group and certainly the small ones. Mike and Steffen disagree.

Luckily we have a team of people who can resolve this issue officially once and for all. I'm happy to go with whatever is decided but I'd like to see a decision. In the grand scheme of things it's a minor issue but it's one that Mike felt strongly enough about to place a hold and I felt strongly enough about to disagree with the hold.

And a note on the solution should be added to the primitives reference page. Which I shall do when it happens.

Cheers,

Tim

[Jude Parrill]

So, from what I've read around here, in various files, and on the parts tracker, there seems to be two prevailing theories on the creation and usage of subparts. (Note, when I use the term "subpart", I'm using it generally to refer to any part referenced by another, whether they be in the S, P, or 48 files, and not the specific subpart file S.) The first theory is: subpart everything, it makes the files look cleaner. The second is: subpart only that which may be useful elsewhere, as this makes things more efficient.

Now, at least to me, your question frames this issue quite cleanly: Do we really NEED to make a subpart for all possible stud groups? Why should/would we want to? Would it be better to have fewer subparts? Which option is more optimal, in terms of both memory usage and loading speeds? Does having more subparts make part creation easier or harder?

I don't have the answers to these questions, but I do think it's important that they're discussed.

Final thought: Has anybody actually bothered to run tests on this to see what actual "cost" is for using subparts vs inlining? I hear tales "recursion indefinate" and from a programmer's point of view of making an optimally performing program, I shudder. I remember taking an optimization class back in college and while I don't remember much of it, I do remember that recursion=bad.

[Orion Pobursky]

Personally, I never really saw a good reason for stud groups. It just seems to add another layer of hierarchy that's not really needed. Also, if you want to be really picky, they're not really primitives. That said, the box is now open so griping about it is kind of pointless...

[Travis Cobbs]

I haven't kept up with stud groups, so I just want to make sure I understand something. I believe that the reason for having 1xX and Xx1 stud groups is so that the stud logo will have the correct orientation. Is this correct? (I know this isn't involved in the question, but if the LSC does standardize something, it will need to be explicitly given as the reason for having both to avoid possible confusion.)

Also, related to the above, is there an official policy on stud logo orientation? Is it reason for a hold, or just a complaint inside a novote? Is this documented anywhere? (I think it needs to be documented, either way.)

[Tim Gould]

Some more discussion

http://news.lugnet.com/cad/dat/parts/primitives/?n=310 is the earliest discussion I could easily find. And the debate lasted over 2 years

Steffen lays out some compelling argument here http://www.ldraw.org/cgi-bin/ptdetail.cg...ug-2x3.dat


Travis Cobbs Wrote:
-------------------------------------------------------
> I haven't kept up with stud groups, so I just want
> to make sure I understand something. I believe
> that the reason for having 1xX and Xx1 stud
> groups is so that the stud logo will have the
> correct orientation. Is this correct? (I know
> this isn't involved in the question, but if the
> LSC does standardize something, it will need to be
> explicitly given as the reason for having both to
> avoid possible confusion.)

From what I could find on LUGNET (link) yes this is the reason. Interestingly this is not spelled out on the primitive references page, and nor are the logos pictured.

> Also, related to the above, is there an official
> policy on stud logo orientation? Is it reason for
> a hold, or just a complaint inside a novote? Is
> this documented anywhere? (I think it needs to be
> documented, either way.)

I'd like to see a clear policy on that too.

Tim

[Orion Pobursky]

I have a few thoughts:

• I'm not convinced the part size is really that big of a problem. I think it's a problem we invented as opposed to observed.
  
• Stud logos. This has been argued before. I'm still of the position that logos are not part of the spec and therefore why should we care about them when certifying parts. If we really care that much about them to create extra "primitives" (i.e. 1 x X and X x 1) then we should codify it.
  

[Willy Tschager]

Though I agree with Mike and Steffen on this, I do not think that the LSC should rule over it. In my opinion it should be handled by the PT admin. Its his choice how many STUGs he wants to show up on the Primitive Reference page. If a rule is needed we should add something to the LDraw.org File Format Restrictions for the Official Library on stud orientation in general.

w.

[Tore Eriksson]

Having been asleep for far too long, I guess it's a bit too late for me to add my opinions right now. I think there's about thirty certified stug primitives already in the PT. Unfortunately, because I find a lot of them totally unnecessary.

Stud orientation is not the least interesting to me, but I know that a lot of LDraw users produce photo-realistic renderings, so for them, it is essential. So therefor I say yes to both 1xX and Xx1 versions.

But the question is: when is it justified to create yet another "primitive"?
In other words: How many lines does it at least have to represent to be beneficial?

Two stud primitives? Like the case of stug2-1x2.dat and stug2-2x1.dat? No way!
Three stud primitives? Hmm, well maybe - if it's very commonly needed, like 3x1 and 1x3.
Two stugs? Well, it depends. I think 1x6 and 6x1 can be useful, even though they only replace two 3x1 groups. But generally I would say no. For example, with 5x1 and 6x1, there no need at all for 11x1 IMO.

3x1, 4x1, 5x1, 6x1? Ok.
7x1, 8x1, 9x1, 10x1, and 11x1? No, I don't think so. They replace only two smaller stugs. We should draw a line somewhere, shouldn't we?
12x1? Well, only if there's a really large demand for it, maybe. But we already do have 6x1...

I know I should have said this earlier, but better late than never, maybe.

/Tore

[Chris Dee]

Just because these are on the Parts Tracker and Certified doesn't mean they'll ever get released. I still follow the guidance of previous Parts Library Admins in not releasing primitives until there is a part/subpart that uses them.

Chris

[Tore Eriksson]

Chris Dee Wrote:
-------------------------------------------------------
> Just because these are on the Parts Tracker and
> Certified doesn't mean they'll ever get released.
> I still follow the guidance of previous Parts
> Library Admins in not releasing primitives until
> there is a part/subpart that uses them.
>
> Chris

Ok, but do you think I would make myself very impopular if I voted hold on the 2 stud stugs now? If it's even possible, that is.

/Tore

[Tore Eriksson]

Stud groups must not be scaled.
So it reads in the proposed rules for stugs, which is about to be approved.

But what if somebody suggests stud3 and stud4 groups, ie bottom studs and tubes?
Do we have to make one set of stugs fo plates/tiles and one set for bricks as the stud3 and stud4 primitives are scaled in the y-axis?

[Travis Cobbs]

None of those exist right now, so I think none of us thought about it. Since the proposal just passed, I think the best thing to do would be to add the proposed text as passed, then have another vote to modify the text to allow them to be scaled in the Y axis for underside studs.

[Allen Smith]

None of those exist right now, so I think none of us thought about it. Since the proposal just passed, I think the best thing to do would be to add the proposed text as passed, then have another vote to modify the text to allow them to be scaled in the Y axis for underside studs.

My expectation was that stugs consist of nothing but stud.dat.

Personally, I think stugs of tubes is really getting out of hand. What's so bad about just replicating the stud/tube/widget n times? With studs, it made some sense (for logo orientation), but for tubes?

In any event, this is an issue for part authors to get excited about, not me.

Allen

[Travis Cobbs]

The proposal we agreed on allowed for all different stud types (hence the N in the filename template). So, while there aren't any stud groups for tubes at the moment, what we voted on allows for them. An option to allowing Y-axis scaling of stud groups is to update the text to only allow for topside stud groups, but I don't think we should do this. There aren't any tube stud groups yet, and there may never be, but I don't think they're something that should be forbidden.

[Steffen]

I'd like to reply to Allen:

Personally, I think stugs of tubes is really getting out of hand. What's so bad about just replicating the stud/tube/widget n times?

No, no, it really is not getting out of hand.
The stugs allow a massive compression of both filesize on harddisk and internal memory storage of a part.
For example, a big baseplate with 32x32 studs will shrink dramatically.
The effect is easily achieved because the usage of stugs shrinks the references to studs
logarithmically.

Regarding scaling:
I think that the discussion currently is led much too formally.
The stugs are very effective, and the current spec allows extending them to underside studs as well.
Those need Y scaling the same way as the studs do.
So simply change the wording, and we're done. I suggest:
"To stugs, the same scaling rules as for studs apply."
That's it.

[Orion Pobursky]

The stugs allow a massive compression of both filesize on harddisk and internal memory storage of a part.

- File size is a non-issue. It might have been when hard drives were 100 MB but that was over 20 years ago.
- Internal memory savings is non-existant issue since you still process the same amount of data.

[Steffen]

File size is a non-issue. It might have been when hard drives were 100 MB but that was over 20 years ago.

Orion, please just don't use such a simple argumentation!
You are throwing the argumentation why stugs exist back to its beginning,
I feel this is counter-productive, as this discussion has been led long time ago when they got created.
The point is not mainly about filesize on harddisk (although even that still is an issue, think of mobile devices!).
The point is about loading and parsing times.

Let me just throw together a quick, rough thumb calculation to explain the performance gain.

imagine a model containing 4 parts, each of those parts contains a section of 4x8 studs.

without stugs, this means:
1. parse 4 lines in the model, referencing the parts.
2. parse the 4 parts, each contains at least 32 lines of stud references.
3. parse the stud.dat file 1 time.
Sum:
4+4x32 = 132 lines, each having a transformation matrix.
1 time parsing of stud.dat

with stugs, the calculation goes this way:
1. parse the 4 lines in the model, referencing the parts.
2. parse the 4 parts, each contains 2 references to the 4x4 stug
3. parse the 4x4 stug 1 time
4. parse the stug.dat 1 time

4+4*2 =12 lines, each having a transformation matrix
1 time parsing of the 4x4 stug.dat
1 time parsing of stud.dat

THIS is the performance gain.
Loading time of parts and models does matter for big models.

The gain will be even much bigger for models containing more parts
or for parts containing many studs.

[Allen Smith]

The stugs allow a massive compression of both filesize on harddisk and internal memory storage of a part.
For example, a big baseplate with 32x32 studs will shrink dramatically.
The effect is easily achieved because the usage of stugs shrinks the references to studs
logarithmically.

Steffan,

I appreciate the insight into the thought process very much.

You should know there is effectively zero internal memory savings by doing this. The memory hit comes from referencing geometry in a part. How you juggle around the way the geometry is referenced at the file level has no bearing on the end result.

While group files like this do indeed save a few lines of text parsing, they offer no savings in geometry processing, which is a hefty bit of "parsing" time.

As for disk savings, this is also not what one might expect. Most LDraw files are tiny. Hard drives, or filesystems or something, have a minimum sector size each individual file must carve out. For example, on my system, no file is smaller than 4 KB, even if it only has 1 byte of content. Only the hugest stud fields are going to come close to using up the whole 4 KB. Any effort to shrink files that are already smaller than 4 KB will yield no disk savings whatsoever.

Allen

[Steffen]

I suggest that we stop re-discussing the pros and contras of stugs again.
- the stugs now exist officially, and they have a positive effect on filesize and parsing time
- they do not worsen anything else except for adding a handful of new primitives, so they do not hurt
- they are official now

Would we re-start the discussion of having them, and the outcome would be
that we shall keep them everything is like it is now.
Should the outcome be that we shall not keep them would be a useless result
as stugs are officially out and cannot be removed anymore.

We're wasting energy here IMHO

Regarding the clustering of certain filesystems: this is nothing our library should rely on.
In future, anybody can invent another filesystem and store our files differently.
So clustering of existing filesystems should not be an argument for us to stop saving filesize.
We must save filesize as good as we can.

[Tim Gould]

Steffen,

This discussion started about a type of stud group that does not yet exist

To allow for it the existing spec would need to be changed

So the future existence or non-existence is important. Not very important but worth talking about if people wish to spend the time.

Tim

[Steffen]

oh, I think this can be settled easily.
I think that the current wording in the spec is too restrictive for stugs.
I currently forbids vertical scaling for stugs, whereas it allows it for (underside) studs.

So the only thing currently needed is IMHO to change that wording to something like
"the same restrictions for scaling of studs apply to stugs as well", and we're through.

the decision whether to create new (underside) stugs can then be done later, independently.

the suggested above small correction in the wording of the spec does not hurt.

[Tim Gould]

It would require a new vote and a new change to the spec.

One can easily argue that's energy that doesn't need to be spent until underside studs are allowed.

Tim

[Steffen]

well, I suggest to simply do that vote and after that stop the discussion of the usefulness of stugs

[Willy Tschager]

Agree with you Allen.

As for the usefulness I've got the most important argument ever: They save a lot of time copy'n'paste of singles stud + position them to the part authors! Period.

w.