LDraw.org Discussion Forums

Full Version: The Case for Underside Fillet Primitives
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
As some of you may have seen, I recently added some underside stud fillet primitives (Here is one such file, where discussion has occurred). Some are wondering whether these parts should exist, and if so, where they should be located (P or S). Here is the thread I promised with my arguments.

The Problem (As I See It):
There are a number of parts in our library which have underside fillets. I recently uploaded some new 4xM and 8xM parts, but more exist. There are more as well. However, there is actually a bit of variety to them. Some are 2 ldu in width, while others (like the ones I worked on) are 3 ldu in width. There are also some medium height ones as well as ones which are full length except at the edges where they are medium height. Some are detailed while others are pretty basic.

Here's a picture which shows some of that variety:
[Image: fillets.png]

However, there is currently no system for naming or re-using these parts. In fact, most of relevent parts are located in the S directory, and I found no less than 3 sets of these, two of which could probably be combined:
- 6161.dat and 6162.dat use s/6161s01.dat and s/6161s02.dat
- 30072.dat uses s/30072s01.dat and s/30072s02.dat
- 47116.dat uses s/47116s02-05.dat (4 files)

And the question becomes, the next time LEGO releases a new large Brick, will the person who creates the part be able to find and use the correct subparts/primitives for this? Will they simply create another set for their given part? How is one expected to know these parts even exist when there is no mention of them on the primitive reference page?

Why not just put these parts in the S folder?
Because it makes re-using them harder, especially for newer authors who may not know they exist. Really, the S folder should be for part specific subparts which don't and probably never will have any use elsewhere. The P folder is for primitives which either can be used for many parts, or have the potential to be used by many parts.

The Solution (As I See It):
I believe we need to create a new set primitives for underside fillets. When I created mine, I used stud naming convention based on an assumption that later proved to be false. And as Chris has pointed out, these are much more than studs. As such, I believe a new name should be used, and I'm currently favoring "Fillet" although I'm open to suggestions on this. However, assuming we used "Fillet", the naming scheme would proceed as such:

S is the width of fillets in ldu. Currently both 2 and 3 ldu width fillets exist, and it leaves the option for further sizes should they come along.
h is used for half-height fillets (I believe 33230.dat on the PT could use these).
d is used for detailed parts (like the ones I currently have on the PT).
optional-identifiers can be used for different variants based on wall collisions. A meaningful naming convention is preferred.

So that's it. I don't think I'm that far out of line on this, but you can let me know what you think.
Hi Jude,

I agree these should be primitives. Might I suggest shortening the 'fillet' to 'fil' since primitives are meant[1] to be only 8 characters long (yes I know it's annoying).

Why not come up with a fully worked system of fillets first and propose a full naming convention (with examples) and the forum can refine the nomenclature. For example, probably you can avoid dealing with height in the primitive by simply setting height=1LDU and scaling vertically. That saves hassle. Obviously width cannot be dealt with in the same way.


[1] Maybe I'm wrong about this? Hopefully??
Quote:I agree these should be primitives. Might I suggest shortening the 'fillet' to 'fil' since primitives are meant[1] to be only 8 characters long (yes I know it's annoying).

[1] Maybe I'm wrong about this? Hopefully??

This isn't the case anymore, primitives can have longer names than 8 characters.
Yes, they can.
Awesome. I knew parts could but had the mistaken impression primitives were still restricted. I take back my complaint.

Tim Gould Wrote:Why not come up with a fully worked system of fillets first and propose a full naming convention (with examples) and the forum can refine the nomenclature.

Well, currently I have two sets of fillets (both of width 3 ldu) ready to go. Both were on the PT, but I believe Chris deleted one of them. One set is the "normal" ones and the other is the detailed (although someone mentioned in another thread that "reinforced" tends to be more commonly used and I like it a little bit better). So, using this naming system, we'd have:

fillet3.dat (not attached to any walls)
fillet3-1.dat (attached to one wall)
fillet3-2a.dat (attached to two adjacent walls)
fillet3-2p.dat (attached to two parallel walls)
fillet3-3.dat (attached to three walls)

fillet3r.dat (not attached to any walls)
fillet3r-1.dat (attached to one wall)
fillet3r-2a.dat (attached to two adjacent walls)
fillet3r-2p.dat (attached to two parallel walls)
fillet3r-3.dat (attached to three walls)

You can see how it would go for 2 ldu width fillets by simply substituting 2 for 3.
What file am I accused of deleting?

I only removed the unnecessary stu24c files when I renamed stud4c* to stux*.

In any case PT deletes are only "logical deletes" and can be retrieved on request.
Yes Chris, those are the files I was talking about. It's OK, though, I can always re-submit them.
Please don't. Only stud* primitives need lo-res stu2* equivalents.

There is no value in having a low-res version of a primitive which only includes rectilinear surfaces and a linetype 1 call to an existing primitive (stud4f*.dat). When set in lo-res mode a renderer should do the stud4f* -> stu24f* substitution regardless of how deeply that primitive is nested in the call hierarchy. As I explained here, that's why these primitives should not be named stud*.
I wonder if there is a different approach that we might take here (although the effort that is going into this discussion seems disproportionate to the number of parts that might be improved).

Rather than building a set of five primitives that comprise a stud4f* plus a variable number of attached fillets (or ribs), another approach might be to build just the stud-to-stud and stud-to-wall primitives and reference them multiple times in the part files, or make 1x5 combinations of the rib primitives.

Since we also have an established nomenclature for the width of the fillet (rib) stub in the existing stud4f* primitives [n=narrow (2LDu), s=standard (3LDu), w=wide (4LDu)], I'd prefer to stick with that in the fillet primitive naming.
Pages: 1 2