Summary

In this article, we describe how a well-architected solution using Rhino.Compute and Hops enables us to improve our productivity and the traceability of our blocs.

At BlocToBuild, we develop what we call blocs, engineering components that encapsulate a wealth of knowledge (regulations, supplier content, etc.). To achieve this goal, we use a process inspired by a blend of systems engineering and Object-Oriented Programming (OOP). In developing these blocs, we ensure that each component is not only robust and reliable but also adaptable to various engineering requirements and standards. This approach allows us to create modular, reusable components that can be easily integrated into different projects, thereby streamlining the engineering process and enhancing overall efficiency.

One of our challenges is making these blocs accessible to customers. For example, we designed a building “core bloc”, a piece of building containing stairs, lifts, surrounding walls, air extraction but also openings and emergency lighting.

However, the possibilities are vast, and we split this bloc into multiple models to enhance the user experience (so users don’t have to fill out hundreds of parameters). In doing so, we developed multiple models with a lot of common logic.

Using Hops, we managed to create what we call an object-oriented bloc: we have a main macro-model that calls different object submodels and joins them together. We then have user models that consist of small Grasshopper models, that we can consider as configuration files. These models are the only ones exposed to the final user, giving him only the appropriate inputs, while the main model is only developed once.

Benefits of using Rhino.Compute and Hops:

1. Reusability and modularity: by using submodels, we can reuse common components across different projects, reducing development time and errors. A change in the reglementations or in the products characteristics can be easily reflected on all of our models, saving us the tedious and source or errors process of changing it in all of the models.
2. Improved traceability: the modular structure allows for better traceability of changes. Each submodel can be tested and validated independently, making debugging and maintenance easier.
3. Optimized user experience: User models simplify interaction by hiding underlying complexity. Users no longer have to manage a large number of parameters, making the blocs more accessible and intuitive.

For example, our building core model integrates more than thirty inputs, making it impossible for users to configure the bloc easily. By creating 8 user models, each representing a specific use of the core (stairs placement, presence of a lift, …), we manage to simplify the complexity of generating a configuration, while keeping the benefits of a unified common model.

4. Flexibility and Scalability: the object-oriented architecture allows us to add or modify features, add or remove products from our suppliers as they evolve, without affecting the entire system. This makes our solution more flexible and scalable to meet new requirements.
5. Enhanced Collaboration: modularity facilitates collaboration among team members. Each person can work on specific submodels without interfering with others’ work.

Architecture example

Diagram below shows how we can, from a main model that encapsulates the wole knowledge, reduce choices depending on what the user want to see, and still be able to modify individual submodels as the elements they rely on evolve.

Finally?

In conclusion, using Rhino.Compute and Hops allows us to structure our blocs more efficiently, improving our productivity and the quality of our products. This approach helps us better meet our customers’ needs while maintaining a clean and maintainable knowledge base.

On a more meta perspective, this approach makes a lot of sense for us. We do our best to push modularization and productization in the building industry. Coding our blocs this way goes in the same direction.