SylvainLS

Update 2017-05-31 Corrected: 87989 / 87989.dat Minifig Syringe md5sum: 7228be24f44c09b47c5e88b970d4154d

Nice animation. If only I could get LDCad’s parts bins Isn’t there a tiny problem though? The main rotor turns clockwise, the tail rotor should counter the torque, so it should push clockwise too (tail to the left) but it pushes the tail to the right, with the torque. How did such a big mistake went through QA?

Update 2017-05-29 Added: 92738 / 92738.dat Minifig Gun Small Blaster md5sum: 26a29472cf3f04a1f05ed50e9f5b8128

Update 2017-05-25 Corrected: 10066 / 10066.dat Minifig Hair Orc with Ears Rematched: 45406 / 45406c01.dat Windscreen 4 x 6 x 4 Cab with Hinge and Trans Black Glass md5sum: 9c64b8b2d94d598a1b9afef0e430a469

Well, I’m not ready to open that can of worms yet

All the missing parts are available at http://digital-bricks.de They use LDD’s shapes, no LDraw primitives, no pattern. But you still get a nice placeholder while waiting for the part to be included in LDraw. It’s easier to export LDD to LDraw first then import the LDraw into Stud.io. Using lxf2ldr, you even get submodels, flexible parts, and some of the decorations (some of which are even correctly translated by Stud.io into their BL patterned counterparts). (Yes, I’m shamelessly advertising )

Yep:

I just pushed a few improvements: Assemblies (minifig hips and legs, torsos and arms and hands…) are regrouped in submodels. Update ldraw.xml (I will only post about big modifications from now on.)

Update 2017-05-23 Re-matched: 30499 / 3684a.dat Slope Brick 75 2 x 2 x 3 with Hollow Studs Added: 98560 / 3684c.dat Slope Brick 75 2 x 2 x 3 with Solid Studs md5sum: 858d471e6ec3944861add762073199fc

Update 2017-05-22b Added: 98262 / 98262.dat Plant Flower 2 x 2 with Solid Stud md5sum: 5b3b8886eee36a924b35879236670654

Update 2017-05-22 Added: 14301 / 14301.dat Hose Flexible 11.5L md5sum: fee90bb1e6b48dd5822140bbbf4251a2

I just pushed a new version: Groups are converted to submodels, centered on their first part or submodel. Flexible parts are converted to LSynth commands. (It means you need to run LSynth on the generated file if you used flexible parts. (Cleaning up and removing a lot of control points before is recommended.)) Parse errors are now properly reported. Code has been cleaned up and comments added. A modified lsynth.mpd file is provided. It adds 3 new flexible parts: Minifig Chain Link 5L (92338), Hose Flexible 11.5L (14301), and Technic Tool Belt 17M (98567). (Latest LDraw Unofficial Library needed for 14301.)

@roland Thanks Roland, but it seems LSynth’s way would be simpler: LDD’s bones can serve as LSynth’s constraints: the curve goes through them. With Bezier, the intermediary points are outside the curve. So, unless you have a simple method to interpolate Bezier c.p. from points of/in the curve, I’ll go with LSynth @legolijntje As I’m lazy, that’s exactly what lxf2ldr will do, but with LSynth commands. I don’t want to reimplement LSynth’s interpolation. (Depending on the part, there are more or less “bones” than there will be LDraw parts. So I’d need to interpolate parts’s positions and rotations from the bones/passage points, which is exactly what LSynth does.)

Thanks LXF stores intermediary data as “bones.” I’m not sure yet if they are placed at the center of a rigid part (b-spline-like) or at the joints. It seems to depend on the part. For now (not on the gitlab version (yet)), I just tried placing LDraw subparts at these points. It works great for some parts (as the one I linked, which is very simple) but not very well for others (technic flex-system hose or the tool belt 17). So, next step is to look into how LSynth and LDCad do it and chose the easiest one, er, I mean, the one that translates best

I have been working on flexed flexible parts: looking good so far. http://slswww.free.fr/lxf2ldr_flex.png

Hi all, I cobbled together a little command-line¹ program to convert LXF models to LDR. I put it in a gitlab repo here. Contrarily to LDD’s own conversion process, it tries to convert decorations (though a lot are missing/different in LDraw) and flexible parts (though unflexed). On the technical part: it’s source only², tested under Linux only but should compile and work on other OSes (needs Qt5 core, QuaZIP and yaml-cpp). On the legal part: it’s GPLv3+. Constructive comments are welcome. ——— ¹ Yes, command-line, no GUI. Feel free to add one if you wish. A minimal GUI was added in March, 2018. ² I won’t provide binaries. Feel free to do so for your OS (pointing to the sources as per GPLv3+).

