Search the Community

I propose to keep here an up-to-date ldraw.xml, the file used by LDD to convert to and from LDraw files. Download: latest version On Windows 32 bits: download and replace the one in “C:\Program Files\LEGO Company\LEGO Digital Designer\” On Windows 64 bits: download and replace the one in “C:\Program Files (x86)\LEGO Company\LEGO Digital Designer\” On Mac: download and replace the one in the “Contents\Resources\” folder in the app (open “Applications” in Finder, right click on the “LEGO Digital Designer” package and select the “Show Package Contents” option to explore the pakage folders). (Thanks manglegrat!) This file is also used and distributed with these tools: lxf2ldr C++/Qt version (both CLI and GUI), more options but needs to be compiled lxf2ldr.html HTML/JS version, works everywhere! If you have other modifications or additions, post them here or send me a personal message and I’ll include them to the benefit of all. If you need a part, feel free to ask here and I’ll try to add it (provided it exists in LDraw and LDD). History and Contents It’s based upon gallaghersart’s latest version (see this thread). It includes the modifications shutterfreak published in his thread. It uses some of the LDraw unofficial parts (mainly for new parts in LDD Brick version 2075). It includes some name corrections (because LDraw renamed or moved some parts, added new variants, etc.). I tried to more accurately convert the colors (now mainly according to Ryan Howerter’s conversion table). It’s not easy because all sources (Swooshable, Mecabricks, Ryan) don’t agree, and there are holes and overlaps. But as these differences, holes, and overlaps occur for rare colors or colors that aren’t available in LDD, it should be okay. In a megalomaniacal way, all the entries I have modified have an “SLS” at the end of their heading comments. New entries have an “SLS” at the front of the comments. So it’s easy to know when to blame me. As of 2016-09-16 and the big overhaul, I assume all the errors. Know Limitations As of LDD 4.3.9, flex parts (hoses) are not exported anymore (even unflexed). Minifig arms and hands are not connected in LDraw. I don’t know whose geometry is off (both?) but the shapes differ a lot. At least, hands are correctly connected to whatever they clip and arms are correctly placed in their sockets and somewhat wrap around the hands’s stems. Some variants are not recognized by LDD (e.g. clips, or tiles with/without groove, etc.) In those cases, I prefer to use the most recent variant in LDraw as it generally is easier to find and cheaper. Sometimes, several LDD parts correspond to a unique LDraw part. Sometimes, the transformation is accurate for one variant but not for another. For example, the Flag 2 x 2 is known to LDD as 2335, 11055, and 60779, but LDraw only has the 2335 variant. 2335 and 60779 use the same transformation but 11055 is vertically offset. I preferred to badly convert 11055 to 2335 rather than not convert it at all or badly convert 2335 and 60779. ldraw.xml is used both ways (LDD to/from LDraw). It’s not something I do frequently (too many resulting collisions) so it’s not well tested. One problem I can see is that, when several LDD parts correspond to a unique LDraw part, the conversion that’s listed last is the one that will be used. The reverse (first written is the one used) is true for assemblies that use the same subparts, in the same quantity (like electric cables). A lot of LDraw parts are simply wrong. Almost all the parts that combine System (studs and anti-studs) and Technic (pins and axles, and their holes) are wrong in that they assume the technic holes are at the same height than side studs (on the picture below, the circles are concentric). LDD assumes the holes are 0.2 mm (0.5 LDU) higher. In ABS, the holes are 0.12 mm (0.375 LDU) higher (dixit Jamie Berard in his famous presentation). In order to limit the number and magnitude of errors, LDD is considered to be right. How to write a new transformation for a part in ldraw.xml What? ldraw.xml is an XML file that defines how LDD can export to (or import from) LDraw files. It does so by defining a match between the part’s IDs and how to rotate and translate the part from one geometry to the other. Matches are defined by “Brick” XML elements. For example, this one says to LDD that the Brick 1x1 that it knows as 3005 is also known to LDraw as 3005: <Brick ldraw="3005.dat" lego="3005" /> (Note the “.dat” in the ldraw ID.) Matches are not needed if the part IDs are the same: the transformation element is sufficient for LDD to know the part exists. (So the example above is useless ) Rotations and translations are defined by “Transformation” XML elements. This one says to LDD that the Brick 1x1 just needs to be moved up: <Transformation ldraw="3005.dat" tx="0" ty="-.96" tz="0" ax="1" ay="0" az="0" angle="0" /> The translation (tx, ty, and tz) is in centimeters (0.8 cm is the width of a brick, 0.96 cm its height). The rotation is given by its axis (the line passing through and ), and its angle in radians. And all the coordinates are in the direct (“riht-handed”), Y points up, coordinates system of LDD. The transformation explains what should be done to import from LDraw besides changing the axes (LDD’s Y is up and XYZ is a direct basis, LDraw’s Y is down and XYZ is an indirect basis; so changing the axes only means changing the sign of Y). So, in an LDD to LDraw point of view, the transformation is reversed: it says what happens to a part if you don’t do anything to its coordinates besides changing the sign of Y. In other words, the opposite transformation has to be applied to the LDD coordinates of the part in order to get the LDraw coordinates (with Y reversed). Why? Each part has an orientation (which way up? which way left?) and a center, point of origin, or reference point (we’ll use “reference point” from now on). But LDD and LDraw don’t always agree. To know the orientation and reference point in LDD, insert the part without rotating it nor attaching it to any other part. It will be aligned along the scene’s axes (LDD’s axes). The reference point is near the mouse pointer’s head. To know the orientation and reference point in LDraw, I find LeoCAD the easiest tool: just select the part and its axes are drawn (X red, Y green, Z blue), starting at its reference point. Okay, LeoCAD’s «X, Y, Z» is LDraw’s «X, -Z, Y» but what’s another little change of basis? Sometimes, their disagreement is trivial. For example, for the simple 1x1 brick (3005), both LDD and LDraw agree: the stud is on top and the reference point is on the vertical line going through the center of the stud. But they differ for the height at which the reference point should be: LDD says it’s at the base of the brick, LDraw at its top (but at the base of the stud). (On every picture, X will be red, Y green, and Z blue.) So the transformation for that part is straightforward: if the LDraw part is imported as is, with only Y reversed, it will end up 0.96 cm (the height of the brick) higher than it should. So we have to lower it by 0.96 cm: <Transformation ldraw="3005.dat" tx="0" ty="-.96" tz="0" ax="1" ay="0" az="0" angle="0" /> Sometimes, their disagreement is more profound and the transformation is therefore more complicated. For example, for the musket (Minifig Gun Musket 2561), LDD puts the reference point in the handle and “up” means the handle is vertical but LDraw puts the reference point in the barrel and “up” means the barrel is vertical. Even more, the stock is on the wrong side, so X and Z are different too. With an identity transformation, the part is rotated by an eighth of a turn (X to Y) (π/4) around the Z axis to put the barrel vertical, and then by a quarter turn (X to Z) (-π/2) around the Y axis. After that, it has been translated up and horizontally. After calculations (see below), we’ll end up with this transformation: <Transformation ldraw="2561.dat" tx="0" ty="-1.72" tz="0.336" ax="-0.3574067443365933" ay="-0.8628562094610169" az="0.3574067443365933" angle="1.7177715174584016"/> How? So, how do we find the right values to have the correct transformations? What’s the ID? Having the right part Check the ID of the part in LDD. Check the ID of the part in LDraw. Beware of variants, LDraw uses a letter suffix (a, b, c…) where LDD totally changes the ID or keeps the same ID for new variants. Don’t hesitate to look on BrickLink for the part ID: BrickLink keeps a list of alternate IDs (when the same part has several IDs) and links to variants and notes. If the IDs are the same. Nothing to do. If the IDs differ. We add a Brick element: <Brick ldraw="123a.dat" lego="456" /> Don’t forget the “.dat”! That was the easy part. Which way is up? Finding the rotation axis and angle We start in LDD. Up is Y, or Y is up. X and Z are a bit harder to see on the LDD scene unless you use LDD’s developper mode (which has the LDD axes drawn at «0,0,0» as red X, green Y, and blue Z lines). Or, if you’re sure you didn’t move the camera in a brand new model/file, X is pointing bottom right, and Z bottom left. We place our part among other parts that we know will be correctly converted (like 1x1 plates, or harpoons ) to have references. Using different colors greatly helps! We export to LDraw… … and look at the results: We decompose the transformation in multiple simple rotations, around the X, Y, or Z axis. If it has been turned around X, a quarter turn from Y to Z is a positive π/2 angle. If it has been turned around Z, a quarter turn from X to Y is a positive π/2 angle. If it has been turned around Y, a quarter turn from Z to X is a positive π/2 angle. To make it short, it’s a direct (right-handed) basis. If you can’t figure out the problems with an existing transformation, “clear” it by using an identity transformation: <transformation tx="0" ty="0 tz="0" ax="0" ay="1" az="0 angle="0"/> (All zeroes but one of the a_ which is 1.) You can try each simple rotation one by one to be sure of their angles (especially their signs ). Beware, combining rotations change their axes (e.g. turning around first X then Y is equivalent to turning around first Y then Z). So if you check that the Y rotation is okay, then the X rotation, don’t forget to combine them as Y then Z. For the musket, we need two rotations: an eighth of a turn (π/4, 45°) around the Z (blue) axis that puts the barrel vertical, and then a quarter turn (-π/2, -90°) around the Y (green) axis. Or we can first make the quarter turn (-π/2, -90°) around the Y (green) axis, and then an eighth of a turn (π/4, 45°) around the X (red) axis. Remember, “import”-wise, we’re trying to find what should happen to the part in the LDD scene to be like the LDraw one, with the LDD axes (the harpoons ). My head is turning. Combining rotations If more than one simple rotation is needed, we have to combine them. For that, we’ll use quaternions. Eh come back! That’s not that difficult! A quaternion q can be written as q = a + b.i + c.j + d.k, where i² = j² = k² = i.j.k = -1 (so i.j = k = -j.i, j.k = i = -k.j, k.i = j = -i.k). a is the real part, b.i + c.j + d.k is the imaginary part. A rotation by the angle angle around the axis «ax, ay, az» is the quaternion q = cos(angle/2) + sin(angle/2).(ax.i + ay.j + az.k) Do note the 1/2 factor on the angle! To combine two rotations, we just multiply their quaternions and apply the rules above to end up with a a + b.i + c.j + d.k form (or, more accurately, a C + S.(ax.i + ay.j + az.k) form, where C and S are cosine and sine of the same angle and ax² + ay² + az² = 1 ). If we rotate first by q and then by p, the result is the rotation by p.q. Note the order: q then p is p.q. Multiplication is not commutative with quaternions: if you do it the wrong way, you’ll end up with the correct values but the wrong signs. There’re lots of fun to have with quaternions and rotations as quaternions. But what is said here is sufficient for our purposes. An example: Most of the times, we do π/2 rotations (quarter turns, 90°). angle = π/2 therefore cos(angle/2) = sin(angle/2) = cos(π/4) = sin(π/4) = √2/2; So, for a “horizontal” quarter turn (yaw, around Y): q = √2/2 + √2/2.j (as j/Y is the “vertical” axis). Let’s combine it with a half turn (π, 180°) around the X axis (IOW, upside-down): cos(π/2) = 0, sin(π/2) = 1, so p = 0 + i p.q = (0 + i) . (√2/2 + √2/2 j) = √2/2 i + √2/2 i.j = 0 + √2/2 ( i + k ) Now, let’s get the resulting angle: The real part of p.q, 0, is the cosine of angle/2. 0 is also the cosine of ±π/2 (±90°). Therefore, the resulting angle is π (180°). Now the axis, «ax, ay, az»: It’s the √2/2( i + k) imaginary part. That’s the vector «√2/2, 0, √2/2». We need to remove the sin(angle/2) factor. That’s easy as the sine of π/2 is 1. So our axis is «ax = √2/2, ay = 0, az = √2/2». Written in ldraw.xml: ax="0.707…" ay="0" az="0.707…" angle="3.1415…" Another one, a quarter turn around Y and then around X: q = √2/2 + √2/2 j = √2/2 (1 + j) p = √2/2 + √2/2 i = √2/2 (1 + i) p.q = 1/2 (1 + i) (1 + j) = 1/2 + 1/2 (i + j + k) We rewrite it as p.q = 1/2 + √3/2 (√⅓ i + √⅓ j + √⅓ k) to have a unit vector (ax² + ay² + az² = 1) in the parenthesis and to clarify the cosine and sine: 1/2 and √3/2. They are the sine and cosine of π/3 (60°). Therefore, the resulting angle is 2π/3 (120°). In ldraw.xml: ax="0.577…" ay="0.577…" az="0.577…" angle="2.094…" Back to our musket: An eighth of a turn (π/4, 45°) around the Z axis that puts the barrel vertical: q = cos(π/8) + sin(π/8).i = C + S.k Then a quarter turn (-π/2, -90°) around the Y axis: p = cos(-π/4) + sin(-π/4).j = √2/2 (1 - j) p.q = √2/2.(1 - j)(C + S.k) = √2/2.(C - S.j.k - C.j + S.k) = √2/2.C + (-√2/2.S.i - √2/2.C.j + √2/2.S.k) Wow! Hum, okay. So √2/2.cos(-π/8) is the cosine of half our angle. Get the calculator out… angle/2 = Acos(√2/2.cos(-π/8)) = 0.8589 Our angle is 1.7178. We “remove” the sine of angle/2 from our vector, so that p.q = cos(angle/2) + sin(angle/2).(ax.i + ay.j + az.k): ax = -√2/2.sin(-π/8) / sin(0.8589) = -0.3574 ay = -√2/2.cos(-π/8) / sin(0.8589) = -0.8629 az = √2/2.sin(-π/8) / sin(0.8589) = 0.3574 As an exercise, you can verify that ax² + ay² + az² = 1. So we did it right! Et voilà: ax="-0.3574067443365933" ay="-0.8628562094610169" az="0.3574067443365933" angle="1.7177715174584016" One step to the left. Getting the translation right Now that the part is correctly oriented, it may need to be moved. The translation is in centimeters (cm). 20 LDU = 0.8 cm. Values are often multiples of 0.4 (half a stud) for tx and tz and multiples of 0.32 (height of a plate) for ty. Other, finer, tunings are often in multiples of 0.008. If the rotation is complex, all bets are off In LDD, we try to place the part so that its LDraw up axis ends up up in the scene, and we try to align its LDraw X and Z axes with X and Z of the scene (at least, that it is not rotated by a weird angle). That way, moving the part along its axes is also moving the part along the scene’s axes. It will be easier for getting the translation right. For our musket, that means the barrel up. (I didn’t align the X and Z axes here because, yeah, I’m a warrior, I don’t need that. Besides, you’ll see what happens because of that. ) Again, I find it easier in LeoCAD: the key bindings, the coordinates clearly shown in the status bar, etc. The thing is, LeoCAD uses a direct Z up basis. So if you move «dx, dy, dz» in LeoCAD, you’re moving «dx, -dz, dy» in LDD (and vice versa). Confusing? Noooh. Anyway, choose your own poison but beware of its little quirks. To help fine tuning, using transparent colors greatly helps, especially for clip-bar connections. Now, we note the coordinates of our part in our LDraw editor and move it so that it ends up the way it should. We look how much we moved it. That’s it! Just convert it to cm (= LDU × 0.8 / 20) and we have our translation. Well, mostly, the signs are wrong. Remember: the transformation is what should happen to the LDD part to end up like the LDraw part, we just did the opposite and moved the LDraw part to be like the LDD one. Besides the signs, if you didn’t correctly align the axes, you’ll have to find which is which For our musket, we need to go up and sligthly to the “left” (from bottom right to upper left when your LDraw view is oriented as a new LDD file, as are all the screenshots here). That means negative dy and dx. But as the part is not aligned on X and Z (but still not badly rotated), the negative dx becomes a positive dz. Et voilà! <Transformation ldraw="2561.dat" tx="0" ty="-1.72" tz="0.336" ax="-0.3574067443365933" ay="-0.8628562094610169" az="0.3574067443365933" angle="1.7177715174584016"/> (So, okay. I had to try first tx then tz, both negative and positive, before I found the right one. But I didn’t want to have to remake the pictures! There: I’m not a warrior, I’m just lazy.)

