Search the Community

As suggested by papacharly, here's a topic about LDcad to discuss and help each other. What is LDcad? LDcad is an LDraw cad program being developed by Roland Melkert. The current version is 1.4, which can be downloaded here. For more information about LDCad, visit the website (and make sure to read the quick manual!). The features are (copy/pasted from the website): Windows and Linux support. Multi-threaded (background) loading of parts. Fast detailed real-time 3D rendering. Basic part snapping on growing collection of (official) parts. Integrated portable flexible parts support (springs, hoses, bands). Script based animation. Full MPD Support. Part grouping. Part ghosting. Nested editing. Relative grids. Multiple file editing (open as many files you like). Instruction stepping support. Full undo/redo. Copy/paste from to other LDraw software. Highly customizable part and color bins. Growing collection of example models. From my own experience, LDcad is quite difficult for beginners and can be quite unintuituve. This may sounds harsh, but it is (from my experience at least). But, if you get through the difficult part, a wonderdful piece of software is available to you and when you know to do, it's actually quite easy. Almost as easy as LDD (if we use that as a benchmark for easiness). It feels a bit like SR3D builder, but it doesn't have the user-friendly way of animation. It doesn have other nice features. It's really worth to take a look at! Roland is most active on the LDraw forums, so if you want to directly talk with him, I recommend going here. Of course, you can post all comments, questions and disscustions regarding LDcad in this topic too. So, this is the topic on EB to talk about LDCad [continuation from the LDraw sets topic] LDcad is quite nice. I've been using it for the past few weeks and I'm quite happy with it. Btw, make sure to turn on part-snapping if you haven't already, in my experience it makes building a lot easier. I just tried to find this setting, but I can't find it anymore. Maybe it's turned on by default nowadays, I can remember I had to set it on... Oh, and if you set Anti Aliassing on the edges on (AA), it makes the view a lot better

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.)

Please read the guidelines! GUIDELINES Type the number, name and theme of the model (I prefer Brickset themes) at the top of your post. This topic only makes sense if you give a link to your model, so other people can download it Put a picture of the virtual model in your post. Say if there are errors, if there are, tell what the errors are. Not too big pictures, please follow the EuroBricks guidelines. One set in one file. So not one set in 2 files, or 2 sets in file. The set should be build using the original instructions. Exporting models from ldd is forbidden unless you have the permission from the original author. Pleas do check everything very, very carful (also the inside of the model), because the export is not very accurate. Models like Montly Mini Builds or Club models are allowed. software files/programs that are allowed MLcad SR3D Builder Leocad Bricksmith BrickDraw 3D LDCad

I'm posting this here as I've found few similar threads about file format conversion in this section, but I haven't found a tool that would fit my requirements. I'm looking for a way to batch convert whole library of parts into FBX or OBJ so the parts can be imported into the Unreal Engine 4 project. I don't want to import whole models, I want to import whole library of parts. I have implemented parser that can interpret the ldr file format, build the model structure of parts with transforms and partially draw those parts, but there are some issues with rotation in the transform (and I'm not a graphics/engine programmer), but more importantly this approach is a bit heavy on the performance. From the legal side of things, I need a way to distribute my projects without the parts, but there needs to be a way for the user to put the ldraw files there on his own. The closest thing that could be useful is this: https://github.com/Pomax/WebGLdraw but that's from 2012 and I've seen some basic shapes defined in 2016 so It might not be the best choice to invest into making a batch converter based on this. Any thoughts on how would you approach such issue?

It was suggested elsewhere that I share some of my models on Bricklink Studio Gallery as a way to try and draw interest to my LEGO Ideas project, but I'm running into some problems with Stud.io missing parts and being unable to handle custom parts bundled as subfiles due to ignoring geometric primitives. Presumably I could move some parts into Studio's Unofficial parts folder, but it seems like that would then not visualize correctly if shared via the Gallery. Any suggestions on possible workarounds?

I know there is a blender script that can import LDR (LDraw) models into Blender, but I'm looking for the reverse. I'm looking at using Blender to create (or modify existing) minifig head gear so that I can use them within some digital builds. Is there an (easy) way to export the completed part as a custom LDraw part so that I can use it in MLCad/LDCad?

