<< This is a guest post written by Filipe J.S. Brandão, an architect (Faculty of Architecture of University of Porto), Post-graduate in digital architecture, and PhD. candidate at Iscte-IUL. He won a research grant from Amorim Isolamentos, a merit grant from ISCTE-IUL ISTA, and a PhD. research grant 2020.08659.BD from FCT for the development of his Ph.D. research. He was a co-founder of PARQUR architecture collective in 2012.>>

Mass customization (MC) has been an ongoing topic in the architectural design community for the past 20 years. It is an alternate mode of production for the industry whose main enablers are computational design, digital fabrication and the web. By reconciling apparently contradictory goals, personalization and mass production, the mass-customized construction paradigm inflated new life into the century old idea of industrialized architecture. Underpinning these efforts is the notion that building owners want buildings customized to their needs. In fact, MC allows distribution of control between the actors in the construction process, shifting part of the production and design control to the building owner as late in the process as possible.

One key part to deliver MC is developing design-to-production systems whose inputs are end-users needs and preferences. This requires separating the design of the system from the design of the instance, which as consequence also differentiates the roles of system and instance designers. The knowledge of these processes has been significantly explored and widely disseminated in the design community, to which tools like Grasshopper have heavily contributed. 

The other key part is to provide simple and intuitive interfaces which end-users can easily navigate to get what they are looking for. Several online mass-customization platforms for designers have recently emerged seeking to address these issues, such as ShapeDiver or Swarm. Contrary to traditional deployments of parametric, algorithmic or generative models on the web, where the web interface is developed specifically for an automated design model, these platforms provide a base implementation of an interface that is automatically customized for specific model’s inputs. The model and the interface together are a configurator. A configurator is understood as a customization application that consists of an automated design model, that takes a set of expected inputs and returns a given output, and the interface that allows users to manipulate the model.

A research I’ve been conducting focuses on the application of mass-customization workflows to Building Renovation, where the context is a fundamental input. Context can be the user preferences but also the shape of the space to be intervened. While there are many ways to collect user preferences, there are next to none for allowing non-expert users to provide the shape of their spaces - the as-is survey - particularly on the web. Thus, most configurators that need to deal with boundaries of existing spaces (e.g. Kitchen planners, wall pattern generators, etc) either limit the boundary shape to a set of predefined shapes or require users to provide a file with a polygonal shape as boundary. 

RoomSurveyor

RoomSurveyor provides a way to overcome those limitations. It is an interactive triangulation plugin developed and maintained by me (Filipe Brandão). It implements iterative triangulation algorithms to assist users to survey rooms, either orthogonal or non-orthogonal, and automating the drawing of the as-is survey.

RoomSurvey components can be used to deploy an interactive workflow of space survey for non-expert users that mimics the empiric surveying workflows used by architects or other building professionals: sketch - measure - draw. This enables the possibility of developing low-key design interfaces for mass-customizable systems where contextual information is required. 

The RoomSurvey component comes in two flavors: RoomSurvey and RoomSurveyStrict. There are two differences between these components: the logic used to request diagonals and the assumption that if a polygonal chain is closed within tolerance the angles are assumed to be correct (which is not always true).

The RoomSurvey requests longer diagonals first which is more effective on smaller polygons with few non-orthogonal corners and uses the closed polygon chain test. You can read more about RoomSurvey here.

RoomSurveyStrict makes no assumptions to speed up the process and requests shorter diagonals first. This means that RoomSurveyStrict will always request at least n-3 diagonals, where n is the number of polygon sides. So, for a polygon with 6 sides, 3 diagonals will be requested and for one with 20 sides, 17 diagonals will be required. Choose wisely!

On a conceptual level the survey workflow steps are:

1. Draw or provide a polygon that is similar to the polygon you need to survey

2. Provide the measurements of each of the polygon sides

3. Provide the requested diagonals

Inputs and Outputs

Both components take the same inputs: a closed polygon (polyline), an ordered list of side lengths and the requested diagonals.  You can input a polygon with any number of sides, convex or concave, with whatever rotation or scaling. The only rule is that the polygon must be morphologically similar to the shape you want to survey. Two polygons are morphologically similar when they have the same number of sides and the same sequence of corner types.

The dimensions of each side must be provided as a counter clockwise ordered list, starting from the first corner of the polygon. The diagonals are requested by the algorithm in the [out] output. Higher numerical precision of the side and diagonal measurements results in higher accuracy of the reconstruction. For practical purposes, if you are working in meters providing measurements with millimetre precision is a good trade-off.

The component outputs are a list with the user instructions [out], the current reconstruction of the polygon (more on this latter) [R], the requested diagonals as lines [D], and a boolean that informs if the triangulation process has finished [T].

• [out] – Returns instructions to the user for diagonal measurements (e.g.: Measure the distance from Point 3 to Point 5). When the polygon is closed it reports the closing error (e.g.: The Polygon is closed with a 5.18368349574805E-12 mm error)

• [R] – While the polygon is not triangulated it returns the polygonal chain scaled by the lengths of the respective sides with the transformed angles as a result of the provided diagonal measurements. When the process finishes it returns the triangulated polygon, i.e., the surveyed plan or section.

• [D] – The requested diagonals as lines between corners of the provided morphology.

• [T] – A boolean informing if the triangulation process has finished.

Example Setup

The following image presents the simplest possible setup, with the exception of the ShiftStartPoint component that is only needed to change the starting point of the morphology.

RoomSurveyor + ShapeDiver: Context-aware configurator

The core focus of this plugin is to provide a low-key survey workflow that can be run on the web. Supporting RoomSurveyor on ShapeDiver is a logical step to provide the plugin functionality to a wider group of users that do not want to venture on setting up their own servers running RhinoCompute. With ShapeDiver, designers may build parametric models that are boundary dependent (e.g. partition walls, suspended ceilings, floors, windows, kitchen furniture, etc…) using no code.

There are several ways to set up a configurator using ShapeDiver and RoomSurveyor. This post describes the simplest method using just Grasshopper, ShapeDiver, and RoomSurveyor, including some simple definitions for collecting user input and presenting requests and helpful cues to the user on the UI. 

A more convenient user workflow can be attained using JavaScript and JSON as described here. Using this method the user can directly draw the polygon on the browser canvas and save the polygon to upload to ShapeDiver. Naturally, this download step may be removed using the ShapeDiver API.  

The image bellow exemplifies this process. You may also use the app to survey a wall and upload the JSON to one of the above configurators.

If you are interested in RoomSurveyor, you can download the plugin here.

You can start using the plugin to create online cloud applications today by creating a free ShapeDiver account.

<< Do you have a Grasshopper plugin you would like us to support on ShapeDiver? Let us know via our Forum and our development team will let you know if it's possible! While you're at it, check out our other supported third party plugins.>>