Studio 2.0 (or rather, "Part Designer") is able to export to LDraw. Unfortunately Bricklink has chosen to roll out their own standard for texture mapping, rather than following the official spec. I do not care for the reason for Bricklink to go this way. It personally took me almost a month to implement it, so I fully understand if they wanted to choose something less complex. Instead I would like to dedicate this thread to converting between the two formats. In order to do this, we have to understand the format that Studio exports to. If you want to jump directly to a live demo, then please click "3D" on the page I have set up here. When creating a new part in Part Designer, you can choose either "Minifig", "Decorated Part" or "Create Part From Scratch". I will start with "Decorated Parts" and take the two other options later. Update! The new location for Studio2LDraw is https://brickhub.org/i/apps/studio2ldraw.htm Using the checker.png by Nils from the LDraw forum and some basic gradient picture, I have created test files for most of the decorated parts currently available from Part Designer The Studio "LDraw" File Format - Findings Exporting to LDraw from the Part Designer will result in .dat files containing something along the lines of: 0 FILE studio_test_1_8_checker.dat 0 Brick 1 x 8 checker 0 Name: studio_test_1_8_checker.dat 0 Author: 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 BFC CERTIFY CCW 0 PE_TEX_PATH -1 0 PE_TEX_INFO iVBORw0KGgoAAAAN(...)uQmCC 1 16 0.0000 -24.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 s/3008s01.dat 3 16 -80.000 -24.000 -10.000 -80.000 0.000 -10.000 80.000 0.000 -10.000 0.045 0.955 0.045 0.045 0.955 0.045 3 16 -80.000 -24.000 -10.000 80.000 0.000 -10.000 80.000 -24.000 -10.000 0.045 0.955 0.955 0.045 0.955 0.955 Please note that I have inserted the "!LICENSE" line in order to ensure that the files may be shared and used. The commands "PE_TEX_PATH" and "PE_TEX_INFO" are proprietary from Studio. I have not yet found a "PE_TEX_PATH" command that does not say "-1", so let's ignore it for now. The other command has a base64 encoded picture as the argument. The geometry lines have one sub part (in this case "s/3008s01.dat") and 2 or more triangle lines. I have yet to see any file being generated with quads, lines or any other content after the encoded picture. The Encoded Picture The base64-encoded picture is not simply the picture you upload to Part Designer. It will be processed. I have found that the encoded picture is scaled up and has been given a transparent border. I do not know why the border is added - perhaps someone can give me some insight here. Computing Projections In the LDraw specification you have to specify how to project a texture onto underlying geometry. Unfortunately the exported LDraw files from Studio do not contain any other information than what I have stated above. You thus have to take each part one-by-one and compute your own LDraw TEXMAP projections. I have found the following heuristic works for most of the supported parts (see exceptions in the section below): 1) Take the minimal axis-aligned 3D bounding box of all the points of the triangles. Call this box B. Let Bx, By, and Bz be its length along the X, Y and Z-axes, respectively. 2) Expand B by 10% in each direction to account for the border introduced to the picture. 3) If 2*By < Bx and 2*By < Bz, then assume the projection should be performed on an XZ plane. Otherwise, project onto an XY plane. 4) No matter the projection, choose the points for the planar projection defined in the LDraw specification to be corners from B. Exceptions: 2x4 Brick and 2x2x2 Slope For the parts "Brick 2 x 4" and "Slope 2 x 2 x 2" you can choose two pictures for decorating the front and back of the part. For the 2x4 brick, the two pictures get merged into a single picture - the front picture on top and the back picture below. There will be 4 triangles in the LDraw file - the two first for the front side, and the other for the back side. For the 2x2x2 slope, the two pictures also get merged into a single picture, however, this time they are side-by-side: Front picture on the left and rear picture on the right. For both exceptions, I have had to introduce "magical numbers" in order to get a proper alignment of projections. Please see the source code here for how to compute projections in JavaScript for the buildinginstructions.js project. Non-Standard Alignment of Sub-Part and Geometries Please take a look at the line for the sub part: 1 16 0.0000 -24.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000 s/3008s01.dat The positioning is off: Normally you would place the sub part at (0, 0, 0), but here it is at (0, 24, 0). This position has to be translated so that the sub part is at (0, 0, 0) in order for the custom part to appear correctly. You have to subtract the position of the sub part from all the positions of the triangles as well. By following the observations above, I have been able to create the converter from Studio LDraw to standard LDraw as seen in the source code here for. This is what powers the 3D viewer here. As you can see, there are still some precision issues - most noticeably on the 1 x 8 tile where the "10% rule" doesn't seem to work perfectly. Another issue is that I cull textured surfaces on transparent parts, while Studio does not. Please tell me if you have other observations. My plan for now is to continue with Minifigs.

