(2022-04-23, 21:11)Max Murtazin Wrote: 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?

(2022-04-24, 12:47)Orion Pobursky Wrote: Can you elaborate a bit more on this?

(2022-04-24, 19:55)Orion Pobursky Wrote: 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.

(2022-04-23, 21:11)Max Murtazin Wrote: 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?

(2022-04-25, 6:38)Philippe Hurbain Wrote: 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-part-lookup.html?folder=parts&partid=39369)
...Or we could go the other direction and completely remove beam npegholes like LEGO does in his building instructions!

(2022-04-25, 7:34)Max Murtazin Wrote: 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

(2022-04-25, 14:58)Orion Pobursky Wrote: 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.

(2022-04-25, 14:58)Orion Pobursky Wrote: 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.

(2022-04-25, 15:10)Max Murtazin Wrote: What problems might arise, for example? Currently I see ~20 primitives that just need to be updated, and not much problems updates might cause

(2022-04-25, 15:23)Magnus Forsberg Wrote: 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:

(2022-04-25, 15:33)Max Murtazin Wrote: 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

(2022-04-25, 16:46)Philippe Hurbain Wrote: You can make it work in the middle using cyli primitives instead of quads. But that's not possible near the corners.

(2022-04-25, 17:20)Max Murtazin Wrote: 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

(2022-04-25, 17:38)Philippe Hurbain Wrote: 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.

(2022-04-25, 17:53)Max Murtazin Wrote: 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

(2022-04-25, 18:23)Philippe Hurbain Wrote: Attached my proposal...

(2022-04-25, 18:23)Philippe Hurbain Wrote: 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...

(2022-04-26, 7:38)Philippe Hurbain Wrote: Looking more closely, looks like the corner rounding should be even more prominent (Even though real shape depends on parts)

(2022-04-26, 12:07)Max Murtazin Wrote: 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

(2022-04-26, 7:38)Philippe Hurbain Wrote: Looking more closely, looks like the corner rounding should be even more prominent (Even though real shape depends on parts)

(2022-04-26, 16:11)Gerald Lasser Wrote: 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

(2022-04-26, 18:15)Philippe Hurbain Wrote: Good idea, why didn't I thought of it ???

(2022-04-26, 18:47)Philippe Hurbain Wrote: ...but I don't see how to fit a matching ndis. no 8\tang are defined...

(2022-04-26, 19:54)Max Murtazin Wrote: Maybe it's the time to define those then?

(2022-04-27, 8:44)Philippe Hurbain Wrote: 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.

(2022-04-27, 9:19)Max Murtazin Wrote: What's the deal with 48\tang?

(2022-04-27, 9:43)Philippe Hurbain Wrote: 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.

(2022-04-27, 9:43)Philippe Hurbain Wrote: 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.

(2022-04-27, 13:36)Gerald Lasser Wrote: As there is no prim substitution doen on the level of lo res prims, then we do not need a tang, imho.

(2022-04-27, 14:55)Philippe Hurbain Wrote: You have a point... But then using a cylo has a very limited interest  . Looks excellent nonetheless!

(2022-04-27, 16:26)Max Murtazin Wrote: 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

(2022-04-27, 20:03)Gerald Lasser Wrote: Yes, it's mostly to reduce clutter in the code

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

(2022-04-29, 20:16)Max Murtazin Wrote: If anyone don't have anything to suggest, I'll update other primitives tomorrow

(2022-04-30, 8:37)Magnus Forsberg Wrote: 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?

(2022-04-30, 10:47)Max Murtazin Wrote: All up to the 13 have one same element this topic was about fixing.

(2022-04-30, 10:47)Max Murtazin Wrote: I will go through all the parts using those primitives, but for that I need primitives themselves to be on my hands

(2022-04-30, 16:10)Orion Pobursky Wrote: I'll point out that this doesn't have to be a one person effort

(2022-04-30, 11:53)Magnus Forsberg Wrote: IMO that wrong. They are differently used, and designed. And should be different. Editing them all, would create a bad result

(2022-04-30, 11:53)Magnus Forsberg Wrote: 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.

(2022-04-30, 16:46)Max Murtazin Wrote: Thanks, will be helpful a lot. Both LDFind and LDStructure seem to be unavailable on Mac, are there any options for this system?

(2022-04-30, 16:28)Magnus Forsberg Wrote: 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.

(2022-04-30, 16:28)Magnus Forsberg Wrote: 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.