I am trying to find the torus2.dat file for the rollercoaster 10303 model, where 3 parts are missing.
I am still on that torus2.dat file.
where do I find that one?
I'm very new to LDPartsEditor (<1 day), but I seem to be missing how to perform what seems to be an easy task. Namely, how to split a given triangle/quadrangle along a specific axis.
For example, given the following part, I simply want to make the yellow side (right) look like the orange side (left). I tried to combine two triangles into a quadrangle but then couldn't see how to divide that in the manner desired. Tried splitting a triangle, adding vertices...
We currently have 6 Part Type for the !LDRAW_ORG statement. They all, in my understanding, refer to a specific folder in the library:
Code:
Part => parts
Subpart => part/s
Primitive => p
8_Primitive => p/8
48_Primitive => p/48
Shortcut => parts
This is what I'm enforcing in the submit validation on the tracker.
Additionally, the Name: line is supposed to have the folder below parts/p in the name (e.g. 48\1-4cyli.dat).
Therefore if a part is an 8_Primitive it should be in the p\8 folder and have the name of "8\<filename>.dat".
There are, however, parts in the library that do not meet this standard. I thought I corrected most of them but bug report by Willy revealed this problem to be much more widespread that I had originally thought. The list follows. While this is easy to correct, a list this large is making me think that perhaps I'm being too strict with validation and this is not a rule we should enforce.
Looking through some parts, noticed that there is, surprisingly, no sphere layer primitives. I think it could be useful for cases, which uses spherical geometry other than the full sphere, half, quarter or 1/8. So, here I present those.
General naming scheme is n-16sphely. n-16 is used same way as in flat circular primitives, and can be n-8 or n-4, while y stands for the layer of sphere. Picture below shows layers from 1 to 4, left to right:
Every pattern I create (which admittedly isn't that many yet) seems to involve passing through the SVG format at some point. But we're still missing a tool for converting SVG graphics directly to LDraw, and I know there have been a couple started already. (Img4Dat has planned SVG functionality, SvgToDat I believe handles basic primitives only, etc.)
My proposal is to start with the single task of converting SVG paths to vertices that can be imported, say, into LDPE at a reasonable resolution for mesh generation. And since SVG paths are really just a combination of cartesian coordinates (rel or abs) and Bezier control points, all that's really needed is a way to take the cubic Bezier math and make a polyline out of that—perhaps with an option between points evenly spaced, or according to curvature (so that tighter curves get more points). Best of all, that information is already stored in a nice, human-readable xml format within the svg file.
The use case for this arose when working on this part. I was able to lift those vectors directly from the official instruction booklet, put them into Inkscape, export a PNG and trace that manually in LDPE. But how much faster if I could have taken the paths themselves (or the xml data from inside the svg file) and drop them into a tool in LDPE, maybe adjust the precision a little bit, and instantly have the vertices I need to triangulate the pattern!
I'm thinking—in fact, I'm sure—that the math part of this has already been worked out many times over, and all that's missing is to code it in a way that's specific to LDraw. If we only focus on converting paths (which, again, is really just converting Bézier curves), then it think it becomes much easier to tackle than trying to incorporate the entire SVG spec into an LDraw tool, because a lot of that is probably stuff we can do more or less by hand.
So who's up for the challenge, and how can I help? I never learned to code, though I do understand programming languages generally. I just don't know a git from a commit from a pull request. ;-) And I'm not fluent in math, but I can figure out problems on an ad hoc basis, or at least look up the answers!
I know we have put a lot of effort into the new 3817b/3816b - Minifig Legs by obsoeting the old 3817/3816 but the new geometry with the sloped backside is clearly wrong:
Any ideas how to correct the part without the need to reverse the whole conversion?
![[Image: LDPE-Example.png]](https://i.postimg.cc/Gtnh74RF/LDPE-Example.png)