Hi all, I just released an extra portable version of lxf2ldr: lxf2ldr.html (still on gitlab, next to its brother, and also in GPLv3+). Yes, .html like in HTML/ECMAScript (aka JavaScript) but it’s totally local and self-contained! No compilation, no dependencies, no web server or arcane application (well, except for a d/recent web browser). Just download the zip (or tarball…), unpack it somewhere and open the file lxf2ldr.html in your browser. (See the senseless green/yellow coloured bar ? Click on the little cloud just below, on the right, just next to “Find File.”) Okay, okay, the look is spartan but it gets the job done. Tell me what you think… or not BTW, this is the initial release, I haven’t tested all the cases / stumbled upon all the of the language (two days on this and I know why I hadn’t touched JavaScript since the last century), so any issue, bug, glitch is welcome.

Update July 2024: My described tool here is considered DEPRECATED as the ldraw site has implemented a functionality to download complete .zip files with all needed subparts / assemblies. Scenario: You are in the situation in which you miss some LEGO parts in Studio but have seen them in LDRAW (unofficial) library. Maybe you tried to resolve all the references to all sub-assembly-files once by hand or had a look at the dependencies with some other tools - as I am working in IT and love to automate things and thought "I can't be bothered with doing this manually". And as I want to contribute something back to the lovely community of people I put it online in May 2022 and gave it some little updates inbetween: The LDraw to Studio Exporter (https://www.reum.it/ldraw-to-studio-exporter/) Description This tool is designed to import parts which are available in LDraw, but not in Studio. From the LDraw part number, it zips all relevant sub elements (there can be many!) into a part pack. Howto Visit the LDraw Parts Lookup Search for your part of choice & copy the number Enter this number into the below searchfield A list of all fitting parts from the catalogue will show up - clicking the entries will create a zip package with just the needed parts To use the packs, unzip them and place their contents in your "C:\Users\{your username}\AppData\Local\Stud.io\CustomParts" (Windows) The parts will then be available in Custom Parts palette of Studio Screenshots Entry-Page Example result for query "47373" Details of the zipfile structure of an example part Here is an example of the structure and the needed subparts for one Shock Absorber ("47373-f1"): Some example results as direct links of parts missing in Studio: 65151-f1.zip - Technic Shock Absorber 11L Soft (Extended) 65151-f2.zip - Technic Shock Absorber 11L Soft (Compressed) 47373-f1.zip - Technic Shock Absorber 11L/9L (in Extended Position, not Pre-Tensioned) 47373-f2.zip - Technic Shock Absorber 11L/9L (in Extended Position, Pre-Tensioned) 47373-f3.zip - Technic Shock Absorber 11L/9L (in Compressed Position, not Pre-Tensioned) 47373-f4.zip - Technic Shock Absorber 11L/9L (in Compressed Position, Pre-Tensioned) Updates January 2023: Fix: Nightly refresh of LDraw unofficial files working now, it was buggy before and stuck on the releases from ~August 2022 version Feature: Unofficial files may be downloaded via a new checkbox. Searches are exclusive here, so having the checkbox set means it only goes through the unofficial list (but may grab sub assemblies from the official, where needed) UI: Added Dark Mode awareness UI: Added Font-Awesome Icons for downloads UI: Some tweaks (all professional webdesigners: hush hush, nothing to see here... don't look at my nasty css quirks :P) May 2023: Fix: Textures are now included (they werent before..)

Are there any Digital / comic creators out there? I know they exist, I belong to them on Discord. Kind regards

HOW IT IS WORK: Manage your LEGO set collection, and build an inventory of the parts in those sets. This is remastered version of application with this same name that was brought to as by Jim Valavanis on SourceForge. Is focus on work without internet. Protect user privacy as much as possible. Connection with outside is used when images, price guides must be downloaded. Information about sets | parts can be imported from *.xml file /BrickLink order/ or from *.csv file /BrickLink or Rebrickable set data/. DISCLAIMER: Use at your own risk, i decline any responsibility for anything that may happen to you using the program. DOWNLOAD: Runnable version /Windows platform/ The LDraw images used as parts images GitHub repository 2018-02-18: Add LDraw support Update db_urls.txt Upgrade GUI Improved missing image file download Fix some bugs

Some questions: Is there an Blender importer that can read LDraw models? Does the importer make use of grouped instances? How is the performance when modeling in Blender? Is the framerate when editing comparable to LDCad? Would it be possible to create a library of parts as grouped instances? Thanks!

It looks like the LDraw official parts library doesn't contain any of the Mixels-type parts that contain a towball socket (e.g. 14418, 14419, 14704) even though unofficial parts have been in there for close to 4 years now. Has anyone done any MOCs in LDraw using these unofficial parts? Any problems? I ask because the one time I tried installing unofficial parts I somehow messed up my parts library so badly that I had to reinstall LDraw entirely, so I am wary. Also, looking at the review comments for the unofficial parts, it looks like the part editors reeeally hate these sockets for some reason. Anyone know why that might be? These parts are dead useful.

I am pleased to share with all of you a brand new Ldraw-based digital designer for iPad that I have spent many hours over the past few years on! Masonry is a 3D brick creation app with access to Ldraw's 5000 part library and it supports freeform editing and step creation. I've got a video of it in action, and you can see more details at my website: https://masonryapp.com Thanks!

Hi everyone, may be you can help me: I am looking for the new LEGO Boost parts for LDD or LDraw. I would like to start with some projects and it looks like, there is no update available. Any ideas what i can do? Thanks, Michael

Hello LEGO® fans, I like to post my latest research test. I started 2014 with Modo and LDRaw and passed my ideas and results to Nicolas 'SCRUBS' Jarraud, the french genius who gave us Mecabricks, and he developed a very nice Blender addon what gives us access to high-end renderings out of the box. A long time I ignored Blender but since last year we switched to this impressive open source application for my animation studio pipeline. Therefore I started to learn Blender and it's worth any minute because this is really a serious competitor for all other commercial 3d applications. Just the fact that Blender is a 108MB ZIP archive and starts in a second makes it very special. It has everything you need for animation and visual effects. I am not a Blender professional yet because I am running my studio as a CEO and actually I started an upcoming professorship at a private university. And I have a family with two kids. So it's a miracle that I am posting here. :-D Rendering Digital LEGO® is my personal project called Renderbricks what brought back all my passion for 3d. I wished the day had 48 hours. Due to my activities with Renderbricks I try to post constantly work starting with Facebook, updating flickr, posting on Twitter and adding to ArtStation to get as much attention and followers as possible. This is a time consuming process what needs a lot of patience and energy to keep the project running. And three years later now I will have a call with The LEGO Group next week because an Innovation Director is interested in my work. I am excited. :-) With Renderbricks I am also in touch with a lot of nice people. Actually a programmer is developing a Modo importer for LDRaw what looks very promising. I am also in chat with GitHub user TobyLobster who developed ImportLdraw for Blender. This addon is really fantastic. And I have a lot of contacts to MOC designer but of course I can't render everything. Researching LEGO® never ends. Here's another stress test with Blender. And I am impressed again about this open source software what beats most commercial competitiors in many aspects. This amazing LEGO® ISD Aggressor model by Matthew 'raskolnikov' Benner has 14.531 parts with instances and 56.489.080 triangles in Blender. The scene size is compressed saved only 91.306 MB. The render size is 15.360 x 8.640 pixel (15K). CPU Render time on a Dual Xeon 12 core is 2h 13min only with the latest Blender build and the Denoiser. This is really insanely fast. The key here is the new Denoiser technology in the latest 2.79 release what helps to keep samples low at 64 in Branched Path mode. The performance of the Blender scene is amazing. Compared to Modo much faster overall. No refresh issues. Real time handling here on my DELL with GTX 780. Fast loading and saving. And here all bricks have real bevels. In Modo they use a rounded edge shader. I guess the plastic material needs a bit more SSS because the Modo results look a bit better actually. I have ordered two GTX 1080Ti Founder's Edition to speed this up :-) Here you can download a wallpaper for your specific screen. Click on the picture and click again too zoom at 100% to enjoy the 15K details.

