[Suggestion] Curve the npeghole primitives

[Max Murtazin]

One thing that was bothering me for the all time I was using LDraw-powered software, and especially after I started making parts for the repository, is that the npegholes are very oddly unsmoothed. It doesn't look good, it is not accurate, and requires not that much work to do. Maybe update this set of primitives to make corners a bit rounded?

[Orion Pobursky]

One thing that was bothering me for the all time I was using LDraw-powered software, and especially after I started making parts for the repository, is that the npegholes are very oddly unsmoothed. It doesn't look good, it is not accurate, and requires not that much work to do. Maybe update this set of primitives to make corners a bit rounded?

Can you elaborate a bit more on this?

[Max Murtazin]

Can you elaborate a bit more on this?

Currently it is like this (npegholes, those carvings between connection holes), with sharp ends


And I suggest to make it more like this, to make it have more curved edges

[Orion Pobursky]

Your images are broken but I think I understand.

We've had the same debate for click hinges and the round/half round 1x1 tiles. My counter point would be that these small rounded edges at a lot of triangles for a feature that is only visible at close zoom levels. Also, developers are free to use primitive substitution to render them with "higher res".

My person opinion is more of the latter and less of the former.

[Max Murtazin]

Is it that much significant, tho? Modern PCs (something from last 5-6 years) can easily handle pretty extreme polygon counts. Polygon number increase from this for sure will be big, but not exponential. Not something that is a real game changer to make new version of primitives impossible to use. Axle primitives got updated not so long ago, and polygon increase was way more dramatic for those, than what is necessary to have smooth npegholes

[Orion Pobursky]

I totally agree about triangle count but others care about that more than me. 

Also, now that the images are loading, I didn't understand what you meant. That said, if you want to change, you probably have to do it yourself including researching what parts have that shape but don't use the primitive so you can either update to use it or change it so it conforms. If you're up to the task,  you have my encouragement to do this.

[Max Murtazin]

I totally agree about triangle count but others care about that more than me. 

Also, now that the images are loading, I didn't understand what you meant. That said, if you want to change, you probably have to do it yourself including researching what parts have that shape but don't use the primitive so you can either update to use it or change it so it conforms. If you're up to the task,  you have my encouragement to do this.

I will post tomorrow more informative pictures, as well as primitives, looks like that would be more helpful to the topic

[Philippe Hurbain]

One thing that was bothering me for the all time I was using LDraw-powered software, and especially after I started making parts for the repository, is that the npegholes are very oddly unsmoothed. It doesn't look good, it is not accurate, and requires not that much work to do. Maybe update this set of primitives to make corners a bit rounded?

