General Discussions
Discuss any topics that are not product-specific here.
D22 was a fun one! It was nice to have a pure workflow again (no pen/paper for today). Debugging took me longer than I thought and it seemed like I kept building the same workflow over and over again, thinking it would work until I finished it for the n-th time and remembered why that method wouldn't actually work. I did end up getting things working, and watching my workflow run brought me great satisfaction today for some reason!
Algorithm:
| 1 | 2 | 2 | |
| 3 | 3 | ||
| 5 | 3 | 3 | |
| 4 | 5 |
^The bottom row of our table represents the ground plane (So bricks 4 & 5 aren't going anywhere). On the first iteration, the brown bold-ed bricks are able to drop down 1 unit into free space (Notice that even though brick 2 is in the air and could technically move down too, we won't move it yet because it sits on top of brick 3):
| 2 | 2 | ||
| 1 | |||
| 5 | 3 | 3 | |
| 4 | 5 | 3 | 3 |
^Now brick 2 is also in impeded from below, so on the second iteration, bricks 1 & 2 will move down, but brick 3 is now on the ground plane and won't move any more.
| 2 | 2 | ||
| 1 | 5 | 3 | 3 |
| 4 | 5 | 3 | 3 |
^After the third iteration, all blocks are now unable to drop any further and the macro would be complete.
We can now solve part one, by adding the count of all blocks with nothing above them (bricks 1 & 2) with the count of all bricks with bricks above them, which all have multiple bricks below them (bricks 3 & 5;
Example 1) brick 3 has brick 2 above it, and brick 2 has both bricks 3 & 5 below, so brick 3 is valid. The same argument applies to brick 5.
Example 2) brick 4 has brick 1 above it, but brick 1 only has brick 4 below, so brick 4 is invalid).
For part 2, we now want to solve essentially the opposite problem, we want to know how many bricks will fall if we disintegrate any given brick. This is trickier than it may seem at first because even though removing a brick may cause nothing to happen, deleting the brick underneath it may cause everything to fall.
The first thing that I did to approach this problem was to create a Connection List, that stores all the bricks connected above a given brick:
| 4 | 4 | |
| 3 | 5 | |
| 1 | 1 | 2 |
^The Connection List for the case above would look like this:
| ID_B | ID_T |
| 1 | 3 |
| 1 | 4 |
| 2 | 5 |
| 3 | 4 |
| 4 | |
| 5 |
^We can see from our connection list that bricks 4 & 5 have nothing above them (since [ID_T] is null). We can also see that brick 1 is underneath and connected to bricks 3 & 4, but not to brick 5, which is only connected to brick 2.
Using this Connection List and the Validity List (from part 1, which contains only information on direct neighbors), We can do a double join to determine all necessary bricks, B_i that need to be above a brick, A, so that brick C, which is also above brick A will fall when brick A is disintegrated. That is a tremendous mouthful and may be confusing so here is a diagram that should hopefully help clear things up a little. Join 1 looks like:
^Looking at the above image (see shaded cells) we now know that in order for brick 4 to fall if brick 1 is disintegrated, then brick 1 needs have brick 3 on top of it, which we know it does, but in order to verify, we can do our second join (using the Join Multiple Tool in order to get a full outer join) between Output Join 1 List and the Connection List. Joining on [R-ID_B] = [ID_T] and [L-ID_B] = [ID_B], respectively. If no match is found (i.e. Null), then the brick being considered, [L-ID_T], will not fall when the corresponding brick underneath it, [L-ID_B], is removed.
The only issue to account for with this method is that if a match is not found, there may still be matches found for every brick above that one, which will cause an error in counting since the bricks above cannot fall unless the brick below does too. This can be handled by propagating nulls up the brick chain with another iterative macro.
With the nulls properly accounted for we can now filter out any bricks, [L-ID_T], that have any nulls associated with them and count the remaining rows to achieve the answer!
Note: Some ambiguities are intentionally left unexplained to provide a challenge to the reader to solve as much as possible on his own.
Workflow:
Drop Bricks (Iterative Macro):
Build Connection List (Iterative Macro):
Null Propagation (Iterative Macro):
Happy Solving!!!
Fun challenge...
...except I was too brain dead to optimize P2. Fortunately, brute force did work with a batch/iterative macro combo that ran in 18 minutes:
P1 - I think I had a similar logic to @AndrewDMerrill. The hardest part was figuring out how to organize the x,y,z grid for my macro to work correctly. My initial attempt left a lot of floating bricks with the full dataset:
Settle Macro (every other macro is some variation of this one or uses this one inside a batch macro):
P2 - Brute force all the way. I used a second workflow to pass the results from P1 since I didn't know how long it would take to run:
I learned the viz is very important for debugging again. Because I fell the blocks under the floor or insert a block into another block... At this quiz, the sample data did not work well.
The macro to fall the blocks for 3D TETRIS.
In this macro, I got the position where the blocks is. In other words, these are the coordinates where the blocks touch each other.
And also, I need to consider the pattern below.
66
445
233
11
If I disintegrate the block 3, the block 5 will fall down. So I can NOT break the block 3. It took too long time to find this pattern.
The workflow fot part 1:
Part 2 :
I can use the result of part 1 macro. I created a list that the block supports another one independently, so I look at the parent-child relationship one block at a time based on this list. In order to view each block one by one, iterative macro is called in a batch macro, and the iterative macro itself counts the number of bricks that fall when one brick is destroyed, and the batch macro runs the entire process.
Batch macro :
Iterative macro :
Final workflow :
Tetris was nostalgic for me because I used to make it with Z80 assembly. Part2 was solved with the relationship between the supporting blocks.
