LEARNING FROM GAZOTTI

This is my first attempt at a slightly different format for my posts.  The aim is to group the "stuff about buildings" and the "stuff about Revit" into two parts.  Readers who don't use the software can skip the second part.  Software addicts who don't see the value in my musings of "the way we build" can focus on the "tips and tricks".  Hopefully most of you will gain a clearer picture of the synergy between these two aspects of my work.  The starting point today is one of Palladio's lesser known Villas.

VILLA GAZOTTI

According to the pictures on the web, this is still a semi-derelict villa.  Most of the stucco has fallen off, and there are flowers growing out of the joints in the brick steps leading up to the front porch.  It seems that the villa hasn't had the happiest of histories.  Palladio was modifying an existing structure for Gazotti who had to sell it on to a Mr Grimani before it was finished in order to solve his cash flow problems.  Perhaps he was trying a little too hard to compete with his neighbour whose grand estate dominates the village.

Palladio had two main basic ideas for the central element of his façade: the triple arched porch, and the classical temple portico.  This one has the arch motif, but he throws in a pediment for good luck, and an array of 8 pilasters that divide the whole frontage into 7 equal bays.  I think it's the only one of his country villas to set up a consistent rhythm right across the full width.

Before I started this exercise, I hadn't really given much thought to the importance of "outdoor rooms" in Palladio's villa plans.  This one is a classic front porch, overlooking the street and large enough to lay out a large table on a Sunday afternoon for guests coming from a service at the church next door.  There are 3 imposing doorways, leading to the 3 main rooms of the house.  It seems to me that these four spaces, (one outdoor and 3 indoors) define the house.  The rest is a bunch of much smaller storage spaces and hay lofts stacked up at the back, cramming in 3 floors to the one lofty storey of the master's domain.

The principal room is cruciform, with an impressive brick groin vault.  There is a fascinating photo online of the roof void over these vaults showing the ribbing of the vaults and the massive timber truss and rafters that support the clay tiled roof. 

One thing that doesn't come out very clearly from my sheet at present is the contrast between front and rear elevations.  From the back it looks pretty much like a storage barn and I am starting to wonder if Palladio's main contribution here was to remodel the façade, basically decorating the shed.  The ends of the front wall actually stick out at the sides rather than wrapping around to form a proper side elevation.

 Just to recap, what I have built here is a simplified massing model that aims to put Palladio's Villas in context.  There is a large square of topography, with subregions for rivers and fields; a few floors and walls, some "lollipop trees, and families to represent buildings. 

METHODS USED

Like anything we do using a BIM approach, deciding how much detail to show is critical to success.  It's not just a question of imitating reality.  We have to consider our goals and develop the model accordingly.  Hence the simplified trees.  In a similar way, we are always faced with the question "how parametric?"  Most of this is directly modelled, much of it judged "by eye".  I've bitten off a rather large task here, and can't afford to get too bogged down with accuracy.  In any case we don't really know what the Veneto looked like more than 400 years ago at this level of detail.  But I am assuming that there were rows of cypress trees, as there are now, and for these I can take advantage of Revit's dynamic array feature, which really comes into its own at masterplanning level.  By choosing the "last" option I can nudge around the tree at either end to fine tune both length and alignment of a row.  If the density of spacing doesn't look right, just type in a new number.  This is parametrics built in to a system tool.

The contextual buildings are loadable families. Inside you have a box (rectangular extrusion) and a nested Roof family which is set up so that the ends can flip between gables or hips.  Gables need to be wall colour and hips to be roof colour so you end up with two pairs of parameters: a yes/no and a material for left, then the same again for right. 

The switching between hip and gable is achieved by a retractable void extrusion and a simple "IF" formula.  If the box is ticked, the extension is set to full depth, which cuts a hip slope.  If the box is not ticked the extension is set to zero, and you have a vertical gable.  The pitch angle controls the height of the roof via a simple trig formula using the tangent of the angle.

The end result is a family which can be easily switched between 3 conditions: two hips, two gables, one of each.  Opinions may well differ on the balance of type and instance parameters for a family like this.  In my view there should be a maximum of 4 or 5 types, preferably with simple, intuitive names.  Currently I have them set to combinations of roof pitch and material. That way it's easy to select a bunch of and switch types without disturbing the geometry of the layout.  It's just a way of introducing variety.  Meanwhile, in plan view there are shape handles to make it easy to stretch things around.