I agree that current situation is far from perfect (it's even worse for 90° angled beams where the npegholes join together), but changing this is rather daunting, as these elements are often embedded in part structure. The 90° situation was so bad that I already created npeghol17 with cut corners to address the problem in Technic baseplate (https://www.ldraw.org/parts/official-par...rtid=39369)
...Or we could go the other direction and completely remove beam npegholes like LEGO does in his building instructions!

[Max Murtazin]

I agree that current situation is far from perfect (it's even worse for 90° angled beams where the npegholes join together), but changing this is rather daunting, as these elements are often embedded in part structure. The 90° situation was so bad that I already created npeghol17 with cut corners to address the problem in Technic baseplate (https://www.ldraw.org/parts/official-par...rtid=39369)
...Or we could go the other direction and completely remove beam npegholes like LEGO does in his building instructions!

I think I didn't completely understand wdym, could you elaborate please a bit? Only thing I think I got is that some new parts have problem of old npeghole primitives having overlapping esges

[Philippe Hurbain]

I think I didn't completely understand wdym, could you elaborate please a bit? Only thing I think I got is that some new parts have problem of old npeghole primitives having overlapping esges

Not only new parts, but also some venerable ones like this one:

[Max Murtazin]

Okay so, here is more visual explanation of what I suggest to do. 
Currently we have this:

           

It is pretty angular, not so pleasing to see, and, as Phillippe mentioned, sometimes results in pretty unpleasing geometry

Instead, I suggest doing this:

           

Result is more pleasing to the eye, and doesn't have 0-thickness in any places of the part. 

Mentioning once again axle primitives, we already have an example of changing primitives to make them look better, and also with the change get rid of some unwanted geometry interactions, that don't change much due to not being visible most of the time. Liftarms by the way, I want to say, are way easier to notice imperfections with, because npegholes are seen very commonly on the builds, and some smaller ones look very not good with what is currently on hands

I also attach rough concept models of primitives I used for the pictures. These are currently just the concept models, and use no primitives nor have any smoothing. I will make proper versions of those two, as well as other npeghole primitives if idea won't ultimately get rejected, but for now I think it's enough for the discussion

[Orion Pobursky]

As I wrote above I like this idea. However, also as mentioned above, it's going to take a lot of legwork. If you don't mind doing this, I encourage you take on this project.

[Max Murtazin]

As I wrote above I like this idea. However, also as mentioned above, it's going to take a lot of legwork. If you don't mind doing this, I encourage you take on this project.

What problems might arise, for example? Currently I see ~20 primitives that just need to be updated, and not much problems updates might cause

[Cam's Bricks]

As I wrote above I like this idea. However, also as mentioned above, it's going to take a lot of legwork. If you don't mind doing this, I encourage you take on this project.

Since this is an improvement, wouldnt it be as simple as updating the one or two affected primitives? I am pretty new around here but I am surprised this would be a large undertaking.

[Magnus Forsberg]

The main issue is that the suggested design doesn't work in primitive substitution mode.

Most of the holes in beams are made using the connhole.dat primitive, and when it changes shape, the npeghole has to also adapt.
Many of the npeg primitives are today made using cyli primitives.

Or all beams will end up looking like this:

   

[Orion Pobursky]

What problems might arise, for example? Currently I see ~20 primitives that just need to be updated, and not much problems updates might cause

Changing the primitives themselves probably won't be too much of a problem as long as you don't change the geometry at the edges. It's finding and fixing/updating those parts that either interact with the primitives in a nonstandard way or don't use the primitives at all.

[Max Murtazin]

The main issue is that the suggested design doesn't work in primitive substitution mode.

Most of the holes in beams are made using the connhole.dat primitive, and when it changes shape, the npeghole has to also adapt.
Many of the npeg primitives are today made using cyli primitives.

Or all beams will end up looking like this:

I already mentioned that this variant is just a plain shape, just a plain model. I am going to make it work with primitive substitution once properly done

[Philippe Hurbain]

I already mentioned that this variant is just a plain shape, just a plain model. I am going to make it work with primitive substitution once properly done

You can make it work in the middle using cyli primitives instead of quads. But that's not possible near the corners.

[Max Murtazin]

You can make it work in the middle using cyli primitives instead of quads. But that's not possible near the corners.

I have looked into how you have done with the npeghol17, and tweaked it into how I see general npeghole primitive should look

By the way, here it is. It now is composed from primitives and supports substitution. Requires other attached primitives

[Philippe Hurbain]

I have looked into how you have done with the npeghol17, and tweaked it into how I see general npeghole primitive should look
By the way, here it is. It now is composed from primitives and supports substitution. Requires other attached primitives

Going to hires is definitely not an option...
edit:
...but the base idea (reduce width at corners) is a good one. We could possibly make it work.

[Max Murtazin]

Going to hires is definitely not an option...
edit:
...but the base idea (reduce width at corners) is a good one. We could possibly make it work.

What part of "going to hires" exactly you don't like? Smoothed corners or just general use of those in primitives? If prior, I think non-primitive corners can be used instead

[Philippe Hurbain]

What part of "going to hires" exactly you don't like? Smoothed corners or just general use of those in primitives? If prior, I think non-primitive corners can be used instead

I meant indeed that the small corners really don't need that many faces! As you say, non primitive corners work fine since they are so small. Attached my proposal...

[Magnus Forsberg]

Attached my proposal...

I like this one...

[Max Murtazin]

I meant indeed that the small corners really don't need that many faces! As you say, non primitive corners work fine since they are so small. Attached my proposal...

Shape looks fine, but can someone upload picture of this in random colors? Want to see also a primitive composition of it, but wouldn't be able to until the morning otherwise

UPD: Okay, I checked it, and I think I like this one too

[Philippe Hurbain]

Looking more closely, looks like the corner rounding should be even more prominent (Even though real shape depends on parts)

[Max Murtazin]

Looking more closely, looks like the corner rounding should be even more prominent (Even though real shape depends on parts)

That's more like it. Looks like general shape of this is a way to go, unless someone inupts a bit more on this

[Max Murtazin]

Would it be okay to use npeghole.dat as a primitive in npeghol2.dat? Makes the whole file look cleaner, and also saves some disk space

[Philippe Hurbain]

Would it be okay to use npeghole.dat as a primitive in npeghol2.dat? Makes the whole file look cleaner, and also saves some disk space

Yes, prims using prims is possible (and already often done)

[Gerald Lasser]

Looking more closely, looks like the corner rounding should be even more prominent (Even though real shape depends on parts)

That one looks very nice! I really like it.

I guess there is a possibility to use a 8\ prim section of a cylinder in the corners

something like this:
1 16 5.5803 0 1.7 .78 0 0 0 1 0 -.10 0 .78 8\3-8cylo.dat

[Philippe Hurbain]

That one looks very nice! I really like it.

I guess there is a possibility to use a 8\ prim section of a cylinder in the corners

something like this:
1 16 5.5803 0 1.7 .78 0 0 0 1 0 -.10 0 .78 8\3-8cylo.dat

Good idea, why didn't I thought of it ???

[Philippe Hurbain]

Good idea, why didn't I thought of it ???

...but I don't see how to fit a matching ndis. no 8\tang are defined...

[Max Murtazin]

...but I don't see how to fit a matching ndis. no 8\tang are defined...

Maybe it's the time to define those then?

[Philippe Hurbain]

Maybe it's the time to define those then?

Not so simple considering the way 48\tang are defined. 
Anyway using a cylo primitive is tricky as it must match the 1-16 tang vertex. The proper method is to a add an intermediate geometry, but it then adds even more faces... So non prim version is probably the best compromise.

[Max Murtazin]

Not so simple considering the way 48\tang are defined. 
Anyway using a cylo primitive is tricky as it must match the 1-16 tang vertex. The proper method is to a add an intermediate geometry, but it then adds even more faces... So non prim version is probably the best compromise.

What's the deal with 48\tang?

[Philippe Hurbain]

What's the deal with 48\tang?

It is defined as an extension of normal resolution of tang (this is the proper way to do it to allow direct normal -> hires substitution). But then at lo res this become meaningless.

[Max Murtazin]

It is defined as an extension of normal resolution of tang (this is the proper way to do it to allow direct normal -> hires substitution). But then at lo res this become meaningless.

I don't see much problem with this. Even tho hires is an extension of normal one, it doesn't mean that lores still should be that way

[Gerald Lasser]

It is defined as an extension of normal resolution of tang (this is the proper way to do it to allow direct normal -> hires substitution). But then at lo res this become meaningless.

As there is no prim substitution doen on the level of lo res prims, then we do not need a tang, imho.

PS: the end-condlines of 8/3-8cylo are wrong

Edit: Attached the sample

[Philippe Hurbain]

As there is no prim substitution doen on the level of lo res prims, then we do not need a tang, imho.

You have a point... But then using a cylo has a very limited interest  . Looks excellent nonetheless!

[Max Murtazin]

You have a point... But then using a cylo has a very limited interest  . Looks excellent nonetheless!

I also don't see much reason in using cylo besides saving a bit of disk space. 

New shaping looks better tho, I must point out

[Gerald Lasser]

I also don't see much reason in using cylo besides saving a bit of disk space. 

New shaping looks better tho, I must point out

Yes, it's mostly to reduce clutter in the code

EDIT: But the L-Beam looks very tempting now...
   

[Max Murtazin]

Yes, it's mostly to reduce clutter in the code

EDIT: But the L-Beam looks very tempting now...

For sure the way to go. If anyone don't have anything to suggest, I'll update other primitives tomorrow

[Magnus Forsberg]

If anyone don't have anything to suggest, I'll update other primitives tomorrow

I don't doubt that you are capable of editing a few primitives, but how about the extensive investigation into the geometry of all the parts using these family of primitives. I made a thorough investigation of all the parts with an axlehole, before a dared to suggest a rework.
Have you made a similar investigation of all the parts using npeghole primitives?

IMO it would be wrong to change all the npeg hole primitives, so which one are you planning to edit?

[Max Murtazin]

I don't doubt that you are capable of editing a few primitives, but how about the extensive investigation into the geometry of all the parts using these family of primitives. I made a thorough investigation of all the parts with an axlehole, before a dared to suggest a rework.
Have you made a similar investigation of all the parts using npeghole primitives?

IMO it would be wrong to change all the npeg hole primitives, so which one are you planning to edit?

All up to the 13 have one same element this topic was about fixing. By the extension, all npegholes 0 through 13 would need an update. As far as I know it, currently all parts with npeghole element use primitives, and with how updated variant is done, it shouldn't cause any problems.

I will go through all the parts using those primitives, but for that I need primitives themselves to be on my hands

[Magnus Forsberg]

All up to the 13 have one same element this topic was about fixing.

IMO that wrong. They are differently used, and designed. And should be different. Editing them all, would create a bad result

I will go through all the parts using those primitives, but for that I need primitives themselves to be on my hands

When I reshaped the axle holes I edited my own library and then used them coloured.
1.) edit the primitive, place it in your own unofficial p-folder.
2.) hard code the edited prim in a "weird" colour
3.) remove the corresponding official primitive.
4.) examine the result. I used LDFind and LDStructure a lot in my investigation.

