(for now only works in feet, V2 will include metric- apologies for that!)
PlanBee is a plugin intended to help compute and visualize the features of a floor plan at variable resolutions and in doing so to help the designer look at the programmatic organization of the floor plan from a different vantage point. Use the ‘Rendered’ view mode when using PlanBee to make the most of built in analysis/display components. All analysis components support parallel computing.
In addition to computing various metrics across different floor plan locations, PlanBee offers the implementation of a Kohonen Self-Organizing Feature Map algorithm (SOM) to ‘self-organize’ the specified programmatic blocks pertaining to the floor plan. Jargon start: In order to understand this, it helps to think of the floor plan as a field of voxels, each of which contains values for different computed metrics. Once the metrics are computed, each voxel corresponds to a multi-dimensional vector. The SOM basically reconciles the multi-dimensional vectors of the field of voxels with the features one specifies should belong to a programmatic mix : Jargon end.
The use case is the following: space-planners, architects, and interior designers doing fit-out/ early schematic design exercises needing to reconcile a programmatic brief with a floor plan polygon. Users can also user PlanBee to simply compute analysis metrics for a floor plan and visualize them.
*PlanBee does not produce anything close to a finished floor plan!
In order to use PlanBee effectively it helps to think about it in two parts (1) Computation of floor plan metrics/Analysis (2) Self-Organizing Feature Map. (Please look at the sample files).
- Program Area distribution (.csv format – see sample files)
- Program descriptors/ features(.csv format – see sample files). These are normalized values between 0 and 1 describing how strong the features are present in a given program. An example is ‘Kitchen’ might get something close to 1.0 in ‘Daylight access’ whereas ‘Storage’ may get something close to 0.0.
- Working plane
- Floor plan perimeter curve
- Core perimeter curve (or perimeter curve offset to define core curve)
- Voxel/ analysis grid resolution
*If the usable area of the plan (perimeter area – core area) is too small, PlanBee will tell you and ask you to adjust either the size of your programs, or the size of your perimeter curve). ‘What’s too small?’ you might ask. The program names and areas are specified by the user in the form of a .csv file (see sample files), and PlanBee uses that information to determine whether the plan you are specifying can meet that spec.
Now on to computing metrics….
Computation of floor plan metrics
The metrics that can be computed in the first release are:
- (2D) Isovist (internal to floor plan only; including specified obstacles): A) specify internal obstacles
- (2D) Visibility to attractions (landmarks, point of interest, etc): A)specify the boundaries defining attraction geometries
- (3D) Daylight Proxy (dependency free using Rhinocommon sun): A) specify the analysis period and the Latitude/Longitude of the location you are looking to analyze. B) specify obstacle objects (nearby buildings/ awnings).
- (2D) Distance to exits (A* Shortest path implementation): specify as many exits as you like, place a point where they are to be located
These metrics can be calculated and visualized or can serve as the inputs for the second part (Self-Organizing Feature Map). Each metric corresponds to a component that has a built-in display/preview to it if you toggle ‘Autocolor’ to True. (You should only have one set to True at any given time). I plan on expanding the metrics that can be computed of a floor plan based on user feedback.
Self-Organizing Feature Map
Kohonen Self Organizing Feature Maps (SOMs) are widely used as an unsupervised ML technique in order to classify and represent high dimensional data in lower dimensional spaces. Applications range from medical diagnosis, to interpreting seismic activity, to environmental modeling. The idea is that elements within a field are organized according to their (multidimensional) features; ie. similar field objects are grouped together based on their similarity.
In PlanBee the purpose of the SOM is to ‘self-organize’ the programmatic blocks of a brief within a floor plan. The goal is not optimization, but simply a mapping of the features inherent in the floor plans which can be represented in a few ways; one of them being the programmatic distribution. The other two provided by PlanBee are (1) the raw weights of the nodes as well as (2) the distance to the Best Matching Unity (BMU). For a more in depth understanding of the algorithm please look at http://www.ai-junkie.com/ann/som/som1.html.
Currently the algorithm runs for a fixed number of iterations – I plan on exposing that to the user in future releases. While the algorithm is running ‘Display SOM’ should be set to False. Once running is complete you can set to True and visualize the data by specifying the ‘Display Type’ input. The SOM displays all visualizations with built in display/previews.
If enough differentiation in the computed metrics across of the floor plan ‘analysis grid’ then this method produces interesting and maybe even insightful/ workable feature maps. Because this method doesn’t consider user-defined adjacencies or any other optimization metrics (it is at its core NOT an optimization algorithm), no optimization should be expected.
Have some fun with it! I recommend starting with sample files and replacing with your own inputs.
- Additional analysis metrics
- Routine to better ensure SOM is producing correct area distribution while ensuring feature fidelity
PlanBee was developed by Marco Juliani. If you have questions / suggestions please reach me at email@example.com
Kohonen Self-Organizing Feature Map – A vanilla version of this algorithm was taught at UCL Bartlett’s AC program. The PlanBee version builds upon this vanilla version. The version taught in the course referenced this link heavily: http://www.ai-junkie.com/ann/som/som1.html
A* Shortest Path – This algorithm was pieced together from numerous tutorials on the subject found on YouTube. It doesn’t use external libraries and the data structure of the graph is a dictionary.
Both the Isovist and Attraction visibility methods are simple ray casting methods to determine intersections.
The Daylight proxy method is dependency free and uses the Rhinocommon sun to determine solar angles. It is an overly simplified method in that it doesn’t calculate ambient light/ noise or anything more than one bounce. It is intended to serve as a proxy method that is ‘good enough’ for our purposes.