I've just discovered an issue with instructions I have been making. I use LDraw/MLCad to design models, and then LPub4/3D to produce instructions, but have found that one specific part (26603 Tile 2x3) is not showing up in the BOM or PLI in LPub3D. The part shows up normally in LPub4, while in LPub3D (which I need in order to split BOM across pages) it is showing only in assembly images and is absent from PLI and BOM. Can anyone shed light on this issue for me? Is anyone else having the same problem with this part?

I'm in the middle of learning Blender, but I stumbled upon Poliigon and was blown away. I'd really like something to aspire to once I've got a grasp on the basics, so has anyone tried applying a Poliigon texture to a Lego render of any sort?

Year by Year I take many lesson, when developing LICreator. But I go to this software in the end. It is written in Java. So will be platform in-depended, what is in Java technology nature. But I testing and build LDraw Instruction Visualizer only on Microsoft Windows Seven with 64 bit architecture. What this tool can do: %APPDATA% for Windows platform or User Home Directory for others as Storage Can hide | un-hide selected parts Display part description Rotate on selected axis Exports steps as single images and many more ... A use JLDraw as starting point of my journey. It is Simple LDraw models viewer, written and abandoned by Mario Pascucci in 2014 year. I try get new life to this software, and make them better... that software, I currently stop working on... for many reason. At the current level of development, this program can calmly serve as instruction player. Everyone, stay tuned for updates. EDIT 1: This software strongly depend on LDraw file format standard. If model do not have STEP command. You can see, only one step on the list. EDIT 2: LEFT BUTTON for selecting single part RIGHT BUTTON for context menu SHIFT + LEFT BUTTON for select more parts CONTROL + LEFT BUTTON for toggle section ALT + LEFT | RIGHT BUTTON for rotate all parts in currently displayed step MOUSE WHEEL for zoom out | zoom in EDIT 3: Move application source to GitHub repository LDraw-Instruction-Visualizer

