PIE CHART IN THE SKY

I've been going through various Dynamo tutorials that have been sitting patiently on my hard drive waiting for me to finally "find the time"  I enjoyed building this simple graph that throws out a range of numbers, uses them to place points in a row and then wiggles one of those rows by feeding a sine wave into the Y axis.

One way to check if you absorbed an idea is to reapply it to a slightly different situation, so I turned the whole thing on its side and wiggled both rows to create a rippling surface.  This is all done with Dynamo running on top of a conceptual mass family: Point World, because I'm using points.

So when you switch off Dynamo, or save out the family to an RFA, you end up with a frozen wiggly surface, which you can use for "Roof by Face" and of course you can go back to Dynamo any time to thaw out your surface and use the sliders to quickly generate multiple variants.  In this case I have six active sliders, including different amplitude controls for left and right. 

I think I forgot to put in a width slider, but that could be added.  Maybe I should do a "node to code" while I'm at it and produce a black box with 7 input sliders and a single output.  But instead I got carried away with the resemblence to the little school house that Gaudi built in the corner of the Sagrada Familia building site.  This is not it, but rather a fantasy building inspired by the same idea.

Just before the weekend began I was talking to one of my good friends in the office, a young Egyptian architect with a passion for design, and we chewed over a concept for a tower built with modular units that seem to converge from all points of the compass and stack themselves up into a digital ant-hill.  It seemed like an interesting challenge for a dynamo novice like myself.

I started with the function that Zach used in the session I attended at AU.  He used it to make a truss.  I want to thread beads along a string.  First step is to test out that concept.  It's easy enough, and the family doesn't have to be Point World based.  This is a Generic Model starter family that I use to save a bit of time setting up reference planes and parameters: just a box.  Draw a curve directly in Revit.  Select it and press run, you get a row of beads which responds to a slider controlling   how many there are.  (0..1..#divisions)  Pretty much like using Normalised Curve Parameter and a Repeater in Point World, but the repeated element doesn't have to be an Adaptive Component.

Next we have to flip this into the vertical plane, then use a more complex curve.  A point-based spline in this case.  In fact let's have 2 or 3 of them converging on the family origin and shooting up vertically like the graph of human social development that we all know and love.

Problem is, I can only select one curve at a time.  Even if I duplicate the whole arrangement, it only seems to deal with one output at a time. 

There may be other solutions to this (for all I know, which isn't much) but the one I blundered into involves making a list.  I have it on good authority that lists are "huge" so that felt like a mini breakthrough.  Flatten the list to turn it back into one long stream, and it will go back into the "string of beads" routine not caring a wit that it is jumping from spline to spline every 20 items or so.

I need more splines, so the graph starts to bulk up a bit.  Lists don't care right ?  Just keep adding another index.  And it's starting to look like a thing.  Except that I would like the modules to vary in their orientation, even if they just alternated.  I can make a second type that switches width and length around.  But how to tell me list to alternate between the two ?

I'm pretty sure there is a better way to do this, but I came up with generating a list of families that's at least as long as my list of locations.  You can add in a couple of "count" nodes to keep track of the numbers.  How do you turn two "select" nodes into a massive alternating list.  I ran some tests first.  Start with 4 then do a list of lists to get 16.  That worked fine with ten items to place.

So I made a big lists of lists, 4 x 4 x 4 x 4 = 256, then flattened it.  I'm sure someone is wincing out there, but that's OK, it works but feel free to send me a better solution, it's all about learning at present.

I added a void to make my module slightly more house-like, plus a couple of hand-placed custom types to represent plint and core elements.  That's not bad.  Worth sharing with my mate Islam in fact.  Who sounded suitably impressed, but then you have to be polite on the social media. 

So of course I got carried away and did one of my multi-layered render jobs, then gave myself a well-deserved break and played some guitar.  New Years Resolutions kicking in.  I even got around to using the amplifier.  There was a scary amount of dust on my amp and the bag of spaghetti that goes with it.  To be fair, fine dust accumulates very rapidly here, has to do with the desert.

It was during one of my middle-of-the-night brainstorm episodes that I took the self-assembling ant-hill a stage further.  I realised that I needed more splines and it seemed sensible to group them.  Why not use subcategories so that you can isolate a group and edit with less confusion ?  We can colour code the lines. 

I already have some lines that stop half way up.  Standard practice for any radial pattern.  Some of your lines have to stop short.  They can't all continue to the middle, it's going to get too congested.  So I came up with a "node to code" thing that condenses 4 selection inputs into a single box.  And I'm going to try using 3 of these.  That's 12 splines in total (average bit less than 20 modules per spline... I'm safe with my 256 alternating family types)

I can't believe how well-organised this graph looks.  Each group has its own slider (shorter lines need fewer modules:) And I've been a good boy and added notes and comments.  So how about the geometry itself ?

I'm looking to create a rig that makes it easier to adjust the splines.  Maybe I want to adjust the angles between them, adjust the widths and heights.  At the moment that's really messy work.

So I made a massing family that's just a single plane surface: X & Y axes plus a curve.  You can draw a polyline using this surface as the Work Plane.  Easy to rotate, you can even parametise the angles if you want.  That's after you have assembled a bunch of them.

Actually, it was better to draw a polyline on one before copy-rotating them around.  I have 3 different types of rig, colour coded to match the subcategories that the lines belong to. It still looks quite complicated, but much easier to adjust than it was before.  Should be able to put a scale factor on the whole thing too.

Only took a couple of minutes to connect this up to my Dynamo graph and another couple for Dynamo to chug away and poplulate it.  Adjustments are quite rapid, but first time you run it takes a bit longer.

I put some elements in for the podium and the core again, just manually placed, and I think I would need another family to create some rings of modules in the lower levels.  It's too hollow down the bottom at present.  This is just a conceptual representation.  I'm not trying to think too hard about how each block is held up, but it shouldn't look too impossible.  At present I have whole strings of beads hanging like they are on a chain.  Not the intention.

Perhaps I don't need Dynamo for the inner sanctum family though.  A few circular repeaters in an irregular cone shape will probably do the job.  Give it a few parameters and stick it in there. 

So I'm testing out a hybrid process.  Dynamo is making a major contribution, Revit fluency forms the core (as always) and we've got some manual processes, judging things by eye.  Then of course there is image processing so that we get eye candy to sit back and reflect on, share with others, spark things off in new directions.

Behind all this is an idea: kind of a literal interpretation of "Data Driven Design"  Take a single line curve (rising temperatures, global polution, population of Africa) cross it with a pie chart (regional wealth distribution, market share of whatever, ...) and generate a building.

It's a bit silly, but that's never stopped me before.  Maybe we could do something with Excel.  Collect all the parameter values for the rigs (X, Y, rotation, etc) do bit of processing in Excel, then throw them back in.  Could be a more powerful way to generate options. 

At present I have just 2 different modules, but I have it set up so that it would be very fast to up that to 4, which may well be enough.  Beyond that we would probably want to look at randomising the list a bit.  Need to do that after flattening it I guess.

Maybe we will get into all that if Islam takes the bait.  I'll let you know.

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.

 

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.