Wow, this is great. Your code succeeds at being very efficient while being reasonnably simple and short. I did not know the ListCorrelate[] command, but it is very effective here.

Also, randomly trying the pieces is not really efficient.

Yes, I agree with this, it ts the most basic way, and the least efficient

For instance, randomly combining rotation matrices and hoping you'll eventually get all necessary rotations just doesn't feel good

I disagree with this. While it effectively uses RandomChoice[], in practice there is no randomness in the results for all pieces orientations (thanks to the large number of tries), and it is fast enough (and it needs to be done only once for a given set of pieces). I think it is a matter of taste, but for me it was a lazy way to get all possible orientations without the risk of forgetting some combination of transformations. :-)

Thank you for the notebook - many things to learn !

It's possible to look at this problem from a slightly different angle and reduce it to a graph-theoretical clique finding problem. This is useful because we already have a fast (maximal) clique finder built into Mathematica. I will only give an implementation for the most basic case, i.e. filling out the 3 by 3 by 3 cube, as in illustration.

In graph theory a clique is a complete subgraph, i.e. a subgraph in which all pairs of nodes are connected.

The idea

Let us construct a graph, where the nodes are all possible placements of each individual piece in the fit space. That is, we must generate all rotations of each piece (rotatedPieces from Sjoerd) and all possible positions of each of these within the fit space.

Then we connect two nodes (i.e. placements) if they are not overlapping. If we are not allowed to re-use the same piece twice, then we we only connect non-overlapping placements of different pieces.

Now any valid arrangement of pieces is a clique. That's because an arrangement is valid no two pieces overlap, i.e. they are connected in the graph. Finding a maximal clique means cramming enough pieces in the fit space so that no more can be added. We have 7 pieces and want to use them all. So we need to find cliques of size 7.

Implementation

Let us implement this for a 3x3x3 fit space starting form Sjoerd's piecesAsObjects list.

The following function generates all translations of a rotated piece within the fit space:

allTranslations[p_] :=
 Module[{pad},
  pad = (3 - Dimensions[p]);
  pad // Map[Range[0, #] &] // Tuples // 
    Map[Transpose[{#, pad - #}] &] // Map[ArrayPad[p, #] &]
  ]

We collect these in a list of lists:

allTrans = 
  Map[allTranslations /* Apply[Sequence], piecesAsObjects, {2}];

Each sublist contains all possible placements (including rotations) of a piece.

The following function tests for overlap between two placements:

overlapping[{a_, b_}] := Total[a b, Infinity] > 0

We only want to add connections between different pieces, so we start with Subsets[allTrans, {2}]. Then for each piece-pair we add connections for non-overlapping placements.

edges = (UndirectedEdge @@@ Select[Tuples[#], Not@*overlapping] &) /@ 
   Subsets[allTrans, {2}];

This was the most time consuming part. It took over a second on my machine. This can probably be done much faster with ListConvolve/ListCorrelate, like Sjoerd did.

Now we have our graph:

g = Graph[Join @@ edges];

The vertices are actual 3D placement arrays, but if you prefer to work with indices instead, use IndexGraph.

We are now ready to use FindClique, but we must do so carefully. There are a huge number of cliques in this graph, and trying to find all of them would take impractically long (and would likely cause the machine to run out of memory). A simple FindClique[g] "finds a largest clique in the graph", according to the documentation. This is a bit misleading. You might think that finding only one largest clique shouldn't be slow. The problem is that the algorithm must iterate through all maximal cliques to decide which is the largest, so it will in fact enumerate all of them. But luckily we already know the size of the largest clique: it is 7, i.e. containing all pieces. So we can stop the search as soon as we find a clique of size 7. This is done by

FindClique[g, {7}]

We can ask Mathematica to find more, say 10 of them. I'll do this in a way so only placement indexes are shown and the output is clearer:

FindClique[IndexGraph[g], {7}, 10]

{{12, 132, 301, 428, 473, 578, 625}, {12, 231, 301, 403, 522, 573, 
  625}, {12, 231, 301, 403, 521, 604, 625}, {91, 251, 301, 389, 518, 
  611, 625}, {91, 251, 301, 389, 502, 620, 625}, {91, 271, 301, 414, 
  518, 575, 625}, {91, 201, 301, 413, 527, 544, 625}, {91, 164, 301, 
  380, 480, 620, 625}, {91, 225, 301, 428, 480, 617, 625}, {91, 225, 
  301, 428, 520, 568, 625}}

Let's write a function for plotting placements:

plotClique[cl_] := 
 Graphics3D[
  Raster3D[Total[cl Range@Length[cl]], 
   ColorFunction -> ColorData[97]], Boxed -> False, 
  SphericalRegion -> True]

plotClique /@ FindClique[g, {Length[pieces]}, 10]

We can ask for even more arrangements. Finding 200 takes 2 seconds on my machine.

FindClique[IndexGraph[g], {7}, 200] // Length // AbsoluteTiming

{1.87257, 200}

This is just meant to show the idea. It would be nice to implement this in a general way, for all kinds of fill spaces, and making use of ListCorrelate.

Update Finding all cliques of size 7 took quite a bit longer. It took ~1000 seconds on my machine and came up with 11520 cliques. Many of these arrangements are equivalent. We have 24 rotations and 2 reflections of a single arrangement. In reality there are only 11520/(2*24) = 240 distinct ones.

This result, together with Wikipedia's claim that there are only 240 truly distinct arrangements, implies that none of the arrangements have any rotational of reflection symmetries. Otherwise we would find fewer than 48*240 cliques.

Update 2: If I use IGMaximalCliques[g, {7}] from the IGraph/M package (an igraph interface I made for Mathematica), I get the result in merely 60 seconds instead of 1000 seconds with the builtin FindClique.

IGraph/M does not yet support finding only a limited number of cliques. It returns all cliques that satisfy the size criteria. I plan to add this feature in the next IGraph/M release, which will also bring additional clique finding performance improvements.

Update 3: Somewhat surprisingly, IGCliques[g, {7}] returns the result in only 0.8 seconds. IGCliques finds all cliques, not just maximal ones. In this case, all size-7 cliques are clearly also maximal, so we might as well use IGCliques.

@Thibaut Jonckheere Is it also possible to make the program learn about the game? Say, rather trying brute force all the solutions it can intelligently decide some better moves?

I have attached the notebook version of the code (SOMA set of pieces) for convenience. It contains all the code (the pieces names are still "incorrect", but the pieces themselves are ok), and a few examples.

Attachments:

Indeed, it is nearly the same problem ! Thank you for letting me know about SOMA.

The only difference is in the pieces set, which is here:

The 4 first pieces are also present in Easy Cube, the last three are different (the total volume of the 7 pieces is the same: 27 "unit cubes", which means the two games share identical problems).

Adapting the code is very easy: only three of the piece definitions need to be changed, and the rest of the code can be used as it is. Here is for example two solutions of problem 426 (as shown in your picture) with SOMA pieces:

The difficulty of these problems is probably higher than the Easy Cubes one. For the above solution of problem A426, I made two runs, using respectively ~88000 and 75000 iterations. This probably means that there is only a very small number of different solutions, and finding the solution is more time-consuming (typically between 10 minutes to a small multiple of it ?!). So the code given here should work for all the SOMA problems, but using a more advanced method (e.g. the dancing links algorithm by D. Knuth mentionned by Sander Huisman) would be a good idea if one needs all solutions of all problems... But anyway it is nice to see that a very naive method, quickly progammed, can give solutions.

Adapted code: definition of the pieces for SOMA problems (I did not make the effort to change the pieces names... the new pieces replace the definition of PLine, PSquare and PBulky, all the rest is unchanged)

Pieces Definitions
In[2]:= PTriangle = {{0, 0, 0}, {0, 1, 0}, {1, 0, 0}};
In[3]:= PSquare = {{0, 0, 0}, {0, 0, 1}, {1, 0, 0}, {1, -1, 0}};
In[4]:= PLine = {{0, 0, 0}, {1, 0, 0}, {0, 1, 0}, {0, 1, 1}};
In[5]:= PL = {{0, 0, 0}, {0, 1, 0}, {1, 0, 0}, {2, 0, 0}};
In[6]:= PPodium = {{0, 0, 0}, {0, 1, 0}, {-1, 0, 0}, {1, 0, 0}};
In[7]:= PSnake = {{0, 0, 0}, {0, 1, 0}, {1, 0, 0}, {-1, 1, 0}};
In[8]:= PBulky = {{0, 0, 0}, {1, 0, 0}, {0, -1, 0}, {0, 0, 1}};
In[9]:= (* Rotation by angle \[Pi]/2 matrix*)
In[10]:= Mrotz = {{0, 1, 0}, {-1, 0, 0}, {0, 0, 1}};
In[11]:= Mrotx = {{1, 0, 0}, {0, 0, 1}, {0, -1, 0}};
In[12]:= Mrotx = {{0, 0, -1}, {0, 1, 0}, {1, 0, 0}};
In[13]:= (* Reflection  matrix *)
In[14]:= Mrefx = {{-1, 0, 0}, {0, 1, 0}, {0, 0, 1}};
In[15]:= Mrefy = {{1, 0, 0}, {0, -1, 0}, {0, 0, 1}};
In[16]:= Mrefz = {{1, 0, 0}, {0, 1, 0}, {0, 0, -1}};
In[17]:= MUnit = {{1, 0, 0}, {0, 1, 0}, {0, 0, 1}};
In[18]:= (*Operators which peform a given number of rotation, and of \
reflection*)
In[19]:= RotatePiecex[piece_, n_] := Nest[Mrotx.# &, #, n] & /@ piece
In[20]:= RotatePiecey[piece_, n_] := Nest[Mrotx.# &, #, n] & /@ piece
In[21]:= RotatePiecez[piece_, n_] := Nest[Mrotz.# &, #, n] & /@ piece
In[22]:= ReflectPiecex[piece_, n_] := 
 If[n == 0, (MUnit.#) & /@ piece, (Mrefx.#) & /@ piece]
In[23]:= ReflectPiecey[piece_, n_] := 
 If[n == 0, (MUnit.#) & /@ piece, (Mrefy.#) & /@ piece]
In[24]:= ReflectPiecez[piece_, n_] := 
 If[n == 0, (MUnit.#) & /@ piece, (Mrefz.#) & /@ piece]
Each piece with all the possible orientations
In[25]:= MakeAllPieces[piece_] := 
 DeleteDuplicates@
  Table[Module[{Rota, Rotb, Rotc, Refa, Refb, Refc, na, nb, nc, ma, 
     mb, mc},
    Rota = RandomChoice[{RotatePiecex, RotatePiecey, RotatePiecez}];
    Rotb = RandomChoice[{RotatePiecex, RotatePiecey, RotatePiecez}]; 
    Rotc = RandomChoice[{RotatePiecex, RotatePiecey, RotatePiecez}];
    Refa = RandomChoice[{ReflectPiecex, ReflectPiecey, ReflectPiecez}];
    Refb = RandomChoice[{ReflectPiecex, ReflectPiecey, ReflectPiecez}];
    Refc = RandomChoice[{ReflectPiecex, ReflectPiecey, ReflectPiecez}];
    na = RandomInteger[{0, 3}]; nb = RandomInteger[{0, 3}]; 
    nc = RandomInteger[{0, 3}];
    ma = RandomInteger[{0, 1}]; mb = RandomInteger[{0, 1}]; 
    mc = RandomInteger[{0, 1}];
    Refc[Rotc[Refb[Rotb[ Refa[Rota[piece, na], ma], nb], mb], nc], 
     mc]], {i, 1, 2000}]
In[26]:= PTriangleAll = MakeAllPieces[PTriangle]; Length@PTriangleAll
Out[26]= 24
In[27]:= PSquareAll = MakeAllPieces[PSquare]; Length@PSquareAll
Out[27]= 48
In[28]:= PLineAll = MakeAllPieces[PLine]; Length@PLineAll
Out[28]= 48
In[29]:= PLAll = MakeAllPieces[PL]; Length@PLAll
Out[29]= 24
In[30]:= PPodiumAll = MakeAllPieces[PPodium]; Length@PPodiumAll
Out[30]= 24
In[31]:= PSnakeAll = MakeAllPieces[PSnake]; Length@PSnakeAll
Out[31]= 24
In[32]:= PBulkyAll = MakeAllPieces[PBulky]; Length@PBulkyAll
Out[32]= 48
In[33]:= tPieces = {PBulkyAll, PLAll, PPodiumAll, PSnakeAll, PSquareAll, 
   PLineAll, PTriangleAll};
In[34]:= tPiecesNames = {"Bu", "Ll", "Po", "Sn", "Sq", "Li", "Tr"};

Example of use on problem A

Solve problem A426 
In[71]:= coordA426 = 
 Join[Table[{0, j, 0}, {j, -3, 2}], Table[{1, j, 0}, {j, -3, 2}], 
  Table[{-1, j, 0}, {j, -3, 2}],
  Table[{0, j, 1}, {j, -1, 2}], Table[{-1, j, 1}, {j, -1, 2}], 
  Table[{-1, j, 2}, {j, 2, 2}]]
Out[71]= {{0, -3, 0}, {0, -2, 0}, {0, -1, 0}, {0, 0, 0}, {0, 1, 0}, {0, 2, 
  0}, {1, -3, 0}, {1, -2, 0}, {1, -1, 0}, {1, 0, 0}, {1, 1, 0}, {1, 2,
   0}, {-1, -3, 0}, {-1, -2, 0}, {-1, -1, 0}, {-1, 0, 0}, {-1, 1, 
  0}, {-1, 2, 0}, {0, -1, 1}, {0, 0, 1}, {0, 1, 1}, {0, 2, 
  1}, {-1, -1, 1}, {-1, 0, 1}, {-1, 1, 1}, {-1, 2, 1}, {-1, 2, 2}}
In[72]:= TheGridA426 = GridDefine[coordA426];
In[73]:= Plus @@ Flatten[ 1 - TheGridA426]
Out[73]= 27

In[75]:= SolgridA426ex1 = SolveGridBare[TheGridA426];
During evaluation of In[75]:= 88530
In[78]:= PlotGrid3D[SolgridA426ex1, All]

- another post of yours has been selected for the Staff Picks group, congratulations !

We are happy to see you at the top of the "Featured Contributor" board. Thank you for your wonderful contributions, and please keep them coming!

Thank you for the info ! I did not know the dancing links algorithm. Having a look at the wikipedia page about it, it seems very interesting (and way more powerful than my basic algorithm). I have matter to study here.