So the contextual buildings are simple, variable, highly parametric.  By contrast, Palladio's villas are modelled in much more detail but have no built in variability at all.  I've tried to gauge the minimum level of detail needed to convey the essentials of each design.  The basic room layout is revealed depending on the height of the cut plane, or the clipping of a section box.  The principle openings are cut out by voids, and there are simplified mouldings to break up the elevation and reflect Palladio's basic proportions.

 
It's all done with simple solids and voids, mostly extrusions, a few sweeps, the occasional revolve.  But the starting point is a drafting view where I have assembled my source material and scaled it up to ... now there's a question.  What size to use ?  In a few cases there are dimensions in known units.  Then of course there are estimated measurements from Google earth, and finally we have the numbers written on Palladio's own plans.  I am quite certain these are Venetian feet (348mm)  So I've used a module of 350.  External walls are commonly 700mm thick for example, and most rooms are whole multiples. 

Then I traced over the source images, creating filled regions for the floor plans so I can copy-paste the sketch into an extrusion in the family. 

Elevations are a bunch of detail lines, grouped.  A second copy of this group can be swapped out in a clean drafting view and exported to CAD.  That's the best method I have for bringing the front elevation into my family.   One elevation usually provides enough guidance to create an acceptable massing model.

Maybe you don't see yourself studying the works of Palladio using BIM tools.  But why not apply these same methods to an urban design study as part of a concept design report for one of your current projects?  Adjacent buildings could be modelled from source material to a similar level of detail as Villa Gazotti here.  The more distant cityscape could be assembled from parametric families of various shapes and sizes. 

Take the principles.  Apply them to your situation.
.

DYNAMO FUMBLINGS

New years resolutions.  Let's have 3.  Exercise, music, dynamo.

Over the last year I lost 25kg and it has changed my outlook.  I achieved this mostly by a radical shift in diet, but to complete the transformation I need to settle into an exercise routine.  Wish me luck.

Music has been a big part of my life, but it's been a couple of years now since I had a band in Dubai and work has crowded out the blues.  Shouldn't be that way and that's another rhythm I have to re-establish.

Maybe Dynamo doesn't quite sit at the same level of fundamental life-balance, but it's something that's been on the back burner for more than 2 years now and another candidate for the "change of routine" strategy.

I made a start before leaving for Vegas, and I did a bit more last weekend. Nothing even remotely remarkable, and far from complete, but I want to record my process.

First off is a little exercise shamelessly copied from my good friend Marcello's work. He has shared a number of separate graphs dealing with text case changing.  I started with one of these and then built it out with alternative nodes at various points.  For different cases you have to switch 3 or 4 wired connections around, then press "run". 

I don't know if there is a cleverer way to do this.  It would be nice if you could just pick what you want to rename from a dropdown list and the rest of the rewiring just sorted itself out.  Oh, and you'd need to choose between upper and lower case also.

I've no idea whether this can be done with Dynamo.  Perhaps with some coded custom nodes ?  Doesn't really matter.  I don't even care if this turns out to be useful in real life or not.  I got my hands dirty and learnt some stuff, acquired a tiny bit of fluency.  It's a start.

The next exercise was spectacularly ambitious and I've barely scratched the surface, but once again it's all about the learning.  The starting point is a concept sketch I came up with for RTC Chicago - what if we could do automate these kind of Masterplanning calculations?

Baby step 1.  Create floor slabs from a bunch of property lines.  This turned out to be fairly easy.  There is a node for creating a floor based on 3 inputs.  Two of the inputs are single nodes (floor type & level)  The third input needed a sequence of 4.  Choose the element type (PropertyLine), Select all elements of that type,  gather up all the segments ("curves" in code-speak), join them up into a
PolyCurve.

That works, and if you change the property lines and run it again the floor slabs will update.  Magic.  Sadly if you close dynamo, or switch to another graph and come back to this one later it creates a new set of floors instead of modifying the existing ones. 

Probably there is a way around this.  Maybe you have to store the unique IDs somewhere.  It's way out of my league at present, so I just delete the old floors and start afresh.  I'm intrigued by the difference between repeating the operation in the same session and starting afresh in a new session though.  Food for thought.

Leave that there and switch to another aspect of the process.  Transfer parameters from one category to another so that maybe we can do calculations within a schedule.  I want the floors to inherit the plot numbers of the property lines.  Let's use Mark.  4 nodes will do to collect Mark parameters as a list.

Feed this output into the "value" field of a SetParameter node.  2 nodes to collect all the floors.  One node to choose "Mark" as the field to receive the input.  I was hoping to select only the floors of a named type, but I couldn't figure this out.  I'm sure it's easy when you know how, but so far it's defeated me.  Feel free to jump in and set me straight.  For now I'm happy to fix what I can and move on.

Make some changes to the property lines, press "run" and the floors pick up the new information.  But because I have 2 separate graphs for creating the floors and transferring parameters, when I add a new plot I have to go back, delete the floors, create them afresh using graph 1, then load graph 2 to transfer the parameters.  Baby steps, all good.

So the next piece of the puzzle is to collect several fields of data and shoot them out to excel for further processing.  That's probably the way we are going to get FAR and coverage calculations out of the model.  It would be great to do that directly in a Revit schedule, but I have my doubts.  The minute you put two buildings on one property things are going to get messy.

So I'm going to start very simply by gathering "mark" and "area" from a bunch of plots (property lines)  We've already done the "GetParameter" part of this.  Just double that up and feed the two sets of values into "index0" and "index1" of a "List.Create" node.  We need to "transpose" the result so that it becomes Rows and Columns instead of just a long sequence.

Then feed it into the "data" input of "Excel.WriteToFile"  You also need 3 nodes that I've organised as a "where to put the data" group.  Childishly simple stuff really, but it feels exciting first time around.  And up pops and Excel window with my first Dynamo-populated worksheet.  I added the headings manually, but it's quite easy to do that with Dynamo.  Found that in a handout by Nathan Miller.

To extend my test a bit I added some more plots and entered data in the "Comments" field.  This gives me a basis for colour-coding the floors using a view filter.  So the floors are giving me a representation of plots in 3 dimensional space, plus the ability to colour-code. You'd think that colour schemes would be available for Property Lines like they are for Rooms and Spaces but I don't see that happening any time soon, and in any case I want to see it in 3d so this method carries a lot of promise.

My excel graph now needs to collect 3 sets of parameters.  Only takes a minute or two to make that adjustment and now I have an Excel worksheet that looks a bit more useful.  Nathan's session at AU on Mining Data mentions Pivot Tables & Charts.  I was aware of these but had never really got around to mastering them, so that was fun. 

Final short exploration was to find a way for floors to detect which masses are sitting on top of them.  Later on we will need a way to line up area data from the masses with area data from the floors (plots) they sit on and do some calculations in excel.  Ideally we would set all this up, then just hit refresh every time the design has moved forward and get all these lovely tables with areas and Floor Area Ratios, Coverage percentages, Nos of parking spaces required, etc etc.  But first off is just to achieve some basic detection of masses by floors. 

I found a node called Geometry.DoesIntersect (GDI) this deals with Dynamo geometry so we have to collect that from Revit Elements.  I tested it first with manual selection.  Hit the select buttons and select a mass and a floor.  That returned a "true" result so I took it to the next level.

Select a bunch of floors and a bunch of masses, run them through the GDI and get a list of results.  This seems to work, but it's a long way from doing what I really want, which is to line up masses with the floors they sit on, transfer plot number information, add up values whenever 2 masses sit on one floor, filter out upper levels to get ground floor footprints and set up calculations that give mass footprint/plot area and mass GFA/plot area.  Brain hurty.  Give it a rest.

Starting to feel like I'm getting somewhere.  There's a very long way to go before the Masterplanning thing actually does the job.  Many dots to be joined up and probably a lot to learn about manipulating lists.  But I think that's OK for starters.  If I can set aside one weekend each month for some dynamo explorations like that, who knows where I can get to by the end of 2016? 

So that was mostly about manipulating data.  Maybe I should look at something a bit more geometric next time around.  Let's wait and see.


 

URBAN GENERICS

More experiments with Adaptive Components representing building elements, nested within Mass families and using Mass Floors within the project environment to report GFA for different configurations.

One interesting difference between Conceptual Massing and the conventional Family Editor is the ability to create surfaces with zero thickness.  I have been using a simple Box family (GMA)  Width & Height are set conventionally via labelled dimensions,  Using the "lock profiles" feature to take me into a familiar sketch mode when editing the extrusion.

The height is a parameter linked directly to the offset value of the extrusion.  Unlike "normal" families, the height can be set to zero without triggering an error.  The box simply becomes a surface of zero thickness.  And unlike labelled dimensions, the offset parameter can take a negative value.

In the previous post I used the box to make a podium carrying a variable number of towers or slab blocks.  This time the podium will become a divided surface representing plot parcels.  The towers will become buildings, populating the nodes of the surface via the repeat command.

I used instance parameters to allow rapid adjustment of multiple instances.  As a first exercise I set out 4 urban blocks each 200m square and populated each with the same Gross Floor Area.  Building heights vary from 2 to 12 stories and the density of coverage varies accordingly.

That's fine as a proof of concept, but you may have noticed that the buildings overlap the surface at the edges.  All the nodes are populated, and unlike a linear repeater we don't have an indent parameter to create a blank marging around the edges of the surface.  So we will have to set that up within the family.

A bit of extra geometry 2 or 3 formulae, a bit of grief and I got it working.  With a bit more effort I could probably get it to report the number of plots within the parcel and their areas.  Make these shared parameters and we could schedule them.  Maybe we could even calculate FAR and coverage values.  But first let's try it out.

I created a couple of wall types to represent roads of different widths, and set out a very basic housing layout.  Quite fast and easy to adjust

Next something a bit more urban and varied.  The materials are type based and can represent different uses: retail, commercial etc.  With a bit of tweaking it's quite easy to separate out podium and tower areas for each of the use groups in a simple schedule..

My family is rectangular.  What about irregular parcels?  I created an in-place version with repeater rows hosted on the top surface of the podium.  Nested tower families in a similar way.  You can copy this around and edit the podium sketch, it works quite well.

When I attempted a more detailed analysis I came across limitations/challenges.  For example you can't separate the podium floors from the tower floors within a mass schedule.  It has to be a mass floor schedule.  But in a mass floor schedule you only have limited access to parameters belonging to the mass family.  Also when you create new shared parameters, these are not available for filtering the schedule.  I made some progress in developing work arounds, but it needs more time.

The solution I used for creating a border complicated the area calculations.  In any case, parcels are usually just 2 plots deep for access reasons.  So I abandoned the divided surface approach and made a new family with 2 repeater rows.

I think this is a better solution.

I experimented with curtain panels.  They won't compute mass floors, even if you change the category to generic model.   Four point adaptive famies don't work either.  In fact a little further study led me to the conclusion that anything beyond a simple extrusion is not going to compute when embedding GMA families in masses.  So that limits you quite seriously.

You can do repeaters with extrusions.  You can model complex geometry in the mass category.  Mass floors will compute.  But you can't put complex geometry into repeaters and expect the results to compute.  Never mind.  It would have been fun to do a repeating row of twisty towers, but let's face it, early masterplanning studies are probably going to use simple generic forms.  You are interested in getting the numbers right and developing the overall massing & texture of the city blocks.  Architecture will come later and at that stage you will want each building to be a separate entity, not part of a row of repeaters.

In any case, within the project environment you can make repetitive groups of masses using the conventional array command.

MASTER BLASTER

This is a follow up to the previous post.  You can get a Generic Model Adaptive family to take mass floors by embedding it within a Mass family.  So what ?  Why might you want to use adaptive features while doing a GFA study for a project ?  I woke up in the middle of the night thinking about that one (really need to get a life) and started scribbling down ideas.

Divide and repeat springs to mind straight away.  What if you were to make a podium with a variable number of towers for example.  The image below shows my first test.  2 instances of the same family.  The same nested GMA family serves for both the base and the towers (two types)

The towers are hosted on a repeater which is hosted on the base.  The whole thing takes mass floors nicely.

Lots of instance parameters to play with for different configurations.  You can see how this would be useful in a masterplanning context.

Our weekend is about to start, so apart from completing a mammoth post on Ronchamp and putting my Revit file up for download, I might play around with this idea a little more.  Maybe try some less regular shapes, curved arrays, dancing towers ...

But before I sign off, another little nod in Luke Johnson's direction.  Just after I made the multi-tower family a little light bulb went on.  Didn't he do something a bit similar ?  Actually it wasn't quite the same because he wasn't using mass floors, just making curved rows of townhouses, but it is a variation on a similar theme.  Take a look.

LUKE: using-divide-and-repeat-for-site