The new part is only available in “LDD extended” mode. Menu View / New themes / LDD extended The top toolbar will be brown instead of blue. All the parts will be presented as red: You need to change the main color with the color palette under the part palette or paint them with the paint tool (different than in “simple” LDD mode). Also, check what the “Brick Version” is in the About window (F3 or menu Help / About).

Bummer 95551 is the value of the field “decoration” in the LXF. It seems to be an internal number not related to any public Id (design, part).

Hi all, has anyone ever compiled a matching table between LDD decorations and LDraw patterned bricks (or stickers)? (Something like 95551 = 3005pf0.dat) There’re about 2000 decorations in LDD and it’s highly disrespectful to redo the gruesome work someone has already done

Update 2017-05-12 Verified/Corrected (still aren’t exported/imported by LDD but transformations are now correct): 64230 / 73590a.dat Hose Flexible 8.5L without Tabs 57539 / 57539.dat Hose Flexible 19M 92338 / 92338c01.dat Minifig Chain 5L (Complete) 63141 / 572c01.dat String Braided 21L with End Studs and Minifig Grips (Complete) 32580 / 32580.dat Technic Axle Flexible 7 32199 / 32199.dat Technic Axle Flexible 11 32200 / 32200.dat Technic Axle Flexible 12 76279 / 76279.dat Technic Flex-System Hose 6L (120LDU) 60166 / 76289.dat Technic Flex-System Hose 7L (140LDU) 55668 / 76260.dat Technic Flex-System Hose 8L (160LDU) 76324 / 76324.dat Technic Flex-System Hose 9L (180LDU) 76302 / 76348.dat Technic Flex-System Hose 10L (200LDU) 63037 / 71505.dat Technic Flex-System Hose 11L (220LDU) 60676 / 71175.dat Technic Flex-System Hose 12L (240LDU) 76255|85532 / 71192.dat Technic Flex-System Hose 16L (320LDU) 76270 / 76270.dat Technic Flex-System Hose 17L (340LDU) 76275|61356 / 71582.dat Technic Flex-System Hose 18L (360LDU) 76257 / 22463.dat Technic Flex-System Hose 19L (380LDU) 55676 / 76276.dat Technic Flex-System Hose 20L (400LDU) 62530 / 76252.dat Technic Flex-System Hose 22L (440LDU) 76254 / 76254.dat Technic Flex-System Hose 23L (460LDU) 76277 / 76277.dat Technic Flex-System Hose 24L (480LDU) 57274 / 57274.dat Technic Flex-System Hose 32L (640LDU) 71984 / 71952.dat Technic Ribbed Hose 4L 71944 / 71944.dat Technic Ribbed Hose 6L 71985 / 57719.dat Technic Ribbed Hose 7L 71917 / 71917.dat Technic Ribbed Hose 9L 71986 / 71986.dat Technic Ribbed Hose 11L 71923 / 71923.dat Technic Ribbed Hose 14L 72039 / 72039.dat Technic Ribbed Hose 18L 43675 / 43675.dat Technic Ribbed Hose 19L 98567 / 98567.dat Tool Belt 17M md5sum: fdc070a421e58f3a871f88e2d28562e2

Okay, solved: expressing a rotation matrix R in another basis is R’ = B x R x B⁻¹. I made several stupid things: I thought that it was just a matter of combining matrices (that is R’ = B x R). I didn’t check that assumption. An the change of basis is just a half turn around X (which is good because it’s equal to its inverse). So, here’s what’s done in pseudo-code: # from tx, ty, tz, ax, ay, az, angle in ldraw.xml lxf2ldr_tr = ( -tx -ty -tz ) lxf2ldr_rot = (( ax*ax*(1-cos)+cos ax*ay*(1-cos)+az*sin az*ax*(1-cos)-ay*sin ) ( ax*ay*(1-cos)-az*sin ay*ay*(1-cos)+cos ay*az*(1-cos)+ax*sin ) ( az*ax*(1-cos)+ay*sin ay*az*(1-cos)-ax*sin az*az*(1-cos)+cos )) # = the rotation matrix for -angle (ldraw.xml is written “import-wise”, we export) # read 'a,b,c,d,e,f,g,h,i,x,y,z' in the LXF lxf_pos = ( x y z ) lxf_rot = (( a d g ) ( b e h ) ( c f i )) # the change of basis (= its inverse) B = ((1 0 0) (0 -1 0) (0 0 -1)) # the ldr rot = lxf_rot * lxf2ldr_rot ldr_rot = B * rot * B ldr_pos = B * ( lxf_pos + rot * lxf2ldr_tr ) * 25 # write ldr_pos[0] [1] [2] then ldr_rot[0,0] [0,1] … [2,1] [2,2] (that is "a b c…" for the matrix ((a b c) …)) Now to tackle decorations and flexible parts….

