3 ms·

Ages ago I built a 'lego' system. Basically I figured out you could build any lego shape from 5 basic voxel types, cube, bevel, cone segment, sphere segment,

Ages ago I built a 'lego' system. Basically I figured out you could build any lego shape from 5 basic voxel types, cube, bevel, cone segment, sphere segment, cylinder. Think I was calling them lego atoms, as you could scale the resolution depending on the amount of detail you needed. Not sure if that is true anymore with the more interesting shapes they have introduced. Not sure only 4 would cut it anymore. I only took it to the paper/whiteboard design stage. The problem I had was voxels became wildly more memory consuming when you introduce more than a binary there not there type. I was looking at 10-15 megabytes in memory just to describe a simple 2x4 brick with the min resolution and it still worked as a lego. At the time I was lucky I had 96MB... The exe was pretty small (maybe 1-2MB total). The data on the other hand I could not find a nice way to compress it enough to work without a few dozen bricks filling my memory space. Mostly I got bored with the project and moved on. The 'voxel' style has one very nice quality about it over the ldraw cad system. Unintentional gaps are nearly impossible to have and overlap is dead easy to find. Correct overlap lets you do interesting things in that you can intersect things correctly and it will just work on the snap grid. The ldraw system has to jump thru a few hoops to make it look like it is working. The effect is the same but more of a pain making sure your floating point is correct. ldraw has a nice quality in that rotating an object in freespace is 'cheap' and you only have to rotate a few points. Whereas a voxel system like I designed you in effect have to rotate everything. At this time the ldraw system is the choice to use if you are doing this though. When I built my system there were maybe 200 different bricks total. Now there are thousands.

pavlovskyi 5y ago
Love it! I started to working at my side project on lego classification and detection algorithm to identify what set could you build from bricks scattered on the floor. What change is that I am not that aware of memory consumption as in your project in the past. All best!
- sumtechguy 5y ago
  I had toyed with that idea. This was before ML visualizers had become decent. I was going to use the set numbers to help me figure out what I could or could not do. Think there are a couple of online resources that do that. There are a lot of sets so currently a "i have a pile of xyz pieces" and then just exhaustively going through them maybe with a % complete would be simple enough if you had a complete library of what pieces were in each set. You could get a bit clever with 'i have x piece which set is that in' and filter it down. Not sure if you could get away without it being basically O(m^n) though. But given how small the existing number of sets is compared to the compute power most computers have these days that may not be that bad to just brute force it? It really becomes a combinatoric problem and there are a lot of algs to choose (hehe) from. I personally was noodling with 3 or 4 SQL queries that did it. With ML detection you can get a good ways decently the hard part is 'hidden' feature. Depending on orientation with some pieces they will hide features. For example a 2x4 flat looks the same as a 2x2 flat on many orientations (extreme example but shows off the effect nicely). I have seen some people use tumbling the piece or a few cameras to mitigate the issue. My proj was more along the lines of how do you represent a single piece in memory without using a planar point system such as what ldraw did. I had toyed with the idea of converting between the two systems for memory reasons. But it became compute/IO expensive very quickly on collision detection with other pieces.
  - pavlovskyi 5y ago
    The real interesting thing in fact is that I did not even conclude issues that you meant. At the moment I focused only on ml/dl algorithm and its ‚accuracy’, but its center of gravity lays stricly in form of gathered dataset. It gives me that feeling that I am missing something right now and it wont be usable on production level. Indicating what set you could build from predicted bricks should not be hard because as far as I know there are official APIs which allows you to gather specific information about each set. Thank you for explaining part of your side project, it was really interesting!
    - sumtechguy 5y ago
      nice! You could brute force it a bit? May take a little bit of work. But you could take the part descriptions from ldraw (from ldraw.org). Have a decent way to render a piece (and random known colors). Then feed in those pictures/pieces as random orientations to your net? That may let you automate it very nicely? You would basically cut out a huge time sink of the hardware bit and get a net that is 'close'? Then once it is close you can add in the hardware bit? If you wanted to simulate random pile of bricks you could use something like one of the physics simulation engines and add in random bricks and let them flop where they can? That could give you some input values for your net fairly quickly?

pavlovskyi 5y ago

Love it! I started to working at my side project on lego classification and detection algorithm to identify what set could you build from bricks scattered on the floor. What change is that I am not that aware of memory consumption as in your project in the past. All best!

sumtechguy 5y ago
I had toyed with that idea. This was before ML visualizers had become decent. I was going to use the set numbers to help me figure out what I could or could not do. Think there are a couple of online resources that do that. There are a lot of sets so currently a "i have a pile of xyz pieces" and then just exhaustively going through them maybe with a % complete would be simple enough if you had a complete library of what pieces were in each set. You could get a bit clever with 'i have x piece which set is that in' and filter it down. Not sure if you could get away without it being basically O(m^n) though. But given how small the existing number of sets is compared to the compute power most computers have these days that may not be that bad to just brute force it? It really becomes a combinatoric problem and there are a lot of algs to choose (hehe) from. I personally was noodling with 3 or 4 SQL queries that did it. With ML detection you can get a good ways decently the hard part is 'hidden' feature. Depending on orientation with some pieces they will hide features. For example a 2x4 flat looks the same as a 2x2 flat on many orientations (extreme example but shows off the effect nicely). I have seen some people use tumbling the piece or a few cameras to mitigate the issue. My proj was more along the lines of how do you represent a single piece in memory without using a planar point system such as what ldraw did. I had toyed with the idea of converting between the two systems for memory reasons. But it became compute/IO expensive very quickly on collision detection with other pieces.
- pavlovskyi 5y ago
  The real interesting thing in fact is that I did not even conclude issues that you meant. At the moment I focused only on ml/dl algorithm and its ‚accuracy’, but its center of gravity lays stricly in form of gathered dataset. It gives me that feeling that I am missing something right now and it wont be usable on production level. Indicating what set you could build from predicted bricks should not be hard because as far as I know there are official APIs which allows you to gather specific information about each set. Thank you for explaining part of your side project, it was really interesting!
  - sumtechguy 5y ago
    nice! You could brute force it a bit? May take a little bit of work. But you could take the part descriptions from ldraw (from ldraw.org). Have a decent way to render a piece (and random known colors). Then feed in those pictures/pieces as random orientations to your net? That may let you automate it very nicely? You would basically cut out a huge time sink of the hardware bit and get a net that is 'close'? Then once it is close you can add in the hardware bit? If you wanted to simulate random pile of bricks you could use something like one of the physics simulation engines and add in random bricks and let them flop where they can? That could give you some input values for your net fairly quickly?