The Case for Underside Fillet Primitives

[Jude Parrill]

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:


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:

FilletS[h][d]-[optional-identifier].dat
where
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.

[Tim Gould]

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.

Tim


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

[Santeri Piippo]

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.

[Chris Dee]

Yes, they can.

[Tim Gould]

Awesome. I knew parts could but had the mistaken impression primitives were still restricted. I take back my complaint.

Tim

[Jude Parrill]

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:

Normal:
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)

Reinforced:
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.

[Chris Dee]

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.

[Jude Parrill]

Yes Chris, those are the files I was talking about. It's OK, though, I can always re-submit them.

[Chris Dee]

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*.

[Chris Dee]

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.

[Magnus Forsberg]

I didn't get any respons on my hold vote at PT, and maybe you have corrected your fillet allready, but I feel that I must act before you dig yourself deeper into this.

IMHO, there is a flaw in your design.
Let me try to explain what I mean. Why did LEGO change this design?
I say it's because it is impossible to connect a 1x1 brick to the underside of a big brick. There isn't enough surfaces to give a stud enough clutch power. It simply can't connect. Have a look at my picture.



The new design has a thinner outer wall and gives place for tiny boxes along the inside.
The reinforcements are there to give more surfaces for the stud connection.
It is possible to connect a 1x1 brick in any place, on the underside of a new big brick.
In the old design it is only possible to place a 1x1 brick in the corners.

The current design of your stux-primitives have many issues.

If I were to try to make these, I'd go for only two new files.
Why?
Because the distance between two studs are always the same, as so is the distance between a stud and the surrounding outer walls.
I would make one file creating the wall between two studs, and one file creating the wall between a stud and the wall. And then use those.

I started writing this two hour ago, but didn't have time to finish it. I now see that Chris has the same idea.

[Jude Parrill]

It's not as though I haven't thought of the two basic fillets solution. It did occur to me, in fact. However, I chose to go away from it for this reason: When you have these, you'll still need at least 2 more for the sidewalls (which could be done in a couple different ways. Why? Because when you have these walls, by necessity you're going to need to break up the sidewalls to avoid T-Junctions, especially in the case of the reinforced versions. So you're still going to end up with 4 primitives: two for the interior fillets (stud-to-stud and stud-to-wall), and two more for the inner walls (let's say corners and straights, although other options exist).

Further, isn't part of the point of primitives to reduce file size? Using my solution, the file sizes are drastically smaller than what they would be using this solution. Consider my 4x6 brick, which is the smallest one (and thus benefits the least from them). It uses exactly TWO primitives to model the entire bottom. Using your solution, you'd need: 2 stud primitives, 1 stud-to-stud fillet primitive, 6 stud-to-wall fillet primitives, 2 straight-wall primitives, and 4 corner-wall primitives for a total of 15 primitives. That's 13 fewer lines in my file. And the savings only goes up with the size of the part. What will the savings be for my 8x16? Meanwhile, with your solution, we go from 5 files to 4, although the file sizes of the 4 would be a bit smaller than the 5, but overall, I think you'd save much more disk space with my solution.


Oh, and Chris, in response to your other post above: I don't intend to submit/resubmit anything until this is resolved. Also, the whole point I'm making here is that they shouldn't have "stud" in the name, so the parts that I currently have on there would need to be renamed, and I would re-name my other parts before I'd submit them.

[Jude Parrill]

OK, so after some consideration, I think I've reached a compromise solution: 3 types of fillet primitives. There will be one stud to stud fillet, and two stud to wall fillets: a fillet attached to one "side wall" and a fillet attached to two "corner walls". I've attached an update 4x6 with the reinforced fillets to this post, and will post the plain ones shortly (can't post them all at once due to forum restrictions). Also note: I've re-worked the reinforced fillets per Magnus's observations (this is something I had failed to consider while creating these, although I should have. Have patience, I'm still learning). they should now "connect" properly with studs.

Let me know what you think. If you guys are ok with this, I'll go ahead and put them on the PT along with the updated part files, and Chris can delete my stux primitives.

[Jude Parrill]

Here are the plain fillets as well (with a 4x6 example).

[Magnus Forsberg]

I like it a lot, but I'll step back and let someone else be the judge.

[Jude Parrill]

Hey guys, I'd like to move forward with this one way or another, so some feedback would be nice, especially from Chris. I keep seeing my un-certified files on the PT and want to do what is necessary to certify them.

[Chris Dee]

This looks a much better structured approach. I'd just like some tweaks to the file naming convention:

Code:

fillet[pr][012][nsw].dat
      [pr]          : p=plain; r=reinforced
          [012]     : number of adjoining side-walls
               [nsw]: n=narrow (2LDu); 3=standard (3LDu); w=wide (4LDu) - to match stud4f.. nomenclature

So fil3r -> filletr0s, fil3r-cw -> filletr2s, fil3r-sw -> filletr1s
and fil3 -> filletp0s, fil3-cw -> filletp2s, fil3-sw -> filletp1s