Lasse D

With that praise it sounds like I should give the latest version of LPub a new chance (rather than my old love being the nearly-command-line version).

I'm working on a connection-based format for the problem with angles as there are only 8 place on a brick to which angled connections can be made. The nice thing about my (old) format is how easy (fast) it is to construct and compare combinations, and as CP5670 points out, it is a challenge to do fast comparisons using the connection based ideas. I have not profiled my code, but I suspect these comparisons take up a great part of the computation time. You do not have to store all 900M combinations in memory at once. For the old problem I only stored all combinations where the number of bricks for each layer was given (saving 3 bit pr. brick), taking them one by one. As an example: "2 1 2 1" means 2 brick on layer 0, 1 on layer 1, 2 on layer 2 and 1 brick on the top layer. To construct all these combinations I simply iterated through all combinations with 5 bricks from which you can add a single brick to get one of this type. For this example that means the combinations of type "2 1 2", "2 1 1 1", and "1 1 2 1". This saved me roughly a factor 10 in space usage. (I could have used 55 bit just as in your suggestion since I save the 3 bytes for the layer of every brick, so the data structure should simply store 64 bit ints). It's not the space usage I'm worried about. We can easily come up with great ideas to save space, custom search structures et al - it's the branching that makes me unruly!

As for the current configurations I can give a little insight into the memory usage. Assume for simplicity that we are building configurations of size 6. A brick has a position (x,y), a layer (z) and orientation. We can assume the first brick is always at (0,0,0) and vertical. Now we only have to store 5 bricks. Having the first brick at (0,0) makes any leagal brick be in the x/y interval of -15 to 15, so we need only 7 bits to represent an x or y position. There are only 6 layers a brick can be at (3 bit), and the orientation is either vertical or horizontal (1 bit), so storing a brick requires: 5+5+3+1 = 14 bits or < 2 bytes. Assume for simplicity that we use an array to store the bricks. This leads to 10 bytes for a configuration. I got lazy and used stl set for storing configurations. I didn't check the maximal memory usage, but the program crashed on my 4GB laptop. Running it on a larger machine with more memory took less than an hour on a single 3.2GHz Xenon. This is a significan improvement over the full week than what it took the original program of the original paper (roughly one week on a machine using Java), so I expect that it might be feasible to find all configurations now. You can do better using custom data structures (rather than stl set), but this was fast enough for me. As for now, I will look into configurations of size 4 to get an idea of the nature of the problem.

Correct. The program becomes much, much more complicated, but it annoys me that no one knows the correct answer. That's what worries me as well. What I really need are some good reductions to limit the search space. One such reduction is that I know there are no new configurations for less than 4 bricks. Now I only have to consider configurations with 4, 5 and 6 bricks! That's a restriction I make because LEGO doesn't consider "non-clicked" connections valid, so no use of tubes or half-on-connections for this experiment.

You have some good ideas about how to attack this problem. My program favors simply trying out all combinations, but getting all combinations with cycles seem to be a tough challenge. For 1 to 3 bricks you can try to combine them and see that no matter what you do, you can always turn the knobs and become axis-aligned. For 4 bricks you can combine them at different angles. Now the question is: how many?

That's a good point. I suggest we call any given (static) way of connecting the bricks a model. Given a model, a congifuration is the set of all models which you can obtain by turning the model or the connections between bricks of the model. A configuration is called axis aligned if it contains a model where all the bricks are axis-aligned. The previous results count all axis-aligned configurations. I want to compute all configurations without the restriction of being axis-aligned. From fiddling with bricks it's clear that these two numbers are equal for combinations with between 1 and 3 bricks. Once we have four bricks, we can start forming configurations which are not axis-aligned and thus not counted by the official numbers.

Yes, but that's still only a single combination. The ways the combinations have been counted have been by only considering 90 degree angles between the bricks (aka axis aligned), considering all other combinations as invalid. This restriction makes sense from a programming point of view as writing a program that finds all combinations is much easier once you restrict the combinations to be axis aligned. I say: Don't restrict the counting just because it's harder to write a program.

I have just finished my own little program to check the common LEGO trivia of "how many combinations are there of X 2x4 bricks". My findings are: 1: 1 2: 24 3: 1560 4: 119580 5: 10166403 6: 915103765 This took the program a little less than an hour to compute. Using http://oeis.org/A112389/list one can find the next two numbers: 7: 85747377755 8: 8274075616387 Many results on the Internet seem to have a typo when it comes to the number of combinations with 5 bricks, citing "10116403" rather than the correct "10166403". This typo seems to come from the latest paper in the area: "On the entropy of LEGO" http://www.math.ku.dk/~eilers/papers/lego.html and has spread to pages like - Brickpedia: http://lego.wikia.com/wiki/LEGO - Classic castle: http://www.classic-castle.com/forum/viewtopic.php?f=13&t=12780 - Opentopia: http://encycl.opentopia.com/term/Lego 45 or so other results according to google. I would like to ask the community. Do you think it's fair that we only count the number of combinations where all bricks are at perfect 90 degree angles? The round studs of LEGO bricks allow us to turn the bricks at any angle and using these bricks we can make many other interesting configurations than those found using these computer programs. Think for instance of the six bricks forming a hexagon. If we count all combinations including hexagons and such, then I'm sure there are more than a billion combinations for six bricks. If the community agrees that this is a more correct way of counting, then I would like to give it a try to find the actual number.