LDraw Files for Shupp's XXL Train Wheels Download links: XXL Flanged and Blind: https://bricktraindepot.com/resources Myself and a few others expressed interest in using Shupp's XXL wheels in digital form, so I decided to give LDraw part creation a try. Instead of designing the part directly into .dat format I used Solidworks to create the wheels, exported them as .stl files, and converted them using a python converter script (https://github.com/HazenBabcock/stl-to-dat). Please note these are not perfect, and may have slight differences from the real product. Included below is a picture of the wheels next to a Big Ben Bricks XL wheel and a Lego L wheel. Since I designed these in Solidworks I can export them in many 3D/CAD formats. So if anyone wants these wheels in a different file type, just let me know. ***UPDATE: First of all, many thanks to @supertruper1988 for hosting these files on Brick Train Depot! Secondly, I have ordered some XXL wheels so I can take my own measurements and make a more precise model. I should have the wheels by mid April and have the new files made soon after. Unfinished_Projects

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.

I finally completed my most complicated LDCad animation to date It is a fully animated 8860 LEGO technic 'super car' set. You can watch it here (2:15 long). https://youtu.be/Ea1iHCSPbqo (Some how youtube messed with the quality though, the original x264 mkv is much sharper) It is an OpenGL export, I was originally planning to do a POV-Ray rendering (I've got the POV file) but it would take over 200 hours to render as it would need very high radiosity settings to prevent background flickering. This would result in 3750 frames of this quality: Fullsize img: http://www.melkert.net/img/mel/8860.png If anyone know of a way to reduce that flickering without having to crank the radiosity settings to 11 please let me know.

I have just released first version of Pattern Folder. It is a simple Javascript based tool to add curvature to LDraw files. See how to use it in the video below. How to get started (as shown in the video) 1) Go to https://brickhub.org/i/apps/pf.htm and add your sticker. 2) Use a file, URL or simply paste the content of your LDraw file. Please note that only line type 0, 2, 3 and 4 are supported. Sub-files (type 1) and conditional lines (type 5) or any other digital file format are not yet supported. 3) Click on the surface of your choice (or type in your own. Click the various surfaces or see the video to learn how). 4) Download your folded LDraw file. Bonus See building instructions for the Corvette here: https://brickhub.org/i/224 Building instructions for the Porsche 911 RSR is found here: https://brickhub.org/i/193 (not all stickers made yet) Pattern Folder is 100% free to use, copy, improve, and eat (dietary restrictions may apply). It is also free from advertising and complies to GDPR because it doesn't track anything, nor take ownership of anything you use it for. I have added an ad to the video in order to pay for the website hosting. GitHub project: https://github.com/LasseD/PatternFolder Feel free to make pull requests, raise issues, fork, clone, etc. Please feel free to post ideas, suggestions, missing patterns, bugs, ... or if you think this kind of tool is a stupid or great idea.

New version (0.9.4) January 1, 2018! Go here for the download page. By using JWrapper, LDDMC now runs on both Windows, Mac and Linux, 32bit and 64bit, and without having to install Java. This software has been some years underway. Since I started this request topic, many have contributed with ideas and other input which has helped me developing this mosaic software. Features include - Build your mosaic by either following the instructions in app, by printing, by exporting to LDD or by exporting to LDraw. The in-app building guide (or magnifier) is customizable and can look like this: - Build mosaics using plates, bricks, tiles, and even SNOT. By request I have added a lot of building techniques through the years. 1x2, 1x3, 1x4 and 2x2 plates from top and side are included in the building techniques options menu. Here is how the mosaic looks if you build using SNOT: - Manage exactly which colors you want to use. You can import the latest colors from Rebrickable... or even make your own (if you can work out how the colors.txt file is formattet). You can filter the shown colors using various filters. Here I have filtered out all transparent, old, rare and chrome parts from the color picker: - Change input picture directly to improve the mosaic. You can modify colors, size, building technique, dithering percentage, crop, and even a series of color filters in order to fine tune your mosaic. The changes you make are reflected in the mosaic almost immediately! - Full save and load functionality. You can even export snapshots of the mosaic like in LDD. - Automatic updating to latest version (thanks again to JWrapper) The software is written in Java and the full source is available at GitHub here. If there is anything you want improved, or if you have feature requests, then don't hesitate to either write in this thread or to me directly (lassedeleuran@gmail.com)

One year ago I presented a virtual version of submersible JAGO (see here). Now I am able to proudly present a real life brick built version of JAGO. And some new renders (Pov-Ray, based on LDraw) too. For the brick built version I had to manipulate some original parts: Dome 4x4 #86500 and Round Plate 6x6 #11213 are not available in yellow. So I had to re-color these parts by using a color spray can. JAGO is a submersible primarily dedicated to exploration and research in marine sciences. See homepage JAGO. Hope you enjoy it. Regards Papacharly

Some of you might be aware of Datsville, a ~20 year old community project aimed at creating a multi-user town in LDraw. There's a historical page dedicated to it at LUGNET, and a GitHub project with recent activity. There are also a Facebook page and a Flickr photo stream. Some recent discussion has appeared on the LDraw.org forums and LUGNET. What we need, however, is more submissions! If you'd like to create and submit a new model please drop us a line. Note that all submissions need to be licensed under a Creative Commons BY-SA license or public domain. There are high resolution 8192x4096px versions of the above images on Flickr if you click on the download link and select "Original Version".

Hi everybody I'm new in this forum. I would like to submit you the results of my hard work. I'm writing a new Cad for building Lego models on your PC. It's FREE and has many useful features you cannot find in any other such application like LDD or MLCad. Maybe someone already known it. Watch videos and download it from http://staff.polito.it/sergio.reano/ please feedback your impressions (good and bad!) and your hints I will answer in 2-3 days... enjoy building Sergio

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. 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 there, I've put my latest python code which can convert letters, text and font data into Lego builds on github - you can find it here...https://github.com/pennyforge/Leg-o-letters Enjoy Oh..Merry Christmas!

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, wanted to share this little gem we put together: https://beta.makerbrane.com/tools/ldraw-viewer/ It opens .ldr, .mpd, .dat into an online 3D viewer, you can then change the background color and angle and export snapshots. It also converts the file into MakerBrane format, and opens it in another viewer with a different rendering style. It can also open in the 3D MakerSpace which is like LDD or mecabricks but more of a Universal Digital Builder because it has parts from other systems as well - but it you can't edit everything because not all the LEGO parts have been fully referenced yet for auto-snapping yet. Promising though, right? If you try it, post a screenshot here and let me know if there are any features we should add.

I was asked to put together a tutorial on rendering LDraw-produced models in POV-Ray in as clear and simple a way as possible. Although the following might seem a bit lengthy, I have tried to keep it clear, which is what caused it require a lot of explanation. I plan on updating things and changing things as time goes on and as people give me their input, so as to create a useful guide for everyone here on Eurobricks. NOTE: To give an idea of how long these images can take to render, I will be adding the render time of each image to the tutorial. As I don't rely on POV-Ray's anti-aliasing, I have rendered each image at 2880x1620 with AA set to off, and then crop and resize the image afterwards. For computer spec comparisons, I use an Intel Core i5 running at 2.67 GHz, with 4GB of RAM running at 1333 MHz and an NVIDIA GeForce GTX 460 with 1GB of RAM. I'm also using POV-Ray 3.7, which can take advantage of more than one CPU core. Contents Introduction Requirements MLCad (including LSynth and SR 3D Builder) Special files LDView Setting up POV-Ray Rendering your model in POV-Ray (including lighting and effects) Downloads More information Version history 1. Introduction Unlike LEGO’s own Digital Designer (LDD), which can currently only output an image of exactly what you can see within the LDD window, LEGO models created using LDraw can be turned into high-quality and, in some cases, photo-realistic images. This brief tutorial covers some of the basics of converting files created in LDraw and other compatible programs into something that looks almost real. As an example throughout this guide, I will be using a model I made in MLCad of the tipper from 4201 Loader and Tipper, which can be found here. 2. Requirements Regarding operating system, I currently use Windows 7, so this tutorial will be written to mainly accommodate Windows users, and I shall assume you are using a 32-bit version of Windows with the default installation path for LDraw. For anyone using a 64-bit version, when referencing folder paths please use “C:\Program Files (x86)” instead of “C:\Program Files”. Firstly, if you do not have it installed already, you need to install the LDraw All-In-One Installer, which contains the following programs required for this tutorial: The LDraw parts library MLCad, used for building the models LSynth [optional], a system for building flexible parts within MLCad LDView, used for converting models into a POV-Ray file LGEO, a parts library built specifically for POV-Ray POV-Ray, a ray-tracer that can render 3D models in high-quality You can find the installer here: http://www.ldraw.org/ This will install everything within the "C:\Program Files\LDRAW" folder, although POV-Ray will get its own installation folder. More information on this installer can be found at http://www.holly-woo...w/aioi1-en.html At the moment, the installer seems to install POV-Ray 3.6, but if you're using a computer with multiple CPUs then it would be worth downloading and installing beta version 3.7, as this can make use of more than one CPU. This can be downloaded from http://www.povray.org/beta/ and is installed in the Program Files folder, but installs the "ini" and "include" files in your My Documents folder. Although it's still in beta, I've had no issues when using this to render images. 3. MLCad MLCad is a user-interface for the LDraw system, and makes it easier to create virtual LEGO models than hand-coding the location of each piece. It’s not as straight-forward to use as LEGO Digital Designer, but the parts list contains a greater number of “older” pieces, you ultimately have complete control over brick placement as LDD-style collision is ignored, and (if you’re feeling adventurous) you can even recreate LEGO elements yourself, if they have not been created already, and submit them to the LDraw parts lists. It is missing a number of more recent parts, but new elements are always being submitted and can be downloaded and installed fairly easily. There are many excellent tutorials on how to use MLCad, so I won’t cover that here. However, there are a few settings within MLCad that I use that you may find useful. Firstly, under Settings → General → Change... and then on the Step, Grid, Snap tab, I set the values as below: The coarse settings are left at MLCad’s default setting. The medium settings are changed to 1 unit per step, and the rotation angle is set to mimic the rotation of the new-style locking hinge pieces, which can be set at angles of 22.5 degrees. 11.25 degrees gives you slightly more freedom when using the old-style hinge pieces, but the correct angle is easily set for the locking hinges, which can be reproduced in sets of two rotations. Finally, the fine settings are set very low, so that I can accurately place items that have been rotated. Of course, if you find MLCad’s default settings enough, then they can be left as they are. I then set up the parts tree to something more useable, under Settings → Parts Tree → Tree Configuration…, although this can be quite time-consuming and if you accidentally reset the tree you cannot easily get the settings back, as the information is stored in your computer's registry. For ease of use, I have created a group file that automatically adds the values for you, an explanation of which is available in the “Downloads” section. 3.1. LSynth If this is installed alongside MLCad, it will allow you to render flexible elements, such as hoses, and store these within your LDR and MPD files. It has a bit of a learning curve (pun not intended), but once you’ve got the hang of it, it can really improve models that contain flexible parts. A modest example of what it can do can be found here in a Technic model that I’ve rendered. A good guide can also be found at http://www.holly-woo...utorial-en.html 3.2. SR 3D Builder A lot of people use SR 3D Builder as an alternative to MLCad, as it uses a system that is a little more like LDD. It uses a file format called L3B, which is essentially the LDraw format but with a bit more functionality. These files can also be opened within LDView, but certain special elements created within SR 3D Builder (such as rubber hoses) cannot be displayed using LDView, and therefore cannot be exported to POV-Ray for rendering. As far as I’m aware, SR 3D Builder does not recognise the LSynth library of parts. 4. Special files There are a few special files that are installed with the All-In-One installer which need some adjusting before rendering your model in POV-Ray. LGEO.xml This file contains all of the colour and element definitions for when LDView is exporting a model to the POV-Ray format. The default version is missing some colours, so I have created a more complete version, which can be found in 8. Downloads. Simply replace the default version with this one, and you will have more of LDraw’s colours available to render with. This needs to be saved to “C:\Program Files\LDRAW\LDView” lg_color.inc This file is installed into LGEO's program folder, in the "lg" sub-folder. It contains definitions to all of the colours of the bricks that POV-Ray uses, as well as information on element finish (transparency, reflection, etc.). The default one does not render accurate LEGO colours, so a replacement for this one can be found in 8. Downloads. This needs to be saved to "C:\Program Files\LDRAW\LGEO\lg" 5. LDView Once you have completed your model in MLCad, open LDView and locate the model file (either an LDR or MPD file, or L3B is you have used SR 3D Builder). Depending on how good your graphics card is, you should see a representation of your model that looks better than the one shown in MLCad. As LDView also displays the LEGO logo on element studs, you can use this to check to see if they are set to your desired rotation, as this will carry through to the POV-Ray render. Settings-wise, there is little that needs tweaking here, as it is mainly just for visual effect. However, you can set a better default angle, as LDView’s default is more top-down than the default one in MLCad, and when you export the model to POV-Ray, it will use the angle you currently have your model rotated to. Select View → Viewing Angles → Specify latitude/longitude, and enter your desired values. As I said, I like the default MLCad 3D angle, so I use latitude 23 and longitude 45, although latitude 30 works well with some long, low models, such as cars. Click OK and then go back to View → Viewing Angles and then click Save Current as Default. Now, when you open any model within LDView, it will always be initially displayed at this angle. The model I will be using as it appears within LDView: Render time: N/A 5.1. Exporting to a .pov file Now that you have your file open in LDView, click File → Export. This will bring up a dialog box which allows you to specify where you wish to save the exported file. It also has a button called Options..., which allows you to define various parameters. This is where you can set the aspect ratio for your render, and gives you some specific options: 5:4, 4:3, 3:2, 5:3, 16:9 and 2.35:1. I tend to go with 16:9, as that’s the ratio that modern widescreen TVs and monitors tend to use. It’s important that you remember which one you use, as you will need to set up another file in POV-Ray to account for this. There are a few other options to choose from here, and I use the ones shown below: Once you’ve chosen your settings, click OK and then from the Export window click Save. This will create a .pov file at your chosen location, using your chosen file name (by default this is the filename of the model you were looking at in LDView). 6. Setting up POV-Ray 6.1. Image resolution presets The first thing to set up is the file that contains the default resolution presets. If you are using POV-Ray 3.6, this will be located within the “C:\Program Files (x86)\POV-Ray for Windows v3.6\renderer” folder and will be called “quickres.ini”, and this cannot be edited from here, so you may need to copy the file to your desktop first and then open it from there. If you’re using POV-Ray 3.7, this can be edited within the program itself, as it stores it in you user area, so you can just open POV-Ray and select Tools → Edit resolution INI file. Open this file with a text editor and you should be able to see a list of screen resolutions, listed in this format: [1280x1024, AA 0.3] Width=1280 Height=1024 Antialias=On Antialias_Threshold=0.3 The first line is the name of the preset, and this is displayed in a drop-down box within POV-Ray. The following lines are the actual settings themselves. Copy and paste one of these settings to another location in this file, so we can create a new preset. You can leave both Antialias and Antialias_Threshold alone, as these are best left at default. If you wish to create an image that matches the aspect ratio set within LDView, this is where you set it. As I prefer to render in 16:9, then I need to make a width and height that matches this. So, for example, an image that is 1280 pixels in width must be 720 pixels in height, so you need to change this for your new preset, resulting in something like this: [1280x720 16:9, AA 0.3] Width=1280 Height=720 Antialias=On Antialias_Threshold=0.3 I add the 16:9 comment to the preset’s title, just to make it easier to see the ratio. If you’ve had to edit this from your desktop, then just copy it back to the original location. 6.2. POV-Ray INI file (3.7 only) This file is the one that contains the paths to the LGEO pieces that POV-Ray utilizes in rendering. If you’re using POV-Ray 3.6 it should already have the right paths in it. However, if you’ve manually installed the POV-Ray 3.7 beta, then it needs to be set up. Open POV-Ray and go to Tools → Edit master POVRAY.INI, and this should open the file within a text editor. At the bottom of the file, you need to insert three lines to ensure that POV-Ray can locate the right files. These are: Library_Path="C:\Program Files\LDraw\LGEO" Library_Path="C:\Program Files\LDraw\LGEO\ar" Library_Path="C:\Program Files\LDraw\LGEO\lg" Don’t forget that if you’re using a 64-bit operating system to make sure that the path uses "C:\Program Files (x86)".

As an FYI for any users of LPub3D, an update (version 2.2.1) was recently released. This release seems to have addressed issues I had been experiencing with getting LPub3D to successfully render images using "faded" parts in versions 2.1 and 2.2. It appears to have also remedied an issue related to using POV-Ray to render images and POV-Ray is now successfully working for me to render images. My installation is a Windows 7, 32 bit machine, so you may not have been experiencing the same issues. The most recent version of LPub3D is available for download at https://sourceforge.net/projects/lpub3d/ Regards, David

Hi there, I've been working on some code to allow of the conversion of textured 3D models into coloured ldr files (with brick optimisation - so it creates the ldr model with 10 different types of brick). I've put my python code and instructions on how to use it on GitHub, you can get all the details from my blog...https://cultofthebrick.blogspot.com/2019...ithub.htmlHope you like it

Is there a guide anywhere for working with LPub3D when you have a black & white (grayscale) printer? For example, I would like to add the name of a colour next to each part — or a colour code — so when I'm reading my printed instructions, I can determine the part's colour. Even seeing the colour info on the BOM would be useful. Note that I'm using macOS. Any advice on this issue would be appreciated.

Guide: create build instructions with LPub This is a guide to making your own instructions with LPub. There is a: Short Guide Walks through the basics of producing a set of instructions. Full Guide Provides more details on the main steps for making instructions and explains the main features of LPub. User's discussion You are encouraged to ask questions, provide constructive criticisms and suggest proposals to improve this guide and suit it to users' needs. This guide will be updated over time to reflect the frequently asked questions. A complete guide to using LPub can be found here. List of recent topics that are related with LPub and build instructions: Instruction Miner vs. LPub (-> Go) MLCad: hiding parts in instruction step but showing in BOM (-> Go) LPub and MPD Files (-> Go) Help to create digital instructions for a physical MOC (-> Go) LPub not showing my main assembly (-> Go) Better building instructions than LDD? (-> Go) Problem with MLCad and Lpub (-> Go) LPub tree step - how? (-> Go) ... Credits - Thanks to Kevin Clague, the creator of LPub. - Thanks to Jaco van der Molen for his complete LPub guide. Note: This guide was prepared using a Mac. There may be minor differences for the Windows version of LPub.

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'm using Bricksmith and LPub 4 to create instructions for a rather large MOC (~8k pieces), but I need help with angles for a few ROTSTEP commands. Currently, I have two steps set in Bricksmith as: Step: Relative to default view: x,y,z = 10, -8, 7 Step: Additive: x,y,z = 180, 70, 180 This gives the following commands in the LDraw file: 0 ROTSTEP 10.971 -6.596 8.335 REL. (Side issue - why is this different to the angles I specified??) 0 ROTSTEP 180.000 70.000 180.000 ADD The problem is that Bricksmith does an ADD relative to whatever rotation was used for the previous step, while LPub does an ADD rotation relative to the default step orientation (i.e. ROTSTEP 0 0 0 ADD is identical to a STEP command with no previous rotations). So LPub shows a different view to the one I set in Bricksmith. I know xyz rotation angles cannot be directly added, so I tried converting them to quaternions, combined them, then converted back to an x,y,z rotation angle. Unfortunately (10,-8,7) + (180, 70, 180) gives (-140, -76, -148), which is nothing like what I expected. Is there any way to convert the ROTSTEP ADD command to a ROTSTEP REL command showing exactly the same rotation?