More up-to-date ldraw.xml LDD/LDraw conversion file

[SylvainLS]

Update 2017-07-10

Added:

• 20693 / 20695.dat  Minifig Pumpkin Carved
• 30380 / 30380.dat  Minifig Helmet SW Mandalorian with Rocket Pack

md5sum: 1881492c3f302a520193d0ebe916b11a

 

[SylvainLS]

Update 2017-07-28

Added:

• 10312 / 10312.dat  Windscreen  6 x 10 x  3 with  1 x  2 x  1 Cutout - Ovoid
• 21709 / 21709.dat  =Excavator Bucket  6 x  3 with Click Hinge 2-Finger

Corrected:

• 50986 / 50986.dat  Windscreen  6 x 10 x  3 Ovoid

Rematched:

• 4287 / 4287b.dat  Slope Brick 33  3 x  1 Inverted with Notch and Thin Front

md5sum: 2d54122bc38398f97e510dca4f7e972e

[Renderbricks]

Good work. But I have actually issues with wrong orientation of bricks:

Edited July 29, 2017 by Renderbricks

[SylvainLS]

As my IRL name is Herlock Sholmes, I infer that you’re trying to import an LDraw Star Wars UCS Whatever into LDD and that doesn’t go smoothly. Furthermore, the model and my more than human eyesight tell me the red parts, the naughty ones, are pretty common plates and wedges, whose transformations are pretty straightforward and well-tested.

So, to understand what happened and if it can be fixed:

1. Did you try with the version of ldraw.xml included with LDD?
2. If no to 1, please try.
3. If yes to 1 or after trying, does it work better?
4. How did you build the model? With a “mirror” tool?
5. Could you send me the offending model, or part of it, or a smaller one giving similar results? (Either a link here, or in a PM, or in an e-mail (address in the ldraw.xml file), or a link in a PM, or a link in an e-mail, or smoke signals… er, no, not smoke signals. And no avian carriers either: they’ll be eaten with small peas.)

Thanks.

[legolijntje]

8 hours ago, SylvainLS said:

As my IRL name is Herlock Sholmes [...]

Well, I am the one who made the source LDraw model. For these building instructions. Renderbricks wants to render the model, but he first needs to have an LDD file to be able to import it into Mecabricks. I have not a lot of knowledge about LDD, but I think it's kinda strange how the bottom right imports just fine, but the bottom left has all kinds of problems. There are no mirrored parts (I did use LDCad's mirror functionality, but that doesn't just mirror the parts, it actually applies a transformation on the coordinates and rotation to 'physically' mirror it, so I don't think that's the problem).

[Renderbricks]

Hi Sylvain,

I will ask the author of this file for permission to pass it over to you.

 

[Renderbricks]

Here's the difference:



Your ldraw.xml is much better but both can't handle the broken parts. My suspicion is, too, that the mirror function in LDCad will create coordinates which are bad for LDD.
 

Edited July 30, 2017 by Renderbricks

[legolijntje]

3 minutes ago, Renderbricks said:

My suspicion is, too, that the mirror function in LDCad will create coordinates which are bad for LDD.

I don't think so, I don't think LDCad is the problem here. Because there are also many, many parts which have been automatically mirrored which work perfectly fine.

[Renderbricks]

I tried to import it with the Blender LDR-importer but this is too big. The Blender import took around 24 hours and the file is over 2.5GB compressed. I can't export it to fbx/Collada to import into Modo. These files are 7 and 10GB and can't be loaded.

There's a beta LDR importer for Modo but it will create merged meshes. Tried to load the mesh but failed due to memory issues (32GB here). I contacted the programmer to add instancing support what Mecabricks does. This is the only chance to deal with huge LEGO models like this.

I also had to convert the MPD file to LDR with MPDCenter because LDD can't read MPD. The result looks good in LeoCad but LDCad can't read that completely. Maybe here's the problem?

[SylvainLS]