While building #5540 Formula 1 Racer model, I had some trouble finding the exact position of the two gray plate of the motor. I've positionated them at the 54° angle on the 3938 1x2 hinge top, and then I found that the one on the right (viewing from the bottom of the model) appears to be "well" positionated with value X 200 Y 48.625 and Z 40.625. The plate on the left (ever viewing the model from the bottom) instead has the position values of Y 11.375 and Z 40.75. You can argue the pieces are not parallel, but in the editor they appear right. Where I'm wrong? Thanks for the answers, PN

Hi all I'd like to present a viewer for LDR/MPD files on Apple devices. The idea is to open files which are already present on device in Dropbox, Google Drive, email and so on. App allows to view model from different angles, zoom, rotate or "disassemble" it to view internals. Line to iTunes https://itunes.apple.com/us/app/studless/id1039486304?ls=1&mt=8 Opinions and/or complains are welcomed

Hi there. What programs do you use for LEGO 3d designing? LDD or Ldraw? Let me know :D

Finally, after a long hiatus there's a new official LDraw parts update. Here's the full 'press release':

Shackleton's Endurance in Minifig Scale In August 1914, Sir Ernest Henry Shackleton started an incredible expedition to the Antarctic.This voyage is also known as the Imperial Trans-Antarctic Expedition. Endurance was the name of the ship in which Sir Ernest Shackleton sailed for the Antarctic. On board were 28 men and 69 dogs. Shackleton planned to cross the Antarctic on foot. But shortly before its arrival in the Antarctic the Endurance became locked in ice and was finally crushed. Thus the legendary survival of Shackleton and his crew began. Length 166 studs (131 cm) / Width 50 studs (39 cm) / Height 103 studs (81 cm) Built with LDCad 1.6 alpha 4 / Rendered with POV-Ray Shackleton's Endurance by Papacharly by Papacharly

