This project is a thought experiment for how to power Bongo for Rhino with Python power. For those who are confused and think I may be talking about actual animals or musical instruments, Rhino is a 3D modelling software, Python is a programming language and Bongo is an animation platform for Rhino. Rhino is more commonly used in industrial design than architecture. Even when it is used, it is often just for design development and visualisation. This is unfair, as Rhino can be trained to do far more if you have the right know how. It is far more precise for modelling than Maya or 3D StudioMax, better for 2D drafting than AutoCAD, and more geometrically capable and a better user interface than Sketchup. The only thing it lacks is an inbuilt BIM system for producing 2D and 3D simultaneously like in ArchiCAD or Revit. Python programming offers vastly superior parametric and algorithmic design possibilities to GUI based tools like Grasshopper, and better interoperability with other programs that also use Python. The dream then, is to do as much design as possible in Rhino then export to a BIM package to use the 2D drawing production power of BIM to translate this into drawings, thus spending as little modelling time as necessary in BIM software that is clunky to model in. Bongo is never going to be a full on character animator that you might find in 3D StudioMax or Maya, but for simple animations it is perfectly adequate. However, manually adjusting the timeline keyframes can be tedious and error prone. While as far as I am aware there is no Python functions for directly controlling Bongo, it is possible to get around this by making macros of Bongo commands and enclosing them in Python logic with variables.

As a metaphorical demonstration project of applying python for construction visualisation, lets say we wanted to make an animation to explain to someone how a brick wall is made. Obviously, we all know how brickies make a wall, and we are not going to bother trying to animate every detail. But as an abstraction, the bricks are dropped from the sky, then the cement is added. This first one was done manually for a small number of bricks as a test. Each brick is released at one keyframe, then finds its way to the ground 10 keyframes later. This is a fair enough for a small number of bricks, but what if you had a big number? It would be bloody tedious and prone to accidentally corrupting the timeline. What if the boss decided that he wanted even more bricks or, wanted them dropped faster, or wanted them staggered? Now it is worth making a code.

Before we try animating, we need to be able to generate the Bricks algorithmically. Think of a brick wall as a grid of stacked rows. Each Row is a class object, which knows how many bricks are in it, and how high off the ground they need to be. Every second row needs a half brick at the start and finish. We also need to have a list of all our rows. Each brick is also a class object, with a volume box made from height, width, length parameters and all constructive geometry deleted. It should also know its position in the row and in the global brick list. By placing them as objects in space relative to the previous brick in the sequence, and storing them in a list, we can give each brick unique properties based on its position. Now we can start animating. By default, we get 100 'ticks'. But maybe you have more than 100 bricks, so you need to add more ticks. The code can add extra ticks, then evenly distribute the keyframes across the timeline. Each brick is programmatically told to fall after its predecessor in the list.

We can also start to change more than just the Z value. In this example, a Y value is also changed, as a multiple of the row number X 1/3 of the bricks width. The possibilities of Brickberg Variations are endless! You could get the bricks to follow a path top make a curved wall, or change their colours, move the camera along a path, change the pace of falling as the wall develops, change the lighting a.. You get the idea! Editconcept