[Orion Pobursky]

I'll point out that this doesn't have to be a one person effort

[Magnus Forsberg]

I'll point out that this doesn't have to be a one person effort

Well, my approach has always been that if I want to change a primitive, I have to do the investigation.
I can't just upload a changed primitive, and expect someone else to find and edit all the affected parts.

[Max Murtazin]

IMO that wrong. They are differently used, and designed. And should be different. Editing them all, would create a bad result

Actually all numbers up to 13, if didn't misunderstood some of those primitives, are just different kinds of those liftarm insertions of different kind and/or to be used in different context.
Npeghole/2 are normal liftarm one, that have been worked on.
3/4 are used in the case when we have pinhole next to an axlehole. Can be seen on any thin liftarms, and is always smoothed
5 is similar to the 3 and 4, but is used with axle on one side, and some geometry on the other that doesn't add up to the 3 or 4. Example of this primitive is 32475, which does use smoothed edges of npeghole: https://www.bricklink.com/v2/catalog/cat...ge?P=32475
7/7a are just half variants of npeghole/2
8, 9, 10 and 11 are primitives for different alternating hole liftarms/connectivities, which all use smoothing on the npeghole in real life
12 and 13 are wider kinds of 2, and through I wasn't able to find example of usage, most likely they do follow the pattern

