Sunday, December 27, 2015

GRAPHING THE BANK

I ended my last post with an image of John Soane's variations on a "canopy dome" theme responding to Dynamo sliders.  That was an enjoyable exercise, but comes with a couple of caveats.

The graph lacks a mechanism for recording the starting values when you select an object, so it's tedious to go back and do fine tuning.  Either you start again from scratch or you have to manually set the sliders to the existing values before making your selection.  I would be most grateful for suggestions as to how to harvest the existing settings automatically whenever you select a new object.  Failing that, a separate "harvest button" next to the "select button" would do nicely.  (PS - it would appear that "Presets" may be the best workaround for this ... thanks to Zach for the insight)

The second quibble has to do with the family itself.  This was set up in an earlier post on pendentives in the midst of my Project Soane fever and works well as an explanation of how the different variants can be derived from a hemispherical shell (by making side cuts, a top cut and a bottom cut)  The problem is that the springing point moves up with the undercut and the width of the square that the pendentives sit inside has to be deduced.  It is not one of the original inputs.

John Soane & Canopy Domes



So I set about creating a new pendentive family where you input the size of the square, and the "rise" of the dome above its springing points.  This generates the basic form, ranging from a full hemisphere to an almost flat canopy, based on any given size of square. 



To control the arc I decided to use a "trick" learned from my good friend Paul Aubin. Create a detail item comprising an arc plus necessary construction lines, place this in your Generic Model family, align and lock your arc to that, untick the "Visibility" of the detail item so it will not show up in the project.

My detail item is a little different from the one he usually demonstrates.  Mine is not designed to adjust to different angles, and it needs to be driven by "Rise" not radius.  I'm using a formula that I found on the internet to derive "Radius" from "Width" and "Rise".  It works.