I am trying to import my LDD model to Bricksmith which uses LDraw database, but tire (tyre) 61254.dat is missing. I checked the LDraw database and I cannot find a correct file with the tread and all. Can someone point me to it? Much appreciated. Here is the Bricklink reference: http://www.bricklink.com/v2/catalog/catalogitem.page?id=84621#T=C Here is what I found: http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/61254.dat Apparently it needs the tread file 61254s01.dat somehow used along with it, which is linked from within the 61254.dat link, but I do not know how to use them in combination. I copied them both to my Bricksmith/LDraw parts directory, but it's not coming out right. I'd appreciate some help, hopefully a fully compiled 61254.dat file or a solution to my problem. Thanks in advance. Miro

Greetings,LPub3D 2.0.14 is released. LPub3D is an Open Source WYSIWYG editing application for creating LEGO style digital building instructions. It uses the LDraw parts library, the most comprehensive library of digital Open Source LEGO parts available and reads the LDraw LDR and MPD model file formats. LPub3D is available for free under the GNU Public License v3 and works on the Windows Operating Systems. Portions of LPub3D are based on LPUB© 2007-2009 Kevin Clague, LeoCAD© 2015 Leonardo Zide.and additional third party components. LPub3D can run under POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD using WINE HQ. You can download from sourceforge.net or check for updates in your existing installation. LPub3D 2.0.14.838.2 Features and enhancements ------------ Fix: File reload after external source change breaks page drop-down combo dialogue(r837) * When a file is reloaded after being changed by an external source, the drop-down menu for selecting a page doesn't work until after navigating using another method. Fix: Image orientation does not conform when page orientation changed to Landscape (r836) * Image generation was not inheriting the proper page size values. Fix: Extra characters "%3" in margin meta and page size meta does not display the page size identifier(r835) * Oops, allocated the page size identifier variable to the wrong meta - should have been allocated to page size meta instead of units meta (units meta is used for setting the margin). Consequently, the page size meta is missing the size identifier (A4, Letter, etc...) because the place-holder to pass the variable is not there. This must have happened during the patch process from the maintenance branch because it did not present during my tests. Both issues are now corrected. Cheers,