Only thing I'm unsure about usage of 6 series, but they look also like similar ones to listed on above, and then most likely will also use smoothed shape
 

When I reshaped the axle holes I edited my own library and then used them coloured.
1.) edit the primitive, place it in your own unofficial p-folder.
2.) hard code the edited prim in a "weird" colour
3.) remove the corresponding official primitive.
4.) examine the result. I used LDFind and LDStructure a lot in my investigation.

Thanks, will be helpful a lot. Both LDFind and LDStructure seem to be unavailable on Mac, are there any options for this system?

[N. W. Perry]

Thanks, will be helpful a lot. Both LDFind and LDStructure seem to be unavailable on Mac, are there any options for this system?

I will try and see if these work under Wine. MPDCenter does, so maybe…?

I use LDView's model tree view a lot to check structure, but of course it does far less than these two programs.

[Max Murtazin]

Well, my approach has always been that if I want to change a primitive, I have to do the investigation.
I can't just upload a changed primitive, and expect someone else to find and edit all the affected parts.

I know that changing primitive might cause some unexpected problems, and that's why I'm not touching part tracker at the moment

[Willy Tschager]

Well, my approach has always been that if I want to change a primitive, I have to do the investigation.
I can't just upload a changed primitive, and expect someone else to find and edit all the affected parts.

+1