Jump to content

SylvainLS

Eurobricks Counts
 View Profile  See their activity

  • Posts

    1,354

  • Joined

  • Last visited

 Content Type 

Everything posted by SylvainLS

  1. SylvainLS
    Er, no the snowboards BrickLink has aren’t smaller (size 8 studs x 2 studs). The one that is smaller is this one (size 6 studs x ~1.5 studs).
  2. SylvainLS
    Yes, it must be easy because Studio can do it
  3. SylvainLS
    I do remember hrontos’ technique now you talk about it I never used it though (simpler to use LDraw steps). LDD steps and groups are hierarchical but they are separate hierarchies. LDD groups can span several steps whereas LDraw submodels have steps but their parts can’t be spread into their supermodel steps. So, when converting to LDraw, we can either conserve LDD groups by converting them into submodels, or conserve the steps and break the groups. It could happen that all the parts of a LDD group end up in LDD’s instructions in only one step (no more than four parts then), or strictly consecutive steps or in a strict hierarchy of steps, but I’m pretty sure the only way to see that happening is to use hrontos’ technique. My programs simply read the three interesting parts of the LXF in order: the bricks, the groups, the instructions. The groups are converted to submodels. The parts not in a group are put in the main model. If there are instructions and the user chooses to: in the flat version, the groups are broken and the parts are converted in the order they are referenced in the instructions, each in an LDraw step (to simulate how LDD shows them), and in the hierarchical version, the groups are broken and each step is converted into a submodel, with its parts/substeps in the same order and each in its LDraw step. Flexible parts (one part in LDD) are each converted to a submodel of multiple LSync parts. Assemblies (like minifigure torso) (one part with multiple subparts in LDD) are converted into submodels to keep them grouped in LDraw. So, if you used hrontos’ technique, the hierarchy of groups and the hierarchy of steps are the same. If you choose not to use the instructions, the conversion will only give you the groups, in the order they appear in the LXF (creation order), and if you choose to use the instructions in the conversion, in the flat version, you loose the submodels, and in the hierarchical version, you get the groups and their order as hrontos’ script made them.
  4. SylvainLS
    Update 2020-05-10 Added: 11126 / 11126.dat Ripcord Flexible with Handle Thin for Chima Speedorz (91 Teeth) 14397 / 14397.dat Minifig Head Round 1.8 x 1.8 Biscuit with Filling 16965 / 16965.dat Ripcord Flexible with Handle Thick for Ninjago Airjitzu Flyers (70 Teeth) 62575 / 23714.dat Animal Ant 93064 / 93064.dat Minifig Head Skeleton with Five Spikes 93065 / 93065.dat Minifig Head Skeleton with Helmet Rematched: 3228 / 3228c.dat Train Track Rail Straight Tapered 29592 / 29592.dat Minifig Sports Barbells (renumbered) 71591 / 71591.dat Minifig Helmet Ninja Ornament 93094 / 93094a.dat Figure Friends Lipstick (Complete) (renumbered) Importable: 529.dat / 71591 Minifig Helmet Samurai Horn 25866.dat / 93094 Figure Friends Lipstick Dual Mould md5sum: 8081909e7be5d2fb2370ae96486a3c73
  5. SylvainLS
    Good idea. If there’s an “official” main repository and list, I will add them to ldraw.xml (I can’t usefully do that if everybody does their own version).
  6. SylvainLS
    I looked at it a little bit more (I used a more complex example file ). It appears the LDD steps are in a somewhat meaninigful hierarchy. That means we can use them for submodels (and subsubmodels…). But LDD also puts each part in a step (or at least shows parts one by one). So that makes for a “tétrachiée” (lot) of steps and subsub…subsubmodels. Here is the results of the two options for a small example: no submodels and with submodels. What do you think? (I’d rather not make the choice a suboption.)
  7. SylvainLS
    New version available! As it appears some people loved LDD’s building instructions, I added an option to use them (when present) to make steps. Note that there’s no submodels and LDD’s groups are lost if you use this option. It’s here. And remember the repository keeps an up-to-date ldraw.xml file too (so download it when I update ldraw.xml).
  8. SylvainLS
    New version available! As it appears some people loved LDD’s building instructions, I added an option to use them (when present) to make steps. Note that there’s no submodels and LDD’s groups are lost if you use this option. It’s here. And remember the repository keeps an up-to-date ldraw.xml file too (so refresh your sources (git pull) when I update ldraw.xml).
  9. SylvainLS
    You can’t in Studio. Well, you sort of can if you remove the part list for this step and replace it with your own picture (same with the BOM: fake it in another file and insert it as an image, or simply collate the PDFs when everything is finished). We asked for a way to have “customized composites” (parts we need to break down in the build to pose, like U-joints and minifigure torsos, but that we’d like to be shown as complete in the BOMs).
  10. SylvainLS
    LDraw colour codes (we’re making an LDraw file here). See http://ryanhowerter.net/colors.php for an extensive table with LEGO, BrickLink and LDraw colours names and codes.
  11. SylvainLS
    If you downloaded the zipfile, unzip it. If you downloaded the files, be sure you have ldraw_cliff.html and ldraw_cliff.js together. Now open ldraw_cliff.html in your browser (Ctrl-O should open a file dialog on about every browser). Fill the form and click the button at the bottom. Once the file is ready the link next to the button becomes clickable and you can “download” (save to disk from memory) the LDraw file.
  12. SylvainLS
    Just use 32, 64, 96, etc. Precision: I used the .tri extension but I’m not the only one to have used this extension (meaningful TLA are in a limited number after all). Mine are just plain text files with coordinates, easy to get from LDraw .dat files. I could have taken .dat files directly but then you need flattened (= all subfiles included) files, and it would have added a conversion layer for those who want to make their own files. The same can be said for OFF, STL, or other triangle files: choose one and someone would have wanted another one. As for STL files, indeed, they are just (and already) triangles. You’ll need make a script to convert them to .tri: just ditch anything but the vertices coordinates and put them all on a line, separated with a space. The coordinates are read with the JavaScript parseFloat function, which means it’s the standard C representation (“123.4” or “1.234E2”, etc.). Edit: IIRC, you have a Mac, so awk is readily available (otherwise install it). This should do the trick with STL text files: awk '/vertex/ {t=t $2 " " $3 " " $4 " "} /endloop/ {print t; t=""}' file.stl > file.tri
  13. SylvainLS
    It’s because the heightfield should be the size of the landscape and because the diamond-square algorithm used by ldraw_landscape is recursive and cuts dimensions in 2. It works in 2D but, explained in 1D, it works this way: take a segment, that’s 2 points (2 = 2⁰+1), cut it in 2, compute the middle point, you now have two segments, 3 points (3 = 2¹+1), cut them in two, you now have 4 segments, 5 points (5 = 2²+1), …, at iteration n, you have 2^n segments, 2^n+1 points. (Keywords: Von Koch line (and snowflake), fractal mountains.) On a square, it’s a two time algorithm (the diamond-square algorithm): you start with a square, compute the 4 middle points (diamond), then the center, you now have 4 squares, rince and repeat. But, well, it’s not that important for the end results because: First, I implemented it to act as if the previous iteration was done, so, if you ask for a 7x8 landscape, it acts as if 9x9 was done and computes the four 5x5 landscapes, 3 of which are truncated. But that means the missing points are at 0, not driven by the slope parameter. Second, the heightfield is multiplied with the random landscape, so it doesn’t change the way the random landscape is computed. But I’m not sure I won’t find a better way than a multiplication.
  14. SylvainLS
    Ah yes good idea. The canvas is a necessity to make a PNG the simplest way, its functionning as a real preview is just a bonus I hadn’t really thought of It’s about the same in ldraw_landscape: I need a (visible) canvas to read the pixels in the heightfield image, and it serves as an indication the image loaded successfully (which sometimes doesn’t happen, the joys of JavaScript).
  15. SylvainLS
    Ok, done, new version (I only changed the html).
  16. SylvainLS
    Ah, yes, oopsy, the heightfield is indeed computed each time you upload a file, I hadn’t tested Chromium: in Firefox, you can choose the same file repeatedly. I’ll see what can be done….
  17. SylvainLS
    Okay, so after a few days trying to find out why there were holes with so-called “conservative” voxelization methods, I give up trying to get always perfect results. Indeed, I found a complete implentation (not just theoretical or copy-pasted snippets) and it doesn’t seem to care about holes (this one, it provides input examples files too (so it’s not my input that’s broken)). So, here’s a simple web page to convert a triangle file (text file, one triangle per line, 9 space-separated coordinates per triangle) into a heightfield PNG usable in ldraw_landscape. I put triangle files for all(?) relief baseplates too. Don’t forget to set the size to the size of your landscape (preferably 2^n+1 (65, 129…)) and beware of non square baseplates. And try the different methods and different sizes if you don’t like the results.
  18. SylvainLS
    I’m still considering what’s best and simplest (or the most “good-&-simple”). On the one hand, providing ready-made maps would be the simplest. But size matters: a wrong scale, a too small or too large image or not enough shades of grey or too many, and you risk loosing details when you apply it. That’s why I’d rather people do their own maps. On the other hand, providing a simple way to make a heightmap from a .dat file isn’t easy. The program needs to parse the LDraw library, which can’t be done in a simple HTML page. I could dump my program’s sources somewhere and let people use them but then, that greatly reduces the number of people who could use them (need to compile the C++, have to make everything OS-agnostic…). So, now that I have written that down , I’m leaning toward a middle ground: provide the triangles files for the baseplates along with a simple triangles-to-image HTML page. I can give the choice. They all more or less give the same results, especially for heightmaps, and in about the same times, once optimized. (Plus, optimizing with bounding boxes remove spurious voxels in methods 0 to 2.) As for my method, I think using another algorithm than Bresenham to draw lines should give better results… but I need to find or devise it first
  19. SylvainLS
    Update 2020-04-23 Added: 18585 / 18585.dat Technic Brick 2 x 4 with Holes and Launcher 18590 / 18590.dat Technic Gearwheel Z8 with Pin Holes, Flywheel Socket and Short Shaft 20308 / 20308.dat ~Animal Wolf Head Pixelated 24073 / 24073.dat Minifig Headdress Bandage Wrapped 25977 / 25977.dat Minifig Headdress Banana 30924 / 30924.dat Minifig Arm Bandage Wrapped 93066 / 93066.dat Minifig Head Skeleton with Stud Rematched: 3861 / 3861c.dat Door 1 x 4 x 5 with 4 Panes and Reinforced Hinge 63965a.dat / 64965 Bar 6L with Thick Stop Importable: 4207b.dat / 4207 Ladder 2.6 x 14 with Half-Bumps 3861.dat / 3861 ~Moved to 3861c 3861a.dat / 3861 Door 1 x 4 x 5 with 4 Panes and Two-way Hinge 3861b.dat / 3861 Door 1 x 4 x 5 with 4 Panes and One-way Hinge 63965.dat / 63965 ~Bar 6L with Thick Stop (Obsolete) md5sum: cef45c26fc0ce5ee1aad5e3269dd7ddf
  20. SylvainLS
    You need to copy/paste or delete/add….
  21. SylvainLS
    No need to shout. 32807 is 6091 for BrickLink / Studio. 6091, 42446, 13548 “and so on” are there, if you don’t find them, odds are high you have the checkbox “Hide unavailable colors” checked in the colour palette of the parts palette (not the colour palette on the top right, the one you get via the colour box next to the part search box). That’s a very frequent question on the Studio forum.
  22. SylvainLS
    Just for completeness (black is method 0, blue is method 1, red voxels are obvious errors): So, nobody’s perfect, though 0 doesn’t have any voxel missing (not even the last slice). 1 has less problems on the outside but is missing part of the inside!
  23. SylvainLS
    Okay, green images are the “correct” voxelization, turquoise images are “mine.” That’s supposed to be a 3626c head (a bit stretched). You’ll notice the “correct” voxelization algorithm have problems with the sides, it looks like an apple core I highlighted in red the major problems with my method: the horizontal triangles that form the flat circles go further than the vertical ones for the cylinders. We can also see inside because the last horizontal slice is missing (simple limit issue, it also happens with the “correct” method but is less noticeable as there’s no side). Because the “correct” result was missing the sides, I tried with an even simpler model: 3005.dat. As you see, both are still missing the last slice. Still a couple red voxels for my method, but the “correct” one is also missing the inside box!
  24. SylvainLS
    I think I should feel insulted by the “maybe” Actually, it does not because I don’t use that property in my method: it really draws all the triangles (and fill them) in the voxel space. It doesn’t eliminate lower voxels before they are all found/painted. With the other methods, which go through the whole space for each triangle (loop on all x, all y, all z), I can optimize in two ways: 1. the simplest, do the innest loop in descending z, stop it at the first encountered voxel by the current triangle, 2. memorize the current uppest z for each x,y (so, for all the previous triangles), only look between that and maxz for the next ones. I only implemented the first one not to mess to much with the algorithms while still debugging the rest. Anyway, I found the corner bug: just me being stupid again (rotating only half what should have been rotated). I also thought a bit more (ouch), and realized the other algorithms have their 0,0,0 voxel centered on 0,0,0 (corners at ±0.5). Mine works more like it’s centered on 0.5,0.5,0.5 (corners at 0 & 1). Once corrected, the results are still different but closer. My method doesn’t paint voxels that should be painted. That’s what Bresenham does after all: it draws a line with a minimum of pixels, it does not find all the pixels crossed by the line. So, if I look at all the voxels found (not only the upper ones), I get fewer voxels than the other methods. But it’s not a subset: I find some voxels that shouldn’t be there. Drawing “degenerate” triangles (with a tiny edge) with only one line helps a bit with those supernumenary voxels but not all. Well, so it might explain why it’s not the preferred voxelization method but it doesn’t explain why I didn’t find anyone talking about it. I think it’s a very very fast near-enough method. I’m going to voxelize simpler but more general parts (maybe a minifig head) to better compare the results….
  25. SylvainLS
    Both, that was the intended pun My method seems to have problems in the corners of the image (they are white, they should be Batmanesque (black or very very dark gray)), and as those are where there are tiny vertical triangles (the sides of the rounded corners of the baseplate), I think it’s a problem with too tiny measures. I haven’t investigated yet. (Hmm, simply eliminating too small triangles (making them one point or a line) could solve the issue without my having to think about it too much…. ) And don’t be too overwhelmed by the big words and the name dropping. It’s just for people who want to know or search the names themselves. I only knew about Bresenham because I used it in the 90’s, the rest I found in the last couple of days.
×
×
  • Create New...