+- 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)
Trouble with adding new primitives. - Jude Parrill - 2013-08-02
OK, so I've been working on some new primitives called stud4c, stud4c1, stud4c2a, stud4c2p, and stud4c3 (all .dats). Now, I have tried to insert these into a part, but keep coming back with the same error. Every time MLCad comes back with "File stu24c*.dat not found! Continue loading?" For some reason, MLCad keeps changing the "d" in "stud" to "2", for each of these files, and I have no idea why.
Here's what's interesting though, if I press "Yes" to continue loading, a bounding box that appears to be the correct size shows up, but with no geometry inside. I've tried changing it's color, but it still doesn't show up.
For the record, I have the primitives located both in the same directory as the file I'm editing as well as in the "p" directory.
I've checked the file name, the "Name" part of the header in the files, and name on line in the file a dozen times each. They are all correct. Why won't these load properly?
Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-02
Doh, of course as soon as I post this I figure it out. Stupid MLCad is apparently trying insert "Fast-Draw" primitives, which I never asked it to do. I'll probably just re-name my primitives to avoid this altogether. I'll leave this up as a lesson for future part authors: don't name your primitives stud*.dat unless you're prepared to write fast-draw versions of them (and such a thing is appropriate for them). For my primitives, it isn't really appropriate.
Re: Trouble with adding new primitives. - Philippe Hurbain - 2013-08-03
Quote:For my primitives, it isn't really appropriate.In that case just duplicate your stud* primitive to stu2* and MLCad will stay quiet...
Underside detail - was Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-03
OK, so this topic is going to evolve...
So the primitives I came up with are for the larger sized bricks (4xX, 8xX, etc....). My idea was to create reusable primitives for those underside studs with fillets between them. (Currently, these bricks just use the regular underside stud primitive with boxes, which leaves lots of extra spaces and edgelines which shouldn't be there. Essentially, I created a "basic" one which could connect to others on all sides. I then created similar primitives which connect with a wall on 1 side, 2 parallel side, 2 adjacent sides, and 3sides... basically similar to how rect primitives work with edgelines.
True Story: I totally missed the stud4fxx primitives at first, so I created a similar structure myself. Once I realized what they were, I was able to cut out about 3/4 of my file and replace it with that.
However, as I worked on this and looked for new files that could use these primitives, I came across part 30400 (Brick 4x18), which includes a more detailed underside which I'd seen before (although this part also had extra spaces and edgelines everywhere). When I was starting this project, I was trying to decide how thick the fillets should be, so I took out some real 4x6s that I owned. What I discovered was that I actually owned two types of these: one with the "basic" underside, and another with more "webbing bits" similar to 30400. Bricklink has a picture of this with 8x8s:
![[Image: 2403.jpg?1]](http://www.bricklink.com/TL/2403.jpg?1)
However, there are not seperate numbers for these types of parts. I wish there were, because that would make this much simpler. Now part of me says, "The simple version is good enough"... but that would also mean editing out all the detail currently in the 4x18, which I think might make some of that part's authors/editors angry. Another part of me wants to go all out and do the detailed version for all of them. Of course, the Philo inside me says that's probably excessive.
So, this now brings me crashing back into regular and "fast draw" primitives (stud* and stu*). I'm beginning to think now that the "simple" versions should in fact be fast-draw and more complex versions the "regular."
I'm getting tired of thinking about all of this (it's making my head hurt), so I figured I'd get some feedback from you guys, see what you think.
TG: Edited title
Re: Trouble with adding new primitives. - Max Martin Richter - 2013-08-03
Well, I just did these parts 4201, 4202, 4204 today.
If you check the primitive reference of J.C. Tchang you will find something what you have searched.
Note that the shown s\30072s01.dat isn't a prim. So there is no fastdraw for it.
/Max
Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-03
Yes, I have already completed those parts (I BFCed them as well). The question I'm having is about whether we should use just the "simple" underside studs or make the more complex ones like the right-hand 8x8 pictured above.
Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-04
Alright, the new primitives are finished and have been uploaded to the PT. The updated parts that use them have been e-mailed to Chris, so he should have them up soon as well. Let me know what you think.
Re: Trouble with adding new primitives. - Chris Dee - 2013-08-04
Thanks, Jude, for your work on this.
I think that what you have created (stud4c, stud4c1, stud4c2a, stud4c2p and stud4c3) are more than studs. Since they internally reference the stud4f* primitives, which have their own stu24f* versions, these new primitives don't need low-res versions themselves, but by naming them stud* forces that. We don't have such nested references to stud* primitives at present and the level of complexity this introduces is unnecessary.
Through their use in the six official part updates that you sent me, I think they do deserve to be primitives. So, I think they would be better named something else and avoid the need for low-res duplicates. In low-res mode the references to stud4f* will use the stu24f* files anyway.
I will rename these new primitives to stux4... (stud extended), delete the stu24c* files and update the official updates that you sent.
Can anyone verify the underside of 30072? Does this have plain ribs or "+" ribs? If the latter, this should be re-worked to use these new primitives.
Re: Trouble with adding new primitives. - Jude Parrill - 2013-08-04
Thanks for the reply, Chris.
I do tend to agree that they are more than just studs... they're more like "underside architecture." Now, initially, I did just create the "low-res" versions and thought about leaving it at that.
The problem arises out of the fact that for some (possibly all) of these parts, there are two variations: the "low-res" version and the "high-res" versions. I personally own both variations of the 4x6, and the above photo from Brickshelf proves that there are two versions of the 8x8 as well. I do not own and haven't found proof of the others (although I haven't really looked that hard), but I don't think it's a stretch to imagine the others might have this same variation as well.
Now, none of this would matter if LEGO had given them different part numbers, because then I could just create both versions seperately. Unfortunately, they didn't. Further, it wouldn't have bothered me as much if one of the already official parts (30400) wasn't already "high-res."
Still further, I could have simply created a regular, "low-res" version "xxxx.dat" and a "high-res" version "xxxxh.dat" (or something similar). Except somebody already did this with Baseplates, and everyone started arguing about precidents and not wanting to have multiple files for the same part. (Never mind that some parts have 2-3 or more numbers on the PT due to aliases.)
So, I set out to create a solution that would allow us to have both versions without causing problems on the PT. Is it perfect? No. But I can't think of a better way to do it. If anybody can, I'm open to suggestions.
P.S. I've started working on Steffen's solution to the Baseplate problem (although I'm going to have to make some small modifications to it in order to allow for rounded corners). Look for more on that soon.
Re: Trouble with adding new primitives. - Chris Dee - 2013-08-04
If these large bricks really do exist with and without the added detail, then we do have a way of handling that - use 2356a and 2356b.
The baseplates are a different issue. The lack of underside detail was a gross simplification at the very birth of LDraw, before many of us had the computing power to render those complex features. There has always been some simplification and the modeling non-functional details is not a requirement. I can see why, these days, realistic rendering of the underside of baseplates cild be desirable.
I'm not sure what"Steffen's solution" you refer to (a link might have been nice), but please post your ideas here first, before cluttering up the Parts Tracker with another set of baseplate revisions.
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".