The width in question is actually the diagonal of my pendentive family, because that's where the springing points touch down.  And here comes my Revit discovery of the week.  You aren't allowed to place a detail item in a diagonal view.  I suppose there is a logic to this.  We expect to represent an object by 3 orthographic views, as in 3rd angle projection (top,front,side)  But of course the full theory of descriptive geometry (as developed by Gaspard Monge and others during John Soane's lifetime) allows the projection of any three dimensional form onto any inclined plane in space in order to derive true dimensions. 

In the project environment we can draft on any section view, doesn't matter what angle we draw it at in respect to Project North.  In the family environment we are limited to views parallel to the 3 major axes (X. Y & Z)  This is sad for me because I don't want to see my detail item, I just want to use it to control a sketch arc.  As a workaround I have made my entire family on the diagonal.  It will need to be rotated 45 degrees when placed in a project.  Perhaps I should have dispensed with the whole Detail Item thing, but I decided to follow through on my original idea and see how it worked out.



So we have a shallow dome based on the diagonal of a square, and we can vary the rise.  This is then converted to a shell with a thickness and the edges that protrude beyond the square clipped off with a void.  Finally, make the diagonal a calculated value based on the width of the square using a "root 2" multiplier.

We want a circular hole in the middle for the central lantern/drum/dome (usually a lantern in Soane's case)  I chose to do this directly in the sketch of the revolve.  This makes it possible to go right down to zero while giving the hole vertical sides.  My previous approach produced a hole with a flat top and the driving input was the distance down from the crown, rather than the diameter of the hole.  I'm just trying out different approaches.



Now that I have a centre piece driven by the width of the square and the rise of the crown, I can place it within a family that represents one of Soane's banking halls.  I'm keeping this as simple and abstract as possible so that we can focus on the key variables.  So the floor plan is represented by a grid of model lines.  The vertical supports are provided by 16 vertical model lines.  And we have horizontal reference planes to represent springing points etc.



All in all I ended up with 8 key variables, arranged as two groups of 4 and all set as Instance parameters.  This makes them more accessible for adjustment and simplifies the process of creating a series of variants.  No need to create types and give them names.  In the first place, all the additional bays are represented by the same family, essentially a barrel vault cut out of a rectangular block.



This family gave me quite a lot of grief.  I tried several approaches to modelling it, but all of them were susceptible to breaking.  Frustrating because you would have thought that the pendentive was a more complex problem to solve.  In the end I used a cylindrical void to cut a solid cuboid using a formula to calculate the distance of the centre point from the base line.  A little thought will suggest why this is more stable than constraining the end points of an arc to reference planes.



So the vaults on the four sides of the central square need to match the rise of the dome at that point where it is cut off.  I spent a couple of wasted hours trying to find a formula to drive the dome from this parameter rather than from the rise at the centre of the dome.  No joy.  But I was able to derive that distance from the dome rise, via a couple of intermediate values.  I could have boiled it all down to one monster formula I guess, but it is more comprehensible presented as a series of steps.  Perhaps you've had the experience of coming back to a complex family some months later and struggling to remember how it works.  Happens to me quite a bit.



So I duplicated this calculation within the master family and used the result to drive the rise of the vaults around the dome.  Now whenever you adjust the height of the dome, the surrounding vaults respond accordingly.  Having got a family that flexes well using my 8 key variables, the next step was to hook it all up to Dynamo sliders.  I already had a template for doing that from my last post, just needed to bump up the number of items in the lists.  One list for selecting parameters by name, one list for feeding in the values. 



Like I said at the beginning, it's important to set the sliders to the current values before you start.  It's still possible to break the family (eg by specifying too high a rise for the dome).  Dynamo sliders are good because you can set limits (min & max)  The rise of the corner arches is expressed as a factor such that 0 is a flat line and 1 is a semi-circle.  In practice you might want to start at 0.2 and finish at 0.95.  Zero would give an infinite radius (not clever).  1 seems to be fine with my current stable family, previous versions were less forgiving.  Actually it seems that I can go as low as 0.001 giving a rise of 3mm over a 6m span, which is visually flat.



I went on to duplicate the Barrel Vault and create a Groin Vault family. There is a second cylindrical void with the same rise as the first, but potentially a different width. So they cross at right angles with their crowns level.  That's pretty much what a groin vault is.  I made something similar before for the cellars. 

Down in the Dungeons

This one should be more stable, using the full-circle principle.  The critical part is the formula that calculates the distance down from the springing point to the centre of each circle, based on a given width and rise.



There was a bit more pain getting all my families to flex without breaking, but ultimately I had a collection of banking halls generated by stretching the values of 8 variables with intuitive sliders.  Sadly there is little point in going back to use the sliders to fine-tune one of the iterations.  I desperately need that "harvest" button to quickly reset the sliders to match any given instance.  (or to give each instance a "Mark" and save a preset with the same name.  A slightly more disciplined approach, with a big payoff)



Having created a family that can represent either the Stock Office or the Shutting Room (by adjusting parameters) has made me think a bit more deeply about the differences.  I did a study of comparative sections before which was very revealing, but the greater level of abstraction and the active manipulation of parameters bring further insights.



The Stock Office is a wonderful space and with the benefit of hindsight a better solution, but the fact that the corner arches spring from half-way up a column must have bothered Soane. 



His strategy for the Shutting Room is to make the corner arches very shallow and the dome somewhat deeper.  This allows him to push the arches up into the dome, achieving a common springing point. The down side is that the corners are weak.  Both arches and windows have to be squeezed into the same space and the results are far from satisfactory.



So for the Consols Transfer Office (the culmination of this first series of 3 banking halls) he returns to his original strategy of separate springing points, but retaining the flatter arches and the deeper dome.  In this case the end bays are much deeper, rivalling the central space in size.  The final effect is of 3 arches in a row, well balanced in size and shape, sitting above a cornice line supported on paired columns.  (My simplified model doesn't express the thickness of the supporting columns)



It's an interesting sequence, coming to a satisfying resolution perhaps, but it seems that Soane was still concerned about the arches springing from half-way up the columns.



A couple of decades later, when he returns to the Banking Hall theme for the last 2 he takes a more radical approach, lifting the end bays above the dome and using long barrel vaults spanning across the space.  Then he dispenses with capitals so that the columns flow straight into the arches which are based on a common springing point.



On the one hand, you could say that he was ringing the changes, giving each space its own character.  But on reflection, there is also a sense of direction, a searching after better solutions based on a critical analysis of previous attempts.  To put it another way, the variations are not random, there is a clear progression in the way that he develops this theme over time.

I'm not saying the last one is the best, just that it is the product of systematically pursuing a set of goals.  We might prefer a musician's early seminal works, while appreciating the fact that they continue to explore new possibilities in an intelligent way (not just thrashing around aimlessly).  As an artist, you can't just keep repeating your original concept year after year and expect to remain fresh.




 

Wednesday, December 23, 2015

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.


 

Monday, December 21, 2015

VEGAS AND MORE

You can skip this post, it's just a bunch of photos

I'm in Vegas now, at my first ever AU.  This is the furthest West I have ever been in the US and shortly I will be going the furthest South, visiting my daughter Wendy in Tampa, Florida.
My last 2 weeks in Dubai were pretty hectic: rounding off my work, and fitting in a couple of talks at local BIM events.  The invitation to give an "Architect's Perspective" at Mott Macdonald's annual global BIM seminar came at fairly short notice.  The focus of the event was mostly on the infrastructure side, so it was pretty easy for me to offer something "completely different" as Monty Python used to say.


Rather than do a long post on that, I'm going to make a page that links to my various talks over the years.  Be patient, it will happen.  I tried to focus on three main points:  Inclusivity, Interactive BIM for suppliers and manufacturers, and making BIM fun (aka taking a broader view than the usual narrow business focus)  These are 3 of my favourite hobby horses of course.  We BIM addicts are very skilled at talking down to the uninitiated, putting walls between ourselves and "designers" etc etc.  I had a good time.


Then there was the BIM Summit where I got to talk about Project Soane.  This was an excellent opportunity to gather my thoughts a bit after all that hectic research and modelling.  It was organised by the ITP guys, a publishing group that had previously run the BIM breakfast series in Dubai.  A number of people there who hadn't seen me since I lost a lot of weight.  Nice to catch up and just to cap it off, it actually rained while we were inside.  That's a pretty rare event in Dubai, but we do get one or two showers at this time of year.  Always exciting.



And Vegas.  What can I say?  The hugeness of the event.  The loudness of the location.  The excitement of the moment.  The pleasure of meeting up with some of the people who made Project Soane possible.  Friends old and new.  Young people displaying scary amounts of energy and enthusiasm.  Definitely something to do at least once.  Of the 2 mega-sessions I preferred the closing remarks, less US-centric, more open to the dual-edged nature of those technological swords that Autodesk purveys.  I have always been an optimist and an embracer of digital tools, but I fear for the uncritical worship of robots and 3d printed buildings that is currently in fashion.  Yes, of course these are important technologies for the future, but like GMO foods and nuclear reactors they also come with risks.  I live in a region where hundreds of thousands of lowly paid workers from less-fortunate birthplaces toil to support large extended families back home.  For the globe to remain politically and climatically, viable (I almost said stable, but that would be hoping for too much) we have to balance the runaway technologies of THE WEST, against the human needs of EAST & SOUTH
.


Here is a graph from the opening session, almost the only note of honest doubt on display.  Even then, it only describes inequality WITHIN THE USA.  If there is a growing gap between the corporations and the workers in the richest state ever... well you catch my drift.  As sea levels rise and the itinerant labourers of Bangladesh lose their jobs to robots, the current "trickle" of migrants from Syria could well be dwarfed by future waves of human despair.  We need a balanced view.  I embrace new technologies, but I use them to reflect on our history as a typically flawed species, perfectly capable of fouling our own nest (like any other).  Which brings me back to Project Soane and the bank that stored coal and gold in it's cellars (those firm foundations, inverted arches, financing war and providing a platform for the industrial revolution that would convert coal into gold by way of the steam engine and child-labour on factory floors.  Birth pangs of our digital paradise ?



I haven't yet seen a public anouncement in the Press, but it was stated at a session in Vegas that I won the Sir John Soane Award for my contributions to stage 1 of the cloud-sourced reconstruction.  I'm taking a breather from the bank just now, but I do intend to take that work further, and hopefully to involve more people from around the world in the process.  I attended a planning session where a group of energetic young people showed enormous enthusiasm for pushing the project forward.  Fantastic work, people and it was an honour to meet you all.  BIM has a huge potential in education and research that remains largely untapped.  I see it as an amazing tool for exploring the human condition.  Isn't that more important than chasing ROI ?  I certainly think so. 



First time in Vegas was followed by first time in Florida.  My picture raises a bunch of questions.  How come a historic building in Tampa is full of Middle Eastern references ?  Do you see the irony in driving out the Spanish, (who had themselves driven out the muslims from Iberia) then glorifying/trivialising the vast cultural legacy we inherited from Islam with a resort hotel.  And what about Ybor City ?  How come I have an African daughter ?  Why is she taking selfies with a wooden "indian" (representing the original out-of-africa migrants who colonised the new world in ancient times when "the whites" had barely reached Iberia.)  Which is the most scary: the fact that we butchered "indigenous" peoples with such gleeful abandon or the fact that the microbes we carried with us did most of the damage?  What should worry us most: the social unrest that our addiction to the white heat of technology may trigger, or the diseases that ever larger cities and genetic meddling risk unleashing ?  Last one: can we learn from history ?  History itself suggests not, but I live in hope :)



Wendy and I spent an interesting afternoon at the Dali museum in St Petersburg. It features a central staircase that evokes his extravagant moustache.  The early moderns exploded on art and architecture a hundred years and more ago, changed our world, helped to unleash the breathless charge into oblivion we now face: a constant barrage of images and ephemeral stylistic trends.  Why do their works stand out so starkly, bold and original ? Is it just that they operated in a much smaller space, before photographic images proliferated and gave birth in turn to the infinite world of image searches and smart phones in every pocket ?  Can we ever recapture the shocking clarity of Le Corbusier or Wright or Mies ?  Would we want to ?  And what of John Soane ?  Did he kick this whole process off ?  He and his generation, who let the fossil-fuel genie out of the bottle.  I've been watching Elon Musk advocating carbon tax as the simplest way to save mankind.  It's become such a cliche.  Men in casual black "business casual" pacing around large stages offering "Ted Talk" insights.  Flashback to Carl Bass and the future of making stuff, IoT, robocop, virtual surreality.  But Elon is a little different perhaps, it's not all "bigger,better,faster" ... "bring it on" ... "isn't it wonderful".  There is a recognition of "the progress trap", the need to step off the carbon treadmill, the dangers of business-as-usual/growth is good/change addiction.  Is it because of his African roots?  Could a company like Autodesk develop a more nuanced, less US-centric vision of the future ?



Finally, I don't have pictures of all the wonderful people I interacted with in Vegas.  Those conversations are the most important parts of a conference experience in my view.  So the last image is simply a placeholder for the many others who shared thoughts or gave me a hug.  Zach was one of the first to greet me, and Philip one of the last.  Thankyou everyone, and a special mention to Steve Stafford, who took the time to have dinner with me in Dubai on his way home from a week in Abu Dhabi.  Steve's blog is very different from mine (as it should be) : thoughtful, balanced and penetrating observations on the daily business of using Revit; not afraid to point out flaws, but never carping or preaching.  Thankyou Steve, I rarely miss a post. 

Tuesday, December 8, 2015

SWEEPING UP

I don't often do "tips & tricks" but this one came up at the office recently and I thought it was worth sharing.  One of my colleagues was having difficulty controlling the lineweight of a wall sweep.

His first thought was to use Object Styles (good idea, control all the section views from one place)  There is a subcategory there that looks like it will do the job.  You might be wondering why it says "cornice" but maybe it's just one of Revit's many naming inconsistencies.  Sadly that doesn't seem to have any effect on our sweep.  "Strange" you say to yourself.



Next you might try an element over-ride just to rule out some wierd possibilities like graphic cards or whatever.  That works fine, you can change colour and lineweight just like any other element.  Of course you don't want to have to select every sweep in every view and pick a new lineweight, so what about using a filter ?



As far as I can see there is no way to select a type of wall sweep using a filter.  Wall sweeps don't show up in the categories list for filters, and if you try selecting walls that have "Sweep" in their type name, that doesn't do it either.



What starts to give the secret away is that wall sweeps do respond to the basic object-style settings for walls.  Which is fine most of the time, but let's say you want the sweep to have a thinner line weight than the wall it sits on, what then ?  And what is the purpose of that sub-category called "Wall Sweep - Cornice" if the wall sweeps aren't assigned to it ?  and what would we do with more that we might invent along the same lines, like "Wall Sweep - Copings" or "Wall Sweep - Dado Rail" ?



So now the penny drops.  Maybe we have to consciously assign our sweeps to a subcategory (you think?)   And this turns out to be the missing piece of the puzzle.  Furthermore it's a TYPE property of Wall Sweeps.  So for each type of sweep you can choose a subcategory to associate it with.  But by default all sweeps sit in the root category for walls, aka the <none> subcategory ... and they respond to that, along with all the system wall types.



Why is this confusing?  Is it in fact confusing for many users?  How could it be made easier to discover?  Interesting questions and I'm not sure I have the answers.  It would be possible to put the default sweep into the subcategory where you might expect it to be, but would that help much?  Where would new types that you make go? (by default)



Perhaps, when you make a new sweep type Revit should ask us whether we want to assign it to a subcategory.  Would this be annoying?  Would we need another of those little tick boxes that say, hide this message in future?



Just in case you thought I was going to do a whole post without mentioning Project Soane ... my sample profiles where extracted from the Bank and while I was at it I decided to make a little collection, gathering things together from the various files and families.  It's not complete yet, surprising how many different profiles have been generated, many of them done as sketches at the time and being upgraded to profile families as I collect them.



The mouldings at the base of Tivoli Corner were originally provided by Paul Aubin way back at the beginning.  I seem to remember him pointing out that it was just a first rough draft but I had never zoomed in close.  Turns out that the curves were represented by straight lines and when I stopped to think about it the profiles were too deep.  He had quickly traced over a portion of drawing where the mouldings are at an angle to the viewer.  The resolution of the drawing is not so hot, but I did my best to interpret it and upgrade the mouldings.



That's it for now.  I'll make the profiles collection available when it's more complete.