top of page
  • Writer's pictureMaksim Markevich

Fun research about converting traditional floor plans into modular ones?

Updated: Sep 23, 2022

Let's speak a bit about one of the most conservative markets globally - the construction market, namely, how the adoption of pre-manufacturing is going on there. To make our topic even more specific - how the industry manages the implementation of volumetric modules into the pre-construction phase, what problems do we have there, and possible solutions we might develop.


Current process and roles

I am going to start with process cognition and roles description.

The construction process is a pretty complicated one. Under the RIBA Plan of work 2020, it has 8 different stages, which are designed to work together to inform the briefing, design, construction, handover and use of a building:

Except for RIBA stages, there are planning/contract stage, different procurement routes, etc. Like Lebowski said, "Is A Very Complicated Case, Maude. You Know, A Lotta Ins, Lotta Outs, Lotta What-Have-Yous."

But the complexity doesn't mean we cannot idealise the system and speak about it. 🧤

Regarding main participants in the construction project and their relations, let's consider a pretty typical case:

  • client/developer

  • architect

  • contractor

  • manufacturer

No way to explain the relations of these above in less than 100 pages, but I will try to make a simple scheme:

  1. Clint/Developer sends brief requirements to the architect

  2. Architect produces floor plans without any thoughts about supply chain (without thinking about pre-manufactured volumetric modules)

  3. The contractor gets drawings, sends RFP (Request For Proposal) to manufacturers and starts working with different engineers, subcontractors, etc.

  4. The manufacturer tries to modularise traditional floor plans

  5. If #4 succeed, then Manufacturers prepare quotations and contractor order products (volumetric modules)

  6. Contractor builds building


The main problem is that not every floor plan can be modularized. There are a lot of reasons, below are just a few of them:

  • impossible to get the entire building footprint within modules

  • extremely inefficient use of modules

  • transportation risks

  • installation problems

The principal restrictions manufacturers should respect during modularisation:

  • Development Projections The developer already built financial projections around this particular floor plan, so the number of units, unit mix, etc., cannot be changed during modularisation. Any minor changes will lead to reconsidering GDV (Gross Development Value) and RLV (Residual Land Value), making current projections wrong.

  • Architectural Fundtionality Briefly speaking, the manufacturer cannot change corridors (fire safety requirements), windows (sunlight/daylight calculations), spaces (room areas requirements). They cannot divide wet zones into separate modules, leading to difficulties during the installation. And many more.

  • Planning Approvement If the project already passed the planning stage, it creates even more mess around modularisation. Changing footprint, building program, materials, etc., are not acceptable.

Beyond the restrictions above manufacturer also needs to work with the following criteria:

  • Manufacturing and Assembling Efficiency There is an appropriate term - DFMA. DFMA stands for Design for Manufacture and Assembly. DFMA is the combination of two methodologies; Design for Manufacture, which means the design for ease of manufacture of the parts that will form a product, and Design for Assembly, which means designing the product for ease of assembly. As a manufacturer, you don't want to produce completely different modules each time, and also, you don't want to have a lot of different types of modules.

  • Shipping Efficiency Usually, it is connected with restricted modules by the size caused by transportation capabilities and construction site placement and accessibility.

  • Structural Efficiency This part is very connected to the building concept (maximum height, loads, etc.). Again, the modules from the bottom and the modules from the top of the building can be the same architecturally, but they will not be the same structurally.

These criteria are all overlapped, so finding the best solution is a trade-off as usual (multi-criteria optimisation takes place here).


The main question is how we can fix the problems above and find the optimal criteria trade-off?

As it often happens with multi-role process automation, the first obvious way to fix the problem is to change the process.

Let's assume that manufacturers/contractors could be involved in the flow from the very beginning to explain to architects about the supply chain, products, etc. In that way, architects could deliver building concept taking into account the nuances above.

The workflow would look like this one:

Consultants here are optional, but they can bring a lot of value to this process and organise project participants.

Anyway, as we all know, there is no way to change the process. 😉 Only vertically integrated companies can afford such a luxury - to set up operations in quite an efficient manner.

There is another way to fix the problems defined above. And it is all about the automated modularisation software solution. Such a solution could be used by manufacturers to prepare quick quotations based on traditional floor plans. Unlike the previous approach, this one is more like a hotfix, but it still makes sense as long as you cannot change the process itself.

In Kreo, we decided to build a PoC (proof of concept) of an automated modularisation software solution. And here I am going to explain what we did so far.

We agreed on the input [pdf floor plan] and output [volumetric modular building informational model]. The PoC flow was divided into three main silos:

  1. Floor plans pre-processing

  2. Modularisation (post-processing)

  3. Building concept automation

Let me dive a bit deeper and explain a bit more about all points above:

Floor plans pre-processing

Here we use our pdf floor plans recognition technology from the 2D Takeoff tool.

We use convolutional neural networks to segmentation and classify spaces, wall, doors, and windows.

After that, dynamic programming algorithms finetune neural networks results to produce final polygons.

As an output here, we get a digital floor plan with quite a few errors and shortcomings.

We don't care much about errors because our next silo will fix them (or overwrite them 😁).


Here we process results from the previous step. We use dynamic programming or open-source constraint programming solvers that suggest the best modular scheme on top of the traditional floor plan. We tried to be focused on respecting constraints (development projections, architectural functionality, planning approvement), and we didn't work on criteria, so there is no multi-criteria optimization at that moment (manufacturing and assembling efficiency, structural efficiency, shipping efficiency).

The output of this silo is volumetric modules configuration (modular scheme) that comply with restrictions, which means it doesn't change the floor plan.

Building concept automation

When we have amodular scheme, we can actually use the power of our Kreo Modular tool to generate a 3D model of the building with the necessary dashboards.

For the sake of clarity - we will not automate all parts of this PoC until we prove this PoC. By "prove PoC", I mean having enough companies in the market with problems that we solve with PoC and companies ready to pay for such a solution. So, for now, it is just fun research.

Here is the video where all three silos above glued together:

Thanks for reading! ♥️

913 views0 comments


bottom of page