Eurobricks Citizen
  • Content count

  • Joined

  • Last visited


About SylvainLS

Profile Information

  • Gender


  • Country
  • Special Tags 1
  • Special Tags 2

Recent Profile Visitors

1014 profile views
  1. And yes, about all LDraw applications use them in their UI.
  2. Practical tip: colour the 3-fingered one as transparent, you’ll then see if the articulation bumps match the holes. Theoretical tip: the articulation points are at 12 LDU from the centre of the part. That means two 3612.dat correctly connected are at 24 LDU from each other.
  3. If I remember correctly, that thread is more about the business side, for BL sellers. (If you want to see all the messages on one page: ) I was more talking about this (sub)forum:
  4. Update 2017-08-17 Added: 18455 / 18455.dat Hinge Brick 2 x 4 Locking with 1 Finger on Top at One End 92903 / 92903.dat Arch 1 x 3 x 2 with Curved Top md5sum: 4cfd013b4632e8c0c411f7e30eb8df86
  5. Read BrickLink Mosaick forum, plenty of wanted features (which won’t be implemented soon by BL).
  6. Update 2017-08-13 Added: 93223 / 93223.dat Minifig Beard Medium Short Updated: 15341 / 15341.dat Minifig Robot Arm md5sum: 178932728e81a526e608ddcf467cddc0
  7. TL;DR: 93888.dat is in Unofficial ( ), it has been there for a long time. LDD treats 3007 and 93888 as different (the latter having internal supports), whereas, in LDraw, 93888.dat is a simple alias to 3007.dat (but a long help text explaining the differences (which don’t include internal supports)). So using 93888.dat isn’t necessary and could even be a problem but, as many parts are already only available in Unofficial, in those cases I prefer to use the correct DesignID.
  8. How to bend flex axles?

    1. Only Flex Rods 7M, 11M, and 12M are flexible (14M, 16M, and 19M aren’t). Don’t ask me why 2. You block one end (connect it to another part), you use the flex tool (F) on the other end, which should follow your mouse. If the rod is totally free (not connected), it’ll still move and flex a bit.
  9. Update 2017-08-04 Added: 18835 / 18835p01.dat Minifig Hair Mid-Length Straight with Gold Crown Pattern 88323 / 88323.dat Technic Chain Tread 38 Reinforced md5sum: 43786195f6d977424e571767af7a0dee
  10. legolijntje already sent us (me and Roland) the file and, as surmised, it’s a problem with the file, not with the flattening (mpd to ldr), not with ldraw.xml. There’s a 0.1 instead of a -0.1 in a matrix in the top-level model, the bricks apparently show really near where they should be but the matrix is wrong (not a rotation). I guess legolijntje will correct that soonish. As an aside, as you want to import in Mecabricks in the end, if it’s possible, maybe you could transform the model submodel by submodel: it should greatly help you with overlapping bricks (less bricks to import, less bricks rejected by LDD, less bricks to re-add afterward).
  11. Okay. Must have been down for some time.
  12. (hyphen + .de, not .org) But I don’t see anything there that can help you.
  13. The values in the LDR file have 3 digits, so ±0.001. The example that works leads to an “identity” matrix with (1 or 0) ±0.0005. The one that isn’t orthogonal gives (1 or 0) ±0.0005 and spurious 0.06 and 0.19. I don’t believe these 0.06 and 0.19 can be floating point errors. Especially as the entry matrices uses the same values, just with different signs: [ [-0.304, -0.31, -0.901], [-0.002, -0.945, 0.325], [-0.953, -0.1, 0.287] ] # isn't a rotation [ [-0.304, 0.31, 0.901], [ 0.002, -0.945, 0.325], [ 0.953, 0.1, 0.287] ] # is a rotation
  14. Yes. “Flipping” an axis as a determinant of -1 (your scale-an-axis-negatively matrices are diagonal matrices with two 1 and one -1, aren’t they?). So, you do N = A x M x B, with A, B, and M orthogonal, M a rotation matrix (determinant of 1), and A and B with a determinant of -1. Hence, N is orthogonal, with a determinant of -1 x 1 x -1 = 1. IOW, N is a rotation matrix. Too bad it isn’t (even though it’s determinant is (almost) 1) Hence one of the above hypotheses is wrong: either M, A, or B, or two or all of them aren’t orthogonal (because orthogonal matrices are a group, so XxY is orthogonal iff X and Y are orthogonal), or something happened to the matrices. We really need a simple example (that doesn’t import well in LDD) where we can clearly see which part is the mirror of which. (I wasn’t able to build one using LDCad’s mirror tool (but I’m no LDCad expert): they all import well in LDD.)
  15. Flattening an MPD isn’t rocket science: read the whole file, store each submodel, and then dump the main model, replacing each used submodel by its content, coloring it (= replacing color 16) and transforming the matrices using the one in the use-line (simple multiplication). Here is another (dumb) example in Ruby for your collection The flattening shouldn’t cause much problem (beside approximation errors): we have 4x4 transformation matrices that are multiplied together and we end up with 4x4 transformation matrices. If we start with (rotation+translation) matrices, we should end up with (rotation+translation) matrices (I think : I know rotation matrices are a group, I think (rotation+translation) matrices are another one). @roland As we can see in the examples I gave, the numbers are the same but the first matrix isn’t orthogonal and the second one is. I don’t think approximation errors are the culprit here. As an aside, there’re ways to find the nearest orthogonal/rotation matrix. That’s what Qt does in the QMatrix4x4::optimize() function.