Before I bend over too far trying to figure it out, is it possible to make a torus, using primitives, that is elliptical in the major radius but without changing the minor radius? I think it is not, because the minor radius is in ratio to the major radius, so scaling the primitive differently in X and Y will change both radii proportionally.
The same problem exists with rings, but you can get around that using different primitives, such as chords and n-discs, as I've done in the two files below. (I'm trying to make both a flat and a rounded version; I've figured out the L and the E, but not how to make the round-topped version of G and O.) So maybe there is some way using another kind of primitive?
I know, it is too early for presents. Nevertheless, here is one.
For the next version I will try to include a "cheat sheet" in the program. Search for "blender 3d cheat sheet" or something similar. Otherwise you can take a look here in the next year, when there is actually something to see.
...use a "stud" grid setting (Plate 1 x 1, Y = 8 LDU, XZ = 10 LDU half-stud).
...see an optional "x", "y", "z" on the coloured axes of the coordinate system (activate with "Tools..."->"Options..."->"Show Axis Labels", or with the 3D view context menu "View Actions"->"Axis Label").
...create a new file draft (Ctrl+Click on "New Part File"), without saying where it should be saved. When it is saved for the first time, the program will ask where to save it. Unsaved drafts are lost when the program gets closed.
...access a set of standard bricks, tiles and plates in the primitives view.
...benefit from a more precise unit converter (it avoids the division).
The following critical issue is fixed:
Creating/opening a project kept the "Part Review" active, when doing a review.
The program was tested intensively with "real world" files.
However, something can go wrong in about 140.000 lines of code.
Installation on Windows:
Download and extract LDPartEditor_win32_x64.zip
Run LDPartEditor-1.8.74.msi
Start LDPartEditor from the start menu
Installation on Linux:
Download and extract LDPartEditor_linux_x64.zip
Install ldparteditor_1.8.74-1_amd64.deb
Start LDPartEditor from the menu or via launcher
Installation on Mac OS X:
Download and extract LDPartEditor_mac_x64.zip
Mount LDPartEditor-1.8.74.dmg
Drag LDPartEditor.app to the Applications folder
Copy ldparteditor.sh to your home folder
4a. Open a Terminal.app and run ./ldparteditor.sh
4b. Or open a Terminal.app and run /Applications/LDPartEditor.app/Contents/MacOS/LDPartEditor
I listen carefully to your requests and possible complaints. Please leave me a message, with your thoughts and wishes to further improve the software.
LDPE is a 3D CAD application: The overall system requirements are higher. While I recommend to use a powerful 64-bit multicore system, it could be possible, to run LDPE on older machines as well.
System Requirements:
Minimum System Requirements:
OpenGL 2.1 compatible Graphics Card
Operating System (64-bit): Windows [7 or newer], Linux [e.g. Ubuntu Linux >=14.4], Mac OS X [>=10.6]
CPU: Multicore-Processor e.g. Intel Core 2 Duo or AMD Athlon II (>2.0Ghz)
RAM: 4GB
Video-Memory: 1 GB
Free Disk Space: 150 MB
Recommended Requirements:
Operating System (64bit): Windows 7,8,10,11, Linux [e.g. Ubuntu Linux >=14.4], Mac OS X [>=10.6]
OpenGL 3.3 compatible Graphics Card
CPU: Multicore-Processor with 4 cores (or more)
RAM: >4 GB
Video-Memory: >1 GB
Free Disk Space: 500 MB
For a faster start, LDPartEditor and the LDraw™ library should be installed on an SSD.
I know it has been present in LDD, but I can't find it now.
I could do a simple mock-up, but I don't have any information about the height, or image of the bottom view.
Guess the square hole on the back is stud sized.
Hello, I have a software friend who would like to process pairs of LDraw files and determine how they may interact. This is clearly part of the LDraw program, as the user interface allows users to do this; and so I am wondering whether that software is open source or a more experienced administrator could help us understand how to read and interpret the code. Would love any and all help in this direction. We are very excited.
I was checking the Mursten-era parts (the u80xx series) to see if they needed to be corrected with non-logo studs, and I was glad to see that Magnus has already submitted fixes for most of these. But after reviewing the research, I realized that this fix isn't necessary in some cases—specifically, the non-slotted bricks (u80xxa variants).
tl;dr—
Basically what I'm asking is this; read on below the break for more background.
The Mursten bricks in the official library have stud logos. Real-life slotted bricks generally did not have stud logos, but non-slotted bricks always did. Which library parts, if any, should be fixed to have non-logo studs?
For parts that existed both with and without stud logos (e.g., 1x2 slotted bricks), which variant should the official part reflect? Or, should a new version be submitted so that both are represented?
Now, back to our story…
It appears that stud logos were first added to the molds at the same time that TLG switched over to studded windows and doors—and thus bricks that no longer needed slots. Prior to this time, all the different available bricks had at least one slot, which means that all bricks without stud logos (with a few random exceptions* that probably aren't worth modeling) would have had at least one slot.
So basically you have two distinct periods for these early bricks:
Slotted bricks (Automatic Binding Bricks and early LEGO Mursten, c. 1949–1955). These had no stud logos (and their undersides had either no logo, or one of two general logo styles—plain or "dogbone"—but we don't model these underside details anyway).
Non-slotted "hollow-bottom" bricks (late LEGO Mursten and early System, c. 1956–1957. These had stud logos (and their undersides typically had no logo, but some molds also had a plain style underside logo).
After that, of course, you had the modern tube/post-bottom bricks starting from 1958.
There is one snag, though. There was limited production** of some bricks that had both slots and stud logos (and in some cases also underside logos!). In general, I think it's correct to model the slotted bricks without stud logos, but it's worth being aware that there are some real-life cases where examples of either can be found.
So, I've put together a summary of the Mursten-era bricks that are in the library and what I think their status should be. I'm starting with standard bricks; I need to dig a little further into beams and baseplates. Open to ideas and suggestions, of course! I. Standard bricks A. Non-slotted, hollow-bottom with stud logos (no fix needed):
Parts listed in bold are variants that have also been found with stud logos, mostly in limited cases as discussed above. The exceptions are u8001b and u8001c, which had a fairly mainstream production run—these two in particular might be worth having separate models for (or possibly leaving unchanged).
* The random exceptions are things like Swedish PRIMA bricks that had their own special molds. In fact, the only example I can point to off hand is the 2x8 beam, which was produced in Sweden without slots from a non-logo mold. (Ironically, this part would be u8005a, which is not yet in the library.)
** This mainly seems to be due to certain markets like Norway, which still sold slotted bricks after the changeover happened elsewhere, because they were still using these older molds after Denmark was done with them.
So I wrote this script in lua that takes all the parts in a ldr and moves them to their "rounded" location (I have a massive studio 2.0 file that I have been working on for a while, and a bunch of stuff is slightly out of place in completely different directions)
I tried the script, and it works perfectly, but I was wondering if there was a way to make it so that the individual parts of each submodel could also be targeted and align to the world grid.
btw i used another script by N W Perry as a starting point
![[Image: 15447.png]](https://img.bricklink.com/ItemImage/PN/11/15447.png)