Hello, I was trying to import my LDD file to 3DS max, but everytime when I render the object I get this. Can someone help me to get this right? Greetings, Tom

Greetings, LPub3D 2.0.13 is released. You can download from sourceforge.net or check for updates in your existing installation. Interesting fixes are the ability to switch part occurrence (times used) in the PLI between per step and per submodel on called out and submodel pages; the ability to insert one-to-many non-faded models (e.g. with alternate attachments/views etc...) when fade step is on; and new meta for pages size including the standard identifier - e.g. A4, Letter, Legal etc... and print/export performance improvements. LPub3D 2.0.13.834.2 Features and enhancements ------------ Fix: Logging options added to Preferences (r832) * Select logged attributes and logging levels. Fix: Prompt search directory settings reset (r831) * Prompt to inform that the search directories have been reset after the search directory reset button is clicked. Restarting LPub3D is not required. Also changed menu items "Reset 3D Viewer Model Cache" to "Change Temp File Cache" and "Reset Image and Model Caches" to "Reset All Caches". Fix: Inconsistency between part counts in submodels and part counts in call-outs where multiple instances are involved (r829) * For submodels, the PLI part counts reflect only one instance of the submodel, even if multiple instances are used in the same step. The instance count is correct, and the BOM has the correct total number of parts. With this update, sub-model pages displaying instance count now have a context menu option to display parts per step/page or not (total parts consumed by the number of instances indicated. Previously, for callouts, you have the options (see context menu) to display parts list per callout (one instance) or not. When you select no parts list per callout, the PLI will show all the parts consumed by the total number of instances in the callout. If you choose parts list per callout, the PLI is moved to the callout and only the parts for a single occurrence of the callout is shown. The idea here is if you have 5 occurrences of the called out assembly, you'll need 5x the parts total, but only 1x parts are shown to indicate what you need to build an instance of the called out assembly. On sub-model pages displaying the instance count, there is only one behaviour for PLI counts (the most intuitive) which is to display the parts list per step. This is intuitive because the primary role of the PLI is to show what you'll need to build an occurrence of the step shown - it is not the intention to mimic the BoM. Nevertheless, I added a context menu item to not display parts list per step and instead display total parts consumed by the number of occurrences of the submodel in the parent submodel/step. Fix: Page size and orientation processing update (r826/833) * Further industrialization of the print/export module. This update streamlines the process and realizes some performance gains. There are some key changes. Notably, page orientation and page size are now mutually exclusive. This means when switching from Portrait to Landscape, accompanying the orientation meta with a transposed page size meta no longer required or managed. Here is an illustration: Previous behaviour when editing a page size change required the following meta commands: 0 STEP 0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE 0 LPUB PAGE SIZE LOCAL 11.0000 8.5000 Note that the page width and height have been transposed. Going forward, transposition of the page width and height when switching from Portrait to Landscape is automatically managed by LPub3D. NOTE: This update is NOT backward compatable. An accompanying transposed page size meta to indicate the switch from portrait to landscape as shown above will be treated as a new page size meta for that page. Consequently, using this meta to 'switch' orientation will actually result in NOT switching the orientation as LPub3D will automatically switch again the switched page size meta. If the user is only interested in changing the orientation, the proper meta command going forward will be: 0 STEP 0 LPUB PAGE ORIENTATION LOCAL LANDSCAPE To help with accurately displaying the page size identifier in the setup and context menus, the standard page identifier is now appended to the page size meta command. For example: 0 LPUB PAGE SIZE 8.5000 14.0000 Legal 0 LPUB PAGE SIZE LOCAL 8.5000 11.0000 Letter 0 LPUB PAGE SIZE LOCAL 5.8000 8.3000 A5 0 LPUB PAGE SIZE LOCAL 5.8678 8.3456 Custom Along with the width and height values, if the page size is non-standard, the identifier "Custom" will be automatically used. Additionally if an identifier is not present, the identifier "Custom" will automatically used. The page identifier is displayed in the Page Setup dialogue and Size/Orientation change context menu dialogue. Also, the LPub3D print/export function no longer needs to parse the model file to capture, in advance, page sizes. This capture is performed during the existing page parse and load functions and is exposed to the print routines during printing/exporting. This change was necessary to better enable mixed-size page export/printing where it is necessary to 'look ahead' to get the next page's size and orientation parameters in order to configure the printer engine before processing the page. Fix: Expand INSERT MODEL meta command behaviour (r825) * When using part fading LPUb3D will now process multiple INSERT MODEL commands rendering the CSI content at each command. For example, if the instruction document includes different model attachments, the editor can now include a non-faded image of the entire model with each attachment. Here is an example of he proper command sequence when used in conjunction with BUFEXCHG: 0 BUFEXCHG B STORE 0 //... default model content... 0 STEP 0 BUFEXCHG B RETRIEVE 0 BUFEXCHG A STORE 1 0 445 -46 -10 1 0 0 0 1 0 0 0 1 attachment1.ldr 0 STEP 0 LPUB INSERT MODEL 0 LPUB INSERT PAGE 0 STEP 0 BUFEXCHG A RETRIEVE 1 0 0 0 0 1 0 0 0 1 0 0 0 1 attachment2.ldr 0 //STEP These last 3 lines are optional when editing the model file. 0 //LPUB INSERT MODEL If they don't exist and fade step is ON, they will be automatically created by LPub3D 0 //LPUB INSERT PAGE Fix: The PNG output of a model with various page orientations is not correct (r824) * Cleared page buffer before rendering each page. Also corrected a typo causing page range to sometimes not work for image exports. Cheers,

When producing instructions from LDraw files using LPub4 I usually use the 'Treat as Part' function for minifigures, contained as submodels within the LDraw MPD file, so that they show up as single parts in the PLI and BOM. However, I sometimes get a parse error in LPub4 when doing this, with the result that the minifigure does not get drawn in the PLI or BOM. Does anyone know what causes this error, or how to fix or avoid it?

This is a fictional space-themed LEGO shopping mall complex named "The Spaceship" due to the shape of main building resembling a spaceship. If that naming idea had come sooner I would probably have designed something that actually looked more like a spaceship, but the idea only came to me more than halfway through the project when I saw what shape the building was taking so I just used the idea to name and style numerous parts of the model. The model uses approx. 175000 parts and 258 custom sticker designs and measures 3810mm x 3493mm x 519mm (13.3m² footprint). It features 30 shops, 218 car parking spaces, 500 minifigs, bank, post office, library, cinema, amusements, restaurant, foodcourt, admin/security office, service access, maintenance areas, escalators, functional elevators, toilets, ice rink, gymnasium, boating pond, custom brick-built road layout, and real LEGO lighting in most of the main building and ice rink. The design attempts to be as functional as possible by providing convenient car access, separate rear public transport access, and separate rear service vehicle access to all shops on the first two levels, as well as multiple entrances and fire exits. It also attempts to be wheelchair/buggy friendly as much as possible using a mixture of stairs, escalators, ramps and a glass elevator. The main glass roof can be removed in two halves, as can the roofs of the gym, the wing shops, and the rear section, the latter of which reveals the battery packs for the LEGO lighting. There's also manual cable winders on both the customer and service elevators. I managed to get the water tank in too but had to forego the boiler room - despite the size of the build I found myself running out of space. The massive size of the model caused numerous problems, especially due to buggy software and PC limitations, so I had to reduce the intended length of the mall and forego a few other features too, but it's still by far the biggest model I've built. It probably should have taken around 6 to 9 months to complete, but due to personal and technical issues it ended up taking more than 2 years. This virtual LDraw model was built using MLCad software and rendered with LDView (sadly it's too big to render with POV-Ray), with additional construction, graphic and animation support via the use of PHP, LDraw Sticker Generator, LDraw txt2dat, LDraw LSynth, ImageMagick, Paint Shop Pro, GIF Movie Gear, IrfanView, PNGOUT, AviSynth, VirtualDub, and ffmpeg. Even had to use Excel to write macros to compute the precise angles needed for the curved window walls on the wings, which were too difficult to compute on paper. And no, I don't intend building it for real! Links: Flickr (lots more images) YouTube (looks better at 720 resolution) The video contains still images and many flyby sequences which give a better impression of the model by restoring some of the 3D visual cues lost due to the non-raytraced renders containing no shadows. Excuse the length of the video and number of images. It's a REALLY BIG model, and 25 images just wasn't going to do it... This is my first post here, and may well be my last! - during the uploads of the more than 200 images the PC terminally died and the remainder of the uploads and this post had to be done from a Raspberry Pi.