Thanks. Exporting to various formats is thankfully an easy task once you have all the groundwork covered (making the instructions). The most difficult part would be to allow the user to say "this piece should already have been put onto the model a step before" or "this should be a sub-model". All these changes have to happen in the program I'm designing (unless InDesign and Illustrator have some awesome functionality that I don't know of). Still. This is a project which is very young and I have other programs which have to be completed before this... there's always a lot of programming to be done.

The latest version of LPub that I have tested, which is the first one where they displayed pictures simply couldn't load my models. I don't know if they have gotten better, but for now I'm fine using MLCad to construct everything and the old version of LPud to make the pictures. I am planning on pulling LPub out of the loop and simply use the LDraw as a command-line program for my instructions - that way I can get rid of all the old LPud quirks (doesn't save state, redraws all images and has very poor default values).

Does Adobe Illustrator use an open format? I'm developing software that takes MLCaD models (ignoring any step information). My program then creates all the steps, sub-models, rotations, arrows, parts call outs and stuff as needed before exporting. If Illustrator uses an open format, I might bea ble to export to it, thus reducing the amount of manual labor significantly. (Unfortunately my own instructions are often too large for LPub to handle) Right now I have only made the most basic stuff work and I still use an old version of LPub to make my instructions. Steps are also still created manually.

The video was finally uploaded. See OP. The new L motor seems to be superior to the M motor in many ways: Nearly same speed but with substatially more torque, better mounting points (for Technic models) and doesn't seem to use much more power. I await Philo to add it to his experiments and motor comparisons.

I have just obtained the motors. My camera is currently recharging, but I expect to present motor characteristics ASAP. Until then, enjoy the latest photos on TechnicBRICKS. I have brought out my scale and ruler to give some preliminary info for comparison of all PF motors: Motor: Length, width, height, cable length, weight Medium: 6, 3, 3, 19.9cm, 33g Large: 7, 3, 4, 19.8cm, 44g XL: 6, 5, 5, 19.5cm, 71g Servo: 7, 3, 5, 20.4cm, 42g There are also some preliminary speed info in the crawler thread. Update I finished recording a video of the motors right before the camera went out of power. The upload is at 15% with 126 minutes remaining before the youtube video is ready. I have also takes a couple of pictures where you can see all 4 motors together:

Seriously!? The speed of this thing is much greater than what you see the typical trial truck perform at. Add to that the design which has to be sturdy enough for childrens play while still being buildable by a child and you have a great model - even when considering AFOL models. IMHEO.

You say that "like" and "fav" would help you a lot. If you could tell us what you mean with "like" and "fav", then we would be able to help you. But how, exactly, do you need help?

Nice to see another person have a go at GBC. I have to ask you to repeat what you say here, though:

I have updated OP with their later addition of pictures which show the size of the motors better. The new L motor is especially interesting for me where the XL motor is just a bit on the "big boned" size when building motorized Model Team, resulting in abysmal ground clearance.

Update I have uploaded a video with the new motors in action showing their characteristics. The good people over at technicbricks show and present their initial thoughts of the upcoming PF L and Servo motors. There will be two L motors in the rock rawler! http://technicbricks.blogspot.com/2012/05/first-quality-images-for-2h2012-lego.html Update: More pictures at this update.

Resize the pictures (800px max preferred) before zipping and uploading. Brickshelf is very slow for larger pictures.

Thanks for putting up pictures of how it looks. You are probably right regarding the connection. I tried this mod myself (thanks Holodoc for letting me mess with your models) and I don't like the flat background compared to the original model. I will try to make a true 3 wide model and see if it can work out.

Finally I'm not tired! Yay! Thanks for a great event, guys. BTW. I ran from the bill. Who should I contact about this?

Thank you. I will try to find this information desk, or anything similar .

And I have arrived safely near Billund. Where is everyone meeting up tomorrow, and where? 7AM at the Camp site?

OK. I will just be somewhere in Billund Thursday morning... I'm sure I will find you guys... somewhere.

>VMLN8R That is the redeeming quality here. We critique the models, not the builders (As opposed to local lugs where there is an infinite amount of personal drama. This is why I post mostly on EB - because it's about the bricks!)