It doesn’t change a thing: to go from the LXF 4x4 matrices to the LDR 4x4 matrices is still not a constant matrix. Applying the transformations should be Mat_LDR = Mat_basis x Mat_ldraw.xml x Mat_LXF (or the other way around, or the rotation part of Mat_LXF transposed because I don’t know if both notations “a,b,c,d,e,f,g,h,i“ mean ((a b c 0) (d e f 0) (g h i 0) (0 0 0 1)) or its transposed (that is, column-vector or row-vector conventions)). And whatever Mat_basis and Mat_ldraw.xml be, Mat_LXF / Mat_LDR should be constant for the same brick ID (because I don’t see any other information than the brick ID to go from the LXF matrix to the LDR one). It’s not. Never, however I read the data in the LXF and LDR files. So, something is done beside a change of basis and the ldraw.xml transformation. And I can’t figure what because if it were an affine transformation (translation or rotation or some others), it would be a 4x4 matrix and Mat_LXF / Mat_LDR should still be constant for the same brick ID. (And I think applying the scale should be easier done on the position only, rather than on all the matrix that I’d have to renormalize afterwards ) EDIT: just saw your edit (I type slowly). For now, I was trying to understand how to read the rotation data (row-vector / column vector). So I don’t even use the transformations in ldraw.xml, I’m just trying to check that Mat_LXF / Mat_LDR is constant for the same brick (and, next, how it could relate to what’s in ldraw.xml, but I’m not there). Anyway, the brick I use for the tests, 3005 1x1 brick, only needs to be translated: Its rotation is 0° (because it’s symetric).

You might have an OpenGL/driver problem: your graphics driver announces a function that’s not actually there and that LDD uses. Does it work if you revert the preference? Have you tried updating your drivers?

The change of basis works fine for the position vector. It’s the rotation matrix that’s giving me a headache. As I tried to show on the example above, a 3005 1x1 brick just put there (stud up) has a rotation matrix of Identity in LXF and in the generated LDR, with a rotation of 0° in ldraw.xml. ID x ID = ID. If I insert a change of basis in there, it doesn’t work. Same if the brick is rotated -π/2 around Y, or Z (bricks 3 and 4). But if the brick is rotated around X (brick 2), then yes, the change of basis is needed (-π/2 becomes π/2). And if the brick is rotated around Y then Z (brick 5), then it’s totally unrelated to the change of basis. The LXF is correct. The LDR is correct (the models do look alike). So why do the matrices don’t show a constant relationship? (LXF / LDR should always be the same matrix, no?) (Even 4x4 matrices to account for any affine transformation don’t work. And even if the notations are transposed/inverse (that is, computing t(LXF)/LDR for all bricks), it doesn’t explain the discrepency.)

Here’s what I’m talking about: one brick (3005) is placed in LDD, then exported by LDD into an LDraw file. Below are the rotation matrices: Rotations LXF matrix LDraw matrix 1 none 1,0,0,0,1,0,0,0,1 1,0,0,0,1,0,0,0,1 2 around X 1,0,0,0,0,1,0,-1,0 1,0,0,0,0,-1,0,1,0 3 around Z 0,1,0,-1,0,0,0,0,1 0,1,0,-1,0,0,0,0,1 4 around Y 0,0,1,0,1,0,-1,0,0 0,0,1,0,1,0,-1,0,0 5 around Y then Z 0,-1,0,0,0,1,-1,0,0 0,0,1,1,0,0,0,1,0 1 is placed as-is. 2 is 1 rotated a quarter turn around the X axis (-π/2). 3 = -π/2 around Z. 4 = π/2 around Y. 5 is fisrt rotated π/2 around Y then π/2 around Z. There’s no rotation needed to go from LXF to LDraw for 3005.dat (only a translation is needed, but it only concerns the positions, not the rotation matrices). LXF basis is right-handed X-right, Z-front, Y-up. LDraw basis is right-handed X-right, Z-back, Y-down. That is, a rotation of π around the X axis should be needed to change basis. But: The “transformed” matrices in LDraw are identical to the ones in LXF for 1, 3, and 4: no transformation (as expected by ldraw.xml) but no change of basis either. LDR-2 is LDR-1 with a π/2 turn around X, instead of the -π/2 to go from LXF-1 to LXF-2, thus implying a change of basis occured. LDR-5 corresponds to a π/2 around Z followed by a π/2 around Y, instead of Y then Z. Guh So, either I’m missing something obvious (which wouldn’t surprise me ) or there’s some info missing. Any help appreciated.