top of page
Search
  • Writer's pictureViktor Kuzev

Automatic Views and Sheets for Apartment Plans



Bofakta

That’s what it is called in Swedish and it translates to “Housing Facts”, that said I’m not the right person to trust for translation from Swedish.

So we often need to create these sheets with either unique apartment types or all the apartments in the buildings. Also, some of them show furniture (that needs to be nice and dandy and not the same families used for technical drawings) some of them would need to be unfurnished - to show exactly what comes with the apartment when you buy it (sorry the sofa is not included)


A few people already asked me if I am selling the tool.

It is 100% my brain child and I have developed with while working at 3 different companies.

What you saw in the video is tuned for the needs, workflows, parameters of the current company I work for and it was developed for the company. I cannot sell you that tool as it is. But I can make a similar tool for you.


Below is a more detailed description of the tool:


The first time I had to tackle this problem was back in 2016 when I worked for a company called Nyréns Arkitektkontor.

I already knew a little bit of Python and a whole lot of Dynamo so I started making a Dynamo graph that was getting bigger and bigger.






One of the problems back then was that the Revit API for custom crops of the plans was not yet exposed so instead of cropping the view with the shape of the apartment I had to create white filled regions between a rectangular c


rop and the apartment boundaries.


The detection of the thicknesses of the walls was terrible back then - I was pulling the geometry of the walls from Revit to Dynamo and used that geometry to perform boolean unions and differences to draw around the exterior door because for some reason the apartments in Sweden have their doors opening to the outside.


And this ever-growing in complexity Dynamo graph sort of worked.

Two years ago I updated it, I made it far more reliant on Python nodes, more Revit API, less Dynamo geometry, but still it needed to be changed for each different project that we had and I didn’t like that at all.


At that point in time I had already made several pyRevit tools and thought that it would be great to add the Apartment Sheets tool to our custom Revit tab.


There were two main challenges with that -

the technical, of course, was to ditch the ProtoGeometry library in Dynamo completely and to perform all geometric operations only with Revit’s API which is far from perfect for geometry when it comes to joining, cutting and slicing solids which are needed to get that nice boundary.

To throw more light on this problem:

  1. We want to have these crops done around the apartment in such a way that the crop region includes the walls around the apartment the entrance door (which opens to the outside) and the balcony.

  2. We want to do that without drawing anything additionally - made for the sole purpose of having these plans.

So we already have the rooms and the area inside. Whilst one of the old Dynamo scripts relied on the rooms, this time I went for the area boundary, However, the thing is that boundary mostly goes on the interior side of the walls and also goes in doors and windows (when these are from the ground and are wider than 1,5m)

All these geometric operations that I’m talking about are for the purpose of getting the area boundary and adding the walls, the balcony and the entrance door around it and simplifying it so it could become a crop region.


The other challenge was the user experience

- how to create a tool that is simple to use and works in different projects with different setups. Now when I say “different setups” it’s still projects following the company standards of working. But the idea was to not amend these standards at all for the sake of the tool.


After a lot of thought on the subject, I came up with what you saw in the video - starting with selecting from a list of all apartment areas in the project.

This allows for great versatility of use - you can select all or a few that you want to create and you can choose to use the unique apartment types only.


So what else is going on there?

Step number 0 is to assign a uniqueness parameter.

This is done with the “Assign Unique” button.



When it is pressed it checks if the areas in the project already have the uniqueness parameter and if not - it adds it automatically, so the user doesn’t have to think of adding shared parameters.


Then it runs a check for all the selected areas and the groups that they’re in.

It checks whether an area is in a mirrored instance of the group, whether the area is in an instance of the group that is next to a balcony and assigns parameter values based on that


Why is all of this necessary?


Because if we only rely on group instances mirrored apartments as well as apartments with balconies and without balconies would be considered the same, and we want to have them as different ones, while for the most part of the project we want to keep these in the same group (although in late stages we might separate them into different groups, but by that time we’d already needed to make some apartment sheets)



Then when we are using “Make Unique Only” the script looks at all those selected areas and their uniqueness parameter and groups the ones with the same values together.

It makes a plan view for the first one (being at the lowest level in the building with the lowest number), assigns a name and a template for it and continues to crop around it and to make a sheet for it. It takes the Area number for the sheet number, as well as the area to push it to a sheet parameter.


It looks for a room called FRD (the storage) inside the group and if it doesn’t find it looks for a room with that name and room number equal to the area number in the project.

That’s how we get the storage information.



The tool also takes the area numbers of all other areas of the same uniqueness value and uses them to fill the “Apartment Numbers” parameter on the sheet and to fill in the values for the Key Plan.



The Key Plan (and section).



When I first made the script my idea of the key plan was very true to the model and completely wrong at the same time.

What it was doing was the following:

It did create actual sections and floor plans as drafting views in 1:1500 scale and it drew filled regions where the apartment was. Then it was placing those views on the sheets.

Maybe it sounds nice, and it did work, but this workflow has the following problems:

  1. Difficult to change once the script is run. Say you want to adjust something manually - then you are dealing with filled regions on actual views.

  2. The geometry of the plans and sections was too “true to the model” - and often we want a key plan to be more stylized and schematic.

  3. A bunch of drafting views appear in the project.

  4. If you want to change the position of the key plan on the sheet - you have to move views.

So that’s why the key plan is done with filled regions on the titleblock controlled by visibility parameters. And the script is assigning those automatically because it can read the names of the parameters that follow a special naming convention.


These key plans and sections were a pain in the neck to draw and assign parameters manually though, so I made two neat tools to assign the visibility parameters automatically following the naming convention that the script reads and that way - it is about 10x faster to do and there is no room for error in the naming or grouping of these parameters.




I do love this. Really.


The next step is to get the crop right and this is a series of complex geometric operations with getting the walls close to the area boundaries and their thicknesses, adding a crop around the door etc.

At that step the tool also attempts to hide elements close to the entrance door that come from other apartment groups - that’s why we don’t see the usual overlapping of entrance doors that is typical for Swedish apartment buildings.



Then since we have different buildings with different orientations the tool has to rotate each plan so it is aligned with the sheet.

To do so it detects in which scope box the current apartment is found and rotates the view so it matches the orientation it would have if that scope box is applied.


Finally, the tool creates sheets with the specified titleblock and places the views on these sheets and it assigns the corresponding sheet and TitleBlock parameters.


The sheet parameters necessary for it to work are added automatically to the project.


These parameters are the Sheet Name and Number, the apartment area and the number of rooms, the storage area and position (inside or outside the apartment), the apartment numbers of the other apartments of the same type and the browser organization parameters.

The titleblock parameters are the ones that control the schematic key plan and section to show the positions of the apartments in the project.



This post is extremely long at that point, but there is more to say about all the additional tools that work together with this one. This is probably going to happen in a different post sometime in the future.


That’s all for now,

If you have an idea for a custom tool for your company send me a message.

Stay tuned and till the next time!

Viktor

686 views0 comments

Recent Posts

See All
Get updates: 
bottom of page