I don’t import much (only for testing purposes), but I’m guessing some of the red parts are marked only because of collision errors (that is, there are correctly placed and orientated but collide with each others), no?

Could you (Renderbricks or legolijntje), make a small model, try it and send it to me? (A few parts of the nose maybe?)

Anyway, if it’s because LDD can’t handle some peculiar input or “simplifies” or “normalizes” too much, I don’t think there’s much that can be done ldraw.xml-wise 

[Calabar]

1 hour ago, legolijntje said:

I don't think so, I don't think LDCad is the problem here. Because there are also many, many parts which have been automatically mirrored which work perfectly fine.

Maybe something go wrong with inclined parts, especially if the angles of the right and the left side of the model are not perfectly symmetrical.
LDD is strict with tolerances, so the parts fit in LDCad but LDD reject them.

[legolijntje]

46 minutes ago, Renderbricks said:

I also had to convert the MPD file to LDR with MPDCenter because LDD can't read MPD. The result looks good in LeoCad but LDCad can't read that completely. Maybe here's the problem?

What exactly did you do with MPDCenter?

Just now, Calabar said:

Maybe something go wrong with inclined parts, especially if the angles of the right and the left side of the model are not perfectly symmetrical.
LDD is strict with tolerances, so the parts fit in LDCad but LDD reject them.

LDD does reject certain parts, that we already figured out (via mail). However, all parts that do appear on the left side are not even in the correct position but look rotated (90 degrees?) in some way. But they look fine on the right side 

[Renderbricks]

35 minutes ago, legolijntje said:

What exactly did you do with MPDCenter?

I extracted the MPD into a single LDR.

[legolijntje]

1 minute ago, Renderbricks said:

I extracted the MPD into a single LDR.

Where can I even find that feature? Can't find it 

[Renderbricks]

20 minutes ago, legolijntje said:

Where can I even find that feature? Can't find it 

MPDCenter
- load MPD
- select the specific LDR in the list
- Extract > Selected in LDR inline
- takes a while till the Save dialog opens

[SylvainLS]

Update 2017-08-01

Added:

• 24130 / 24130.dat  Hemisphere  4 x  4 x  1.667 Bottom with Faceted Inside
• 24132 / 24132.dat  Hemisphere  4 x  4 x  1.667 Top Ovoid with Faceted Inside

md5sum: 6a6303924da9d84de260c1786239c721

 

[legolijntje]

@SylvainLS I start to think there's really something wrong in your ldraw.xml regarding the above discussion about the partly failing import. I found a Python script online (that I had to slightly modify) that transforms an mpd file into an ldr file. It works much faster and cleaner than the above mentioned mpdcenter. However, the result .ldr file still resulted in the same wrong import. I then deleted everything except the two bottom panels to compare them, since the only place something is going wrong is in one of the bottom panels and te remove any of the 'noise' generated by clashing parts that LDD removes. And this is the result:

It looks like on one side all the parts are missing a 90 degree rotation.

[Philo]

2 hours ago, SylvainLS said:

24132 / 24132.dat  Hemisphere  4 x  4 x  1.667 Top Ovoid with Faceted Inside

Looks like you got description wrong, height is 2.333 ;)

[SylvainLS]

Just now, Philo said:

Looks like you got description wrong, height is 2.333 ;)

Oops. Naughty copy+paste 

36 minutes ago, legolijntje said:

I start to think there's really something wrong in your ldraw.xml regarding the above discussion about the partly failing import.

I continue to think the transformations are okay because, mathematically, they can’t be wrong: If a 90° rotation were missing for these parts, it would be missing whatever their LDraw position and orientation. They can’t work sometimes and not others, and they work on all the examples I can get or contrive. Unless either 1. the times they don’t work is when the LDraw matrices aren’t rotation matrices or 2. LDD does something strange (like using Euler angles and falling into a gimbal lock, which would be terminally stupid considering LDD uses matrices and quaternions everywhere else).

