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


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]

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.