LDraw.org Discussion Forums
Trouble with adding new primitives. - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Trouble with adding new primitives. (/thread-9471.html)

Pages: 1 2


Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-04

Alright, so Steffen wrote this on all of the new "Underside Baseplate Primitives", such as this one. I'll break it down it down here.

Steffen Wrote:(A) Replace the current p/studbp1.dat ... p/studbp3.dat with a single file studbp.dat which contains the top as well as the bottom stud.

In a different comment, he also wrote:
I find it not a good idea to put the stud into the top left corner of the surface portion. I would have expected it to sit in its center instead.

I have implemented these two suggestions to make the new file studbp.dat which has equal spacing all around (10x10 ldu) with a stud on top. However, because this is square, in order to accomodate for corner studs, I've had to create a second primitive I'm calling studbpc.dat (the "c" is for "corner") which includes the complete construction for the corner (e.g. it also has the side wall).

Steffen Wrote:(B) Add studbpp01.dat, which is the same as studbp.dat, but has a white spot pattern. This way, files studbp.dat and studbpp01.dat become analogous to stud.dat vs. studp01.dat

I haven't done this yet, but think it's a good idea. It shouldn't take very long, just need to copy and rename my studbp.dat appropriately and make a few small adjustments.

Steffen Wrote:© Optionally, add a "coarse" version of (A) and (B). That "coarse" version could leave out the bottom stud detail to speed up rendering time.

I've done this as well, at least for the studbp.dat and studbpc.dat. They just have a bottom and top quad with a stud on top. I've named them stu2bp.dat and stu2bpc.dat.

Steffen Wrote:(D) Add baseplate stud groups...

Also started on. I've been doing a bit of duplication so far, stugbp-MxN.dat and stugbpc-MxN... the first just has regular studbp.dats, and the other has a single studbpc.dat in one corner.

Steffen Wrote:(E) Refactor JC's *h.dat baseplate versions as follows:
- delete the *h.dat duplicates of the normal baseplates
- refactor the normal baseplates to use the primitives created in (A)-(D)

Actually, I was thinking I'd leave it and let you admin-modify the name to be correct again so that there wouldn't be two versions on the PT, but if you'd prefer I gave them their correct names and e-mailed them to you, I could do that as well.


Overall, I think Steffen's plan was a good one. But if you have objections, let me know.


Re: Baseplate underside detailing - Chris Dee - 2013-08-04

I prefer this to be optional, as described here, but am willing to listen to counter-arguments.


Re: Baseplate underside detailing - Santeri Piippo - 2013-08-04

I'm beginning to think that with edge cases like this we could have a sort of add-on library "patch" which replaces these parts with hi-res versions. I don't think we should bloat these huge parts which commonly appear at least once with tons of non-functional detail for the average user, not at least in the default library.

This add-on patch then could have hi-res versions of parts for users who really care about this. We could also solve other cases like this. I recall there was one commonplace thing with non-functional detail in common bricks but I don't recall exactly what it was... did it have something to do with stud logos?


Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-11

Research: It helps.

So I did some... although it was spurred on by something I noticed in my parts list. I noticed that the brick 4 x 6 (2356) had an alias 44042 already made official, and this got me wondering. So I went and pulled out my real bricks and examined them under better light and sure enough, the non-detailed version was 2356 while the detailed version was 44042. So, I decided to go open up 44042.dat and lo and behold, a comment:

0 // Alias of 2356. 44042 is a new variation of the 4x6 brick, but the changes are
0 // not considered significant for the LDraw library.

Not significant, eh? So why, then, are parts like 30400.dat and 47116.dat including them? Fact is, these details should exist, and I intend to re-work 44042 to be the part it should be: "Brick 4 x 6 with Detailed Underside."

And this got me wondering further, what about the other parts I updated? Do they have alternatives with detailed undersides? So I went to my old friend Bricklink. First I checked under 2356 and sure enough, they had 44042 as an "alternative" name. Moving on 6212 (4x10) didn't have an alternatives names, but 4202 (4x12) did - 60033. We already know 30400 (4x18) is detailed. 4201 (8x8) which I figured should have one based on the picture did: 43802. 4204 (8x16) did as well: 44041.

As a result, I intend to create/edit the new "detailed" versions, and then use the plain version for the older versions.


Re: Trouble with adding new primitives. - Santeri Piippo - 2013-08-11

I don't have a lot to say on this fillet matter as I mainly focus on Technic stuff but the name qualifier is usually "Reinforced" rather than "Detailed".