So, again, unless someone is willing to give me examples of LDraw matrices that lead to wrongly imported parts, I can’t do anything but repeat I have nothing to fix because nothing is broken.

[legolijntje]

8 minutes ago, SylvainLS said:

So, again, unless someone is willing to give me examples of LDraw matrices that lead to wrongly imported parts, I can’t do anything but repeat I have nothing to fix because nothing is broken.

I thought you already received something. I'll send you a PM.

[SylvainLS]

Thanks for the file.

As I surmised, the offending parts are wrong in the LDraw file.

A rotation matrix should be orthogonal (M x Mt = Identity = Mt x M) and its determinant should be 1. As we’re working with floating point numbers, we have to be lenient but, take any of the parts’ matrices, e.g. line 2057 (9 last numbers are the rotation matrix):

[ [-0.304, -0.31, -0.901],
  [-0.002, -0.945, 0.325],
  [-0.953, -0.1,   0.287] ]

If you multiply this matrix by its transposed (mirror by the diagonal / colums become rows), you get:

[ [1.000317, 0.000733, 0.062125],
  [0.000733, 0.998654, 0.189681],
  [0.062124, 0.189681, 1.000578] ]

which is far from Identity (almost 1 on the diagonal (which we have here), and almost 0 everywhere else (which we haven’t)).

Naughty LDraw file 

[roland]

LDCad's mirror function only flips 2 axis' around so I don't think its the cause, are the source bricks orthogonal?

This could be a accumulative rounding problem,

[SylvainLS]

I didn’t test all the bricks (about 1700), just a few that work and a bit more that don’t. The ones that work are orthogonal (±0.0005).

I also opened the file in LeoCAD (to be sure of the line numbers): LeoCAD has some troubles matching the mouse with the parts. (LDCad has no problem.)

The first brick (works):

[ [-0.304,  0.31,  0.901],
  [ 0.002, -0.945, 0.325],
  [ 0.953,  0.1,   0.287] ]

Very similar to the examble above, but this one is a rotation matrix.

I fear your “flipping” doesn’t transform a rotation matrix into a rotation matrix.

Edited August 1, 2017 by SylvainLS
Adding example

[legolijntje]

46 minutes ago, roland said:

LDCad's mirror function only flips 2 axis' around so I don't think its the cause, are the source bricks orthogonal?

This could be a accumulative rounding problem,

I don't think the problem lies with LDCad but with the tools that transform an mpd to a flat ldr. I've tried two so far (MPDcenter and a Python script which I found on the LDraw forums and edited a bit).

 

59 minutes ago, SylvainLS said:

Thanks for the file.

As I surmised, the offending parts are wrong in the LDraw file.

A rotation matrix should be orthogonal (M x Mt = Identity = Mt x M) and its determinant should be 1. As we’re working with floating point numbers, we have to be lenient but, take any of the parts’ matrices, e.g. line 2057 (9 last numbers are the rotation matrix):

[ [-0.304, -0.31, -0.901],
  [-0.002, -0.945, 0.325],
  [-0.953, -0.1,   0.287] ]

If you multiply this matrix by its transposed (mirror by the diagonal / colums become rows), you get:

[ [1.000317, 0.000733, 0.062125],
  [0.000733, 0.998654, 0.189681],
  [0.062124, 0.189681, 1.000578] ]

which is far from Identity (almost 1 on the diagonal (which we have here), and almost 0 everywhere else (which we haven’t)).

Naughty LDraw file 

Hmm, I did not notice that. Something to think about I guess. Maybe I can alter the python script. Don't know much about matrix calculations though, so I'll have to take a very good look in that case 
Thanks for the help!

[roland]

The main rounding problem in LDraw is usually caused by the decimal count used for matrices, (0.707 instead of 0.707106 etc) this combined with multiple nesting levels can result in these kinds of problems.

LDCad uses double precision internally but if those read numbers are rounded all bets are off.