SylvainLS

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.

Okay, it’s official: I’m dumb(founded). I took the coordinates (i.e. position and rotation / or transformation matrix) in a LXF (a couple times the same brick (3005), just rotated and translated), the coordinates (ditto) in the exported LDR, and I can’t find a relation between them (nor their transposed, or inverse, or whatever). It’s the same brick, so the transfomation should be the same each time (and should look like the one in ldraw.xml, modulo a change of basis)

Update 2017-05-08 Added: 61199 / 61199.dat Minifig Lightsaber Hilt Short Curved md5sum: 1355ceb5cd1ceee7f291e3c08c5bb1c0

I found none. But the LXF format is pretty straightforward (zipped XML + thumbnail). To convert to LDraw, you only need to match part IDs and the coordinates systems. Two things ldraw.xml helps doing I guess because LDD does it I never had the idea to write a program to do it, but now that the idea has been planted, I think it would be nice to have one that would handle flexible parts (which are not imported/exported by LDD anymore), even when not-flexed. It would also be nice to handle decors (we would need another conversion table though).

The few (1040) bricks that are neither in the Official LDraw Library nor the Unofficial one are available at digital-bricks.de. And as for out of place bricks, there’re none if you use the right ldraw.xml file:

There’re still parts that are not properly imported (wrong position and orientation). And patterns are still lost in translation (as with LDD’s “export to LDR”).

I’d suggest you try with Blueprint. LDD can’t even create workable instructions for a 100 parts model.

Are you using the latest ldraw.xml? Exporting 14696/3711 works fine with it.

Update 2017-05-04 Added: 17454 / 17454.dat Windscreen 2 x 6 x 2 Vertical Frame 17457 / 17457.dat Windscreen 2 x 6 x 2 Vertical Glass md5sum: 08ead4cd106dded4ef4a41953f4390ae

Update 2017-05-03 Added: 15439 / 15439.dat Minifig Moustache 15496 / 15496.dat Minifig Cup Take Out 15534 / 15534.dat Minifig Tool Grappling Hook with Bar md5sum: c32f55cf120deace6dbaf27ef5f6147e

Update 2017-04-20 Added: 14520 / 14520.dat Bracket 2 x 4 x 0.667 with Front Studs and Deep Arches 95330 / 95330.dat Minifig Axe md5sum: 6f598b4debc21be60407ff5ce244007f

Update 2017-04-18 Added: 11568 / 11568.dat Animal Squirrel 87846 / 87846.dat Figure Tail 8 x 6 Curved md5sum: 10bed60ce4448702ca85e0944cf11de7

Okay. I asked because I have no problem here letting LDD download what it wants (but under Linux/Wine).

Update 2017-04-11 Added: 93055 / 93055.dat Minifig Sword Katana (Dragon Guard) md5sum: ddfdf7ae24b3f95abe0db7c0dac1265d

Why did you “looked everywhere” to install that component? Just click “Yes” in the dialog box and LDD Setup will download and install what it (says it) needs.

I’d amend that to just “open the new file” because “closing a file” in LDD could be taken as “close LDD,” which wouldn’t work So, to sum up: open+copy+open+paste, or import (also imports groups), or use a template (stays available between sessions).

Update 2017-04-04 Added: 18791 / 18791.dat Minifig Shovel Blocky md5sum: d2e31cf4e1b85d306a3685b5a42a567f

Are you talking about Assemblies (e.g. LDD minifig “torso” becoming LDraw torso + arms + hands) or LDD groups (third tab in LDD (Bricks / Templates / Groups))? If the former, it’s the way LDD exports. You can trick it though. If you’re interested, I can explain…. If the latter, it’s not possible in LDD.

You’re welcome A link would be useful indeed. Will do!

Update 2017-03-28 Corrected a typo in 2607 / 2607.dat Magnet Holder 2 x 3. md5sum: 63f92236417de02c4c5042ac03911992

Udpate 2017-03-22 Added: 18787 / 18787.dat Minifig Sword Blocky 18788 / 18788.dat Minifig Axe Blocky 18789 / 18789.dat Minifig Pickaxe Blocky Rematched (new variant): 18838 / 18838.dat Arch 1 x 12 x 3 Raised with 5 Internal Ribs md5sum: f082cc088a947e569c3815be2d0badbd