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.
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.
thank for the wonderful post , lots of information gained , visit us Revit Modeling in uk
ReplyDelete