Facade automations generate a pattern across a whole building in seconds.
◦ What does the automation know, and what does it not know?
◦ Where did the generated pattern need overriding, and why?
◦ If the automation produces something that analyses well but looks wrong, which wins?
The automation knows the dimensions of the facade that it needs to copy and paste, but it does not know where the apartment lines start and stop. This needs overriding because there are sometimes the dimensions of the facade will not be the same as the dimensions as the apartment - if the dimensions do not line up perfectly, the facade will need to be shifted to remain uniform across each apartment unit. If the automation produces something that analyses well that is great, but if the designer is unhappy with how it looks and it is not practical, it will need to be redesigned.
What drives a project team's decision about floor to floor height?
◦ From a developer's perspective?
◦ From a designer's perspective?
◦ From an engineer's perspective?
◦ From a builder's perspective?
From the developer’s perspective, the floor to floor height should meet the expectations of the customers and it should be comparable to what is on the market. They also need to worry about zoning to make sure the building is profitable and realistic while also considering what is legally allowed. The designer will focus more on the aesthetics of the building to make sure it looks the way they want it to. For example, if the floor to floor height is too large or small, the building will not look proportional. They will also consider how the building will feel to the user and how high they would want they ceilings to be based on the purpose of the building. The engineer would want to make sure the MEP and structural systems can still fit in the building. With the same example of the ceilings being too low, the structural beams may not be able to fit which would cause many issues. The builder would just want to make sure the heights are feasible and can actually be constructed. Also, the higher the building, the more equipment (like a crane) is needed to be brought on site to complete the structure.
Last week we chose a massing option based on site evidence. This week you had to fit a program inside it.
◦ Where did the program and the massing disagree, and which one gave way?
◦ What would have had to be true for you to change the massing instead of the program?
◦ Which of this week's program decisions will the structural engineer and the mechanical engineer assume you got right?
Total carbon can now be estimated before materials are specified.
◦ How much confidence should a team place in that number at this stage?
◦ Which decision made this week has the largest effect on it?
◦ How would you present it to a client without overstating its precision?
At some point a conceptual model has to stop being conceptual.
◦ How do you know when a proposal is resolved enough to move into Revit?
◦ What is the cost of moving too early? Of moving too late?
◦ Which parts of your Forma model do you expect to survive the handoff?
I think the proposal is ready to be put into Revit when the building is producing analysis results that the designer is happy with and there do not appear to be any big issues with the design. If the design is moved too early and big mistakes are found, the building will have to be redesigned, causing the cost to increase. If it is moved too late, the cost will also increase because there would have been wasted time where the designer could have been progressing with the building in Revit, but instead was still working in Forma. I think a lot of the design should transfer over like the walls and the general concept, but I do suspect that some things will need to be adjusted once the design is put into Revit; Revit will show more errors than it seems like forma will.