SylvainLS

Giant Overhaul! The file has been cleaned. The existing transformations have all been tested and corrected. A lot of new transformatins have been added. As far as I can tell, all the possible conversions are included. That’s about 2600 parts (depending on how you count them), 64 assemblies. 1075 LDD parts remain unconverted: they are missing in LDraw (at least, I couldn’t find them). You’ll need the latest LDraw Unofficial Library, especially for the assemblies (new parts have just been submitted for them). Here are a few files if you want to help or comment: The working assemblies. The assemblies for which parts are missing (dark grey are missing, white is the rest of the parts of the assembly we already have the LDraw parts for). The parts for which a variant is used instead (red and orange: the missing variant, dark grey: the substitute, brown: substitutes that are also wrong). And, finally, the list of LDD parts that I know no LDraw equivalent for: CSV (columns: LDD ID, LDD name, guessed BrickLink ID, BrickLink name). As I added in the first post, LDraw assumes technic holes/pins/axles in bricks are at the same height as studs. They should be 0.12 mm higher. LDD places them 0.2 mm higher. The old version of ldraw.xml used to add those 0.2 mm to a great number of parts (pins and axles mainly, but also beams and technic panels), not all, and arbitrarily. The picture below shows a 2L Axle (red) and Pin and Axle (blue) in a Technic Brick with Axle Hole. The axles parts have been rotated a quarter turn each level up (that is the higher ones are 270°, the lower ones are 0°). The left part uses the old conversion that added 0.2 mm, the right part uses the new conversion. Disclaimer: I’m prone to tpyos and other herrors, also, sometimes, after looking at a lot of parts and lines of XML, I might not have seen obvious errors. So, if you find an error, be indulgent and post it here. Thank you.

You can enter the DesignID in the search box to find the parts. 6156699 = 19478, not in LDD 4211508 = 4697, in LDD, section Technic Gears (don’t ask me why) 4529226 = 75974, not in LDD

Yeah Actually, you can put anything as an LDraw ID. Here, I used the same ID as LDD and LDD uses sub-sub-parts numbers (half cow body) as the ID for the sub-part (cow body).

Okay, I’m a blind idiot. The cow assembly had 64335c01.dat instead of 64835c01.dat. Guh. Afetr hvanig croretced teh tpyos, all* assemblies are imported! Well, except if your LDraw editor truncates too much…. * but one: “Torso with hook left.” Working on it…. Edit: just another typo. Becoming old

Okay, one strange thing: if I replace the.dat of the cow in ldraw.xml and the .ldr, it imports: <!-- Animal Cow Body 64779c01.dat --> <!-- RIGHT COW 64778 --> <!-- Brick ldraw="64779c01.dat" lego="64778" /> <Transformation ldraw="64779c01.dat" tx="-0.4" ty="-1.92" tz="-1.6" ax="0" ay="1" az="0" angle="-1.570796" / --> <Transformation ldraw="64778.dat" tx="-0.4" ty="-1.92" tz="-1.6" ax="0" ay="1" az="0" angle="-1.570796" /> <!-- Animal Cow Head 64835c01.dat --> <!-- RIGHT COW HEAD 64780 --> <!-- Brick ldraw="64835c01.dat" lego="64780" /> <Transformation ldraw="64835c01.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="-1.570796" / --> <Transformation ldraw="64780.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="-1.570796" /> <!-- Animal Cow 64452.dat --> <!-- COW ASSEMBLED 64452 --> <Assembly ldraw="64452.dat" lego="64452" > <Part ldraw="64778.dat" m0="0" m1="0" m2="0" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> <Part ldraw="64780.dat" m0="3.078" m1="2.33" m2="-0.4" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> </Assembly> I don’t understand why. Other working assembling have XXXc01 LDraw parts. The Poseable Horse above has the LEGO ID + c01.dat but others work and have random IDs before the c01…. Where is that Voynich manuscript? I think it’ll be easier to decipher than that.

If someone wants to play with assemblies, here are two: <!-- Animal Cow Body 64779c01.dat --> <!-- RIGHT COW 64778 --> <Brick ldraw="64779c01.dat" lego="64778" /> <Transformation ldraw="64779c01.dat" tx="-0.4" ty="-1.92" tz="-1.6" ax="0" ay="1" az="0" angle="-1.570796" /> <!-- Animal Cow Head 64835c01.dat --> <!-- RIGHT COW HEAD 64780 --> <Brick ldraw="64835c01.dat" lego="64780" /> <Transformation ldraw="64835c01.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="-1.570796" /> <!-- Animal Cow 64452.dat --> <!-- COW ASSEMBLED 64452 --> <Assembly ldraw="64452.dat" lego="64452" > <Part ldraw="64779c01.dat" m0="0" m1="0" m2="0" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> <Part ldraw="64335c01.dat" m0="3.078" m1="2.33" m2="-0.4" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> </Assembly> <!-- Animal Horse Poseable Head 10350c01.dat --> <!-- ANIMAL NO.11 HEAD 10350 --> <Brick ldraw="10350c01.dat" lego="10350" /> <Transformation ldraw="10350c01.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="-1.570796" /> <!-- Animal Horse Poseable Body 10352c01.dat --> <!-- ANIMAL NO.11 BODY LEFT 10352 --> <Brick ldraw="10352c01.dat" lego="10352" /> <Transformation ldraw="10352c01.dat" tx="-0.4" ty="-2.82" tz="2.68" ax="0" ay="1" az="0" angle="1.570796" /> <!-- Animal Horse Poseable Rear Legs 10354c01.dat --> <!-- ANIMAL NO.11 LEG LEFT 10354 --> <Brick ldraw="10354c01.dat" lego="10354" /> <Transformation ldraw="10354c01.dat" tx="0.4" ty="-2.82" tz="-0.52" ax="0" ay="1" az="0" angle="1.570796" /> <!-- Animal Horse Poseable 10509.dat --> <!-- ANIMAL NO.11 megablocks. 10509 --> <Assembly ldraw="10509.dat" lego="10509" > <Part ldraw="10350c01.dat" m0="-0.31" m1="3.075" m2="0.4" m3="-1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="-1" /> <Part ldraw="10352c01.dat" m0="0" m1="0" m2="0" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> <Part ldraw="10354c01.dat" m0="3.2" m1="0" m2="0.8" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> </Assembly> The Animal Horse Poseable is importable, in any correct pose (that is, you can rotate the legs, the head, the body, provided it stays attached). It works even with one part slightly misplaced, e.g. the head turned 1° on another axis than the hinge axis. The Animal Cow isn’s importable. Even if you import the exact file that is exported. You can play with the matrices, AFAICT, they are useless (it works the same without). I’m beginning to think that the non-working parts are 4.3.9/2075 parts and assembly import has been dumbed down in 4.3.9/2075, the same way Flexible parts aren’t exported/imported anymore (they worked in 4.3.8). Edit: the cow isn’t new in 2075….

Please note I’m in the process of cleaning, verifying, and correcting the whole mess file. Importing assemblies is the last ditch (see http://www.eurobrick...howtopic=140239 ). Don’t fear, I won’t wait for that to publish the result, I’m just waiting for a few new files in the LDraw Unofficial Library to write the big announcement.

I meant that when I tried importing multi-models files (MPD, whatever the extension is), LDD just treated it as a flat file: the submodels parts are placed, once, without transformation. Er, I should add a note: I went through all the available parts and corrected the ldraw.xml accordingly. I also cleaned it up. Importing assemblies is the last step. I hadn’t made it available yet as I’m in the process of adding new LDraw (unofficial) shortcuts for some assemblies.

MPD, not LDR? LDD can’t manage non-flat models. After reading that and a PM from Philo, I tried with LDCad and, lo and behold! It works way better than LeoCAD. But, still, the difference is just that LeoCAD truncates numbers at 6 decimals, LDD and LDCad at 14-16. It’s strange as there’s a way larger tolerance for connections in LDD (almost 0.2mm, 0.5LDU). Yes, and you can see them if you add the full tips (developper mode I think). An assembly is just a bunch of parts, a shortcut. Each part is treated as a primitive/simple element: and is exported separately. The Assembly tag is only needed for import and tells LDD what LDraw parts form the assembly and, maybe, what positions they must have relative to each other. When LDD can’t import an assembly (e.g. 2029+2030 hinge plates), in its error log, it says things like “Can’t find part 2030. Can’t find part 2029.” I surmise it’s because it found one part of the pair and couldn’t find the other part near enough. Yes, having fewer parts is possible for export, not import. Else we could import assemblies’ subparts separately (would have been handy when the 2x2 turntable was an assembly). No, because subparts are exported one by one, and, for import, there’s no plate to add to the motor assembly. We’re progressing: I’ll now use LDCad for my tests on assemblies.

You need to place the center of your model on 0,0,0. Either use the developper mode, which has the axes drawn in 0,0,0, or create a new file, place a part in the center of the virtual baseplate and then import your model and place it above your reference part. For the camera, you can still edit the LXFML inside the LXF, copy the Camera tag’s attributes from another LXF or calculate them yourself from a position.

Hi all, TD;LR: Does anyone know how the Assembly tag is supposed to work or have a link to some clues? Long version: I’m cleaning and completing the ldraw.xml file. I’m stuck with “Assemblies.” LDD parts that are composites are exported subpart by subpart. Easy peasy. But, in order to import them, recombining the subparts in the LDD assemblies, an Assembly tag is needed. Existing tags looks like that: <Assembly ldraw="ldraw-idc01.dat" lego="lego-id" tx="0" ty="0" tz="0> <Part ldraw="subpart-ldraw-id.dat" color="0" m0="0" m1="0" m2="0" m3="1" m4="0" m5="0" m6="0" m7="1" m8="0" m9="0" m10="0" m11="1" /> … </Assembly> sometimes with different values for the matrix. AFAICT, the minimum working tag looks like that: <Assembly ldraw="whatever" lego="lego-assembly-id"> <Part ldraw="subpart-ldraw-id.dat" /> … </Assembly> That is, the matrix and color attributes of the Part tags and the translation vector for the Assembly tag are useless. The name of the LDraw assembly is necessary but can be whatever. I first thought importing assemblies worked but, actually, it only works with the LDR that was exported by LDD. Just resaving it usually truncates some values and boom, can’t be imported anymore. Also, hints are given in comments that LDraw complete parts (such as MF hips and legs in one part) are exported/imported as is. That’s not true. Maybe it was true before: unflexed flexible parts were exported/imported in 4.3.8, they are not anymore in 4.3.9. So, if anyone has any clue… Thanks.

Just stops or explodes into space? On Windows?

In LDD, you can’t put the top stud of a brick in a technic hole but you can put a side-stud (only 1x1 bricks though). Also don’t forget that technic holes are 0.12 mm higher than side-studs. That is, the border of the 1x1 plate you connect to the technic brick by one of its holes is 0.12 mm higher than the top of the brick. You theoretically can’t put a part on top of the brick that would also be above the plate. You can force the connection IRL, you can sometimes force LDD to accept such a connection, and it’s found in some official sets, but it’s wrong (LDraw technic bricks are all wrong: they have their holes at the same height as side-studs.)

Update 2016-08-31 Corrected: 6255 / 6255.dat Plant 1 x 1 x 0.667 Round with 3 Large Leaves 63965 / 63965.dat Bar 6L with Thick Stop Added: 15530 / 15530.dat Minifig Hat Police 20430 / 20430.dat Cylinder 2 x 4 x 4 24445 / 24445.dat Tile 1 x 2 with Minifig Head Post 24593 / 24593.dat Cylinder Half 2 x 4 x 2 with 1 x 2 cutout 24607 / 24607.dat Windscreen 2 x 10 x 3 Note: the new ones are new unofficial LDraw parts.

Because your was? Besides, if you don’t like this topic, why are you participating? Or why don’t you propose a better one? ——— Getting back on the topic, LEGO themselves use non-plastic parts: strings, fabric (capes, skirts, sails…), paper, etc., and also non-brick plastic parts, like the cape of the CMF-14 Spider Lady and others. And what about glue?

If you want to go there, color is not the only trick/cheat. For example, there’re many digital builds that are not buildable in real life (unattached floating bricks…).

If the task seems daunting, feel free to post me your ldraw.xml file, I can easily find the diffs. One little problem with your code: the forum ate all the leading spaces. That’s not good with Python Another little problem is multiplying matrices can lead to errors or at least approximations (floating point computations). And another big problem: where’s the fun in automating that? You’re welcome!

u8101 is a Minitalia part, not pure LEGO, it’s LDraw name is “Brick 2 x 2 Miniatalia with Underside Cross Stud” 63324, 94148, and 74573 are alternate numbers, their names begin with an equal “=”. The correct IDs are 3003, 3022, 6636, and 2580c01. Try not to use parts whose names begin with equal “=”, tilda “~“, or underscore “_”.

Update 2016-08-23 Corrected: 60410 / 933c01.dat Electric Mindstorms NXT RJ12 Style Blug w/ Cable End (Complete) Added*: 55804 / 55804.dat Electric Mindstorm NXT Cable 20cm 55805 / 55805.dat Electric Mindstorm NXT Cable 35cm 55806 / 55806.dat Electric Mindstorm NXT Cable 50cm 11145 / 11145.dat Electric Mindstorm EV3 Cable 25cm 11146 / 11146.dat Electric Mindstorm EV3 Cable 35cm 11147 / 11147.dat Electric Mindstorm EV3 Cable 50cm * The cables are loose assemblies in LDD (the plugs can be moved at will), they are exported as two plugs. As they are loose, we can’t state the relative positions of their components in an Assembly XML element. So they can’t be imported. (Besides they’re 6 assemblies with the exact same two components.)

As far as I can tell, 933c01.dat should match 60410. And 60410 is only available in LDD in the “loose” assemblies 55804, 55805, 55806, 11145, 11146, 11147, and 54690. I say “loose” assemblies because the two parts can be moved separately. LDraw provides the complete assemblies 55804.dat, 55805.dat, 55806.dat, 11145.dat, 11146.dat, and 11147.dat (nothing for 54690). But LDD assemblies aren’t exported as LDraw assemblies (and vice versa for import), which is not a bad thing as LDraw assemblies are one-piece: their parts can’t be moved separately (so their positions wouldn’t match their LDD counterparts). Anyway, LDD assemblies are normally exported as separated parts. So 5580[456] and 1114[567] should be exported as two 60410/933c01.dat. But they are not. Therefore I think those assemblies are among the parts LDD refuses to export, like flexible parts. So, to sum it up: no luck there. Oops, there was a typo . So, they are correctly exported as two separate plugs. But they can’t be imported: the Assembly element should define the relative positions of the components of the assembly. We can’t do that for those assemblies because the components can be placed anywhere. Besides, we have 6 LDD assemblies with the same two components.

Update 2016-08-22 Added: 95646 / 95646.dat Electric Mindstorms EV3 95650 / 95650.dat Electric Mindstorms EV3 Color Sensor 95652 / 95652.dat Electric Mindstorms EV3 Ultrasonic Sensor 95654 / 95654.dat Electric Mindstorms EV3 Infrared Sensor 99380 / 99380.dat Electric Mindstorms EV3 Gyroscopic Sensor 95648 / 95648.dat Electric Mindstorms EV3 Touch Sensor 74665 / 99385c01.dat Electric Mindstorms EV3 Touch Sensor Body Assembly 99386 / 99386.dat Electric Mindstorms EV3 Touch Sensor Button 95658 / 95658.dat Electric Mindstorms EV3 Large Motor 54725 / 99550c01.dat Electric Mindstorms EV3 Large Motor Case 74042 / 99617c01.dat Electric Mindstorms EV3 Large Motor Drive Hub Double 99455 / 99455.dat Electric Mindstorms EV3 Medium Motor 59158 / 99535c01.dat Electric Mindstorms EV3 Medium Motor Body Assembly 74043 / 99543.dat Electric Mindstorms EV3 Medium Motor Thanks Jarema! 95648, 95658, and 99455 are assemblies in LDD. They are disassembled when exporting. Importing them (as assemblies) doesn’t work. The components are correctly imported though. I thought I would have to fumble with the Assembly XML element, but, actually, the ones that exist (torso, steering wheel, control stick/lever) don’t work: the separated components are “assembled” (replaced by the assembly) in LDD when they are correctly placed in the LDR file (as when exported ), but the LDraw ready-made assemblies aren’t imported.

Updated. But: 54809 is a totally different part, a propellor. It’s part of 54824 in LDD. 91996 doesn’t exist in LDraw, nor in LDD. 43903 is in the unofficial parts library, as 45903c01.dat As said in the introduction, I prefer exact matches with unofficial parts (which will hopefully soon become official) than almost matches with official but (even slighty) different parts. In this case, 71965c01.dat has 28 Tooth, 45903 has 20. 95648, 95658, and 99455 are assemblies. I found the composing parts in LDraw. I haven’t yet made the assembly importation (LDraw to LDD) yet, only export, but separated parts should be okay. Edit:separated parts correctly positionned are imported and “assembled” in LDD. LDraw assemblies are not importable (same as steering wheel, etc.).

Doesn’t seem so bad to me Hard to tell from the picture but I guess the missing parts are motors and electrical stuff and flexible(?) parts. For flexible parts, no luck. LDD 4.3.9 doesn’t export them anymore. At all. Even unflexed ones. 4.3.8 did, 4.3.9 won’t. For motors and electrical stuff or any other part that’s not correctly converted, if you have the part numbers in both LDD and LDraw, I can look into it and try to add or correct them.

By definition, i.j = k, so √2/2.i + √2/2.i.j = √2/2.( i + i.j ) = √2/2.( i + k ) The thing is, you’re overthinking it You don’t have to understand why or how, you just apply the rules: The definition: i.i = j.j = k.k = i.j.k = -1 Its corollaries: i.j = k = -j.i j.k = i = -k.j k.i = j = -i.k You apply them until you get only a scalar and simple i, j, k components. And that’s not 5th grade maths. Trigonometry is taught to 14-15 year-olds here (what we call “troisième” (third), should be 9th grade), and easily forgotten. And quaternions are college/university level stuff. (Well, my high school teacher introduced us to quaternions during the last year but he was a madman ) Yes, I didn’t want to go too far into the maths but I may have shortened a bit too much

Thanks! It’s great if it helped you. Sorry, habits. √2/2 is 1/√2 but mathematicians don’t like square roots in the denominator, well, at least my teachers didn’t. I used the Unicode fraction characters (so, basically, I wrote √(1/2) ) but the forum transformed some of them to {amp}frac12; which does not work everywhere. (And it keeps tranforming my “α” (alpha) into “a”!) And I don’t “get” 1/√2, it’s just the value of sine and cosine for π/4 (45°). A square with sides of 1/√2 has a diagonal of 1 (the radius of the trigonometric circle). Again, simple trigonometry. cosine and sine of π/2 = 90° are a given. Maybe your calculator is waiting for angles in degrees, not radians? The quaternions are only used for the rotations. A quaternion that represents a rotation is of the form q = cos(angle/2) + sin(angle/2).(ax.i + ay.j + az.k). It’s doubly unitary: its length is cos²(angle/2) + sin²(angle/2).(ax² + ay² + az²) = 1 and also ax² + ay² + az² = 1 (the length of the unitary vector defining the axis). When you multiply rotation-quaternions, you get a rotation-quaternion. If you know the angle angle and the axis (ax, ay, az) of the rotation, you can write q. If you have a quaternion that you know represents a rotation (as, for example, the result we get from combining several rotation-quarternions), its general form will be q = a + b.i + c.j + d.k. As it is a rotation quaternion, you know it can be written as q = cos(angle/2) + sin(angle/2).(ax.i + ay.j + az.k). Therefore ax = b / sin(angle/2), ay = c / sin(angle/2), az = d / sin(angle/2) and a = cos(angle/2), so angle = 2.Acos(a). Hence we get the angle, ax, ay, az to put in ldraw.xml. So, rotations are a b… I hope my explanations are not more confusing :skeptic: