UP IN ARMS

These explorations took place about 6 weeks ago.  I went down a couple of blind alleys, or perhaps that is the wrong expression.  They were alleys that will almost certainly lead somewhere very interesting, one fine day.  But not today.  First thing you learn as an architecture student.  Don't get seduced by clever ideas.  Address the programme.

First idea was a box rig.  Wasn't quite sure how to use this to best effect, so the arrangement of rungs is a bit arbitrary. Tried hanging some ref lines first to simulate the variations in leg shape and proportions that might be possible.

The actual leg was going to be three instances of a two point adaptive component, nested into a 4 point adaptive.  Thigh, calf & foot.

Loaded into the box rig it seemed to have a lot of potential. Plenty of variation, from humanoid to frog-like.   But how to control the proportions of each segment in a coherent manner ?

I set up separate slenderness & bulge factors for each of the 3 components.  So you can create a named type, say "Frog" and set an appropriate box shape.  Then you tweak the slenderness & bulge factors until it looks right.  So far so good.

Obviously you need a pair of legs.  Link them together with a line representing the pelvis.  3d snapping will attach it to the "hip joints".  The next part is inspired by Marcello's famous hydraulic lifting family.  Host a circle on a point and a line from the centre to the circumference can be driven by an angle parameter.  Very stable.

So I've got a spine with a variable angle.  Easy enough to mount shoulders and neck on the end.

The neck angle & length (radius) follows the same principles as the spine. Parameters mounting up here.

By the time I add a couple more leg families to act as arms it's all getting a bit too complicated.  Angles coming off other angles, bulge factors coming out of my ears, and to top it all, they all look a bit insectified.  Not sure this is heading in the right direction.  Getting rather confusing for the end user.

Also I have the feeling that I need some kind of universal joint.  Isn't that what happens at the shoulder ?  More or less ?  I got an idea in my head about 2 semicircles at right angles.  One rides on the other, and the arm rides on that. If you can keep that assembly vertical you don't have to worry about compound angles any more.  Just one parameter for up/down angle and another for back/front.

That worked pretty well, but then I got the itch to play with vanilla again.  How far could I get with trying to do this kind of thing with ref lines in a standard Generic Model template ?

This turned out to be quite a revelation.  We all know that straight ref lines in vanilla are basically the same as the ones in Conceptual Massing.  They have planes at right angles running all the way down, and two more at right angles again closing off the ends.  You can surely host ref lines on the planes of other ref lines.

So the same concept of "up-down" & "back front" angles for the upper arm can be achieved using vanilla by hosting a ref line on the plane of another ref line (both locked to the same shoulder point)

I used a rectangular extrusions to represent the shoulder blades.  These remain vertical of course. You have angle up and angle back from the shoulder and an angle for the elbow joint.  Forearm ratio above 1 makes it bigger than the upper arm.  Below 1 has the reverse effect.  "Scale by forearm" sets the length of the forearm and is intended as a basic module for scaling purposes.  For example, "slenderness" is used to calculate the radius of the sweep.

How is this going to fit into a body plan ?  I felt the need for a diagram to guide me.  And what better drafting software than revit itself ?  The legs "grow" upwards from the ground, controlled by a "Pelvis Height" parameter.  The trunk (torso) needs to move up and down with the pelvis and swivel between almost horizontal and almost vertical.

Note how I naturally switch into orthographic mode to draw these abstractions that will guide me in the building process.  The power of orthographic is awesome, and one of the fundamental reasons why the BIM approach to modelling wins out over Max or Sketchup (for example) when you want to design something that will be manufactured or constructed by a third party.

My first attempt at building this tetrapod uses the universal egg as torso.  And it looks like a promising approach at this stage. Reptile, primate, hoofed mammal.

Then I experimented with a revolve for the torso, hosted on a rotating ref line.  I think this was my first time to use trig functions in Revit formulae to calculate the length and angle of a hypoteneuse.  Nice to know that I still remember this stuff after 45 years of neglect :-)

So I can get within say 1 degree of horizontal or vertical using the Length & Height parameters for the Torso.  Not quite the total freedom of the points riding on circles.  But this is good old fashioned, stable, vanilla.  Let's continue

This is a snapshot of my vanilla experiments so far.  Arms on their own.  Loosely assembled tetrapods, and tetrapods with rotating torsos.  All headless at this stage.  (and no hands, feedm, hooves, claws)

So I add a basic "Bird" (or Bat) body plan.  Stretching out the arms sideways.  And I bring in some heads and place them roughly where I want them, within the project environment.  I think this is about the right level of abstraction.

all very clever, but I couldn't help feeling that the original tetrapod made up of box rigs was rather simpler, potentially much more user friendly.

Another thing worries me.  The legs and arms use a rather different approach.  They are not true serial homologues of each other.  This is rather un-biological.  Basically all appendages are descended from a common root.  So I make the executive decision at this point to flip back into "Point World" and the original conception of box rigs.

One thing I did get out of the vanilla detour.  Keep the limbs cylindrical.  It's a more appropriate abstraction.  All those cigar shapes are too distracting.  Cylinders are much more neutral.  Allow the variation in size & proportions come to the fore.

So ... Generic Model Adaptive.  Set up ref planes.  Make two boxes with a gap between.  Parameters to control the lengths of the 3 sides, plus one more for the gap.

erect ladders using 3d snapping.  Hang sweeps on these to represent limbs.  The knee angle can be varied and/or reversed to form an elbow by varying the position of a point along a line (Normalised Curve Parameter)

This family is a generic "pair of limbs"  Nest 2 of these within another family which contains another Box Rig to control the torso.  The box for the arms is controlled by the same "pelvis height" parameter as the legs.  So a horse or a dog will stand on all fours (almost).  The offset from ground for arms is rigged up to equal the torso height (by a slightly devious method, hence the "xxx" label)

I will be uploading the families next week so you can figure this out if you feel the need. Basically both pairs of limbs grow upwards.  The legs are hosted on the base level, the arms are hosted on the base of a box.  This base of the box is "xxx" above the pelvis

At this stage the foot/hand/paw is included in the sweep.  Just the fingers are missing.  Later on I changed that.  The whole thing flexes quite nicely.  The torso is lofted from 3 circles (later 3 ellipses)  Simple enough, but you can control the amount of the bulge and whether it's up towards the shoulders or down in the beer belly.

You can also play around with ankle and toe positions.  I already mentioned the knee/elbow switch.  So this post ends with a snapshot of 4 abstracted body plans.  Have I found the right balance between variability and user friendliness ?  I think so.  The most expressive part should be the heads and hands. for primates at least.  So keep the rest simple.

TREES FOR INSTANCE

This is going to be a marathon.  I spent the whole long weekend climbing trees ... sort of.
I started this a while ago.  It was inspired by a post on Revit Swat.  I had the idea of using a rectangular rig for the leaf, so it would maintain a constant shape instead of getting fatter as it got shorter.

It's an adaptive rig so I can use it in a repeater (the branch)  I use a reporting parameter to extract the length of each leaf instance and use it to drive the width.  (W=L*F where F is a width factor)   Add a few rungs, hang a couple of splines and use them to make a surface.  Hey presto: a scalable leaf.

The branch is copied straight from Revit Swat, as far as I could make out.  Again it's a 2 point adaptive.  Connect the 2 points with a ref line & host a point at the mid-point.  Show all ref planes.  Place a point on the horizontal plane and give it an offset.  Show all ref planes of this new point.  Set the work plane on axis, place 2 more points, offset these to either side.  Use spline-through-points to
create 3 curved ref lines. 

Select these & Divide Path.  Place a leaf on one side.  Repeat.  Do the same for the other side.  We have a branch.  A couple of points here.  You will get an error message after the repeat command because it's impossible to make a leaf at the ends of the line (it would be zero length).  To avoid this you need to set beginning & end indents for each of the repeaters.  Once this is done it will be possible to control the number of leaves with a parameter. 

So the next stage is to place branches in a tree.  All these families are "Generic Model Adaptive" with the category changed to "Planting" (and "Shared" unchecked)  I used a loft based on 2 circles for the tree trunk.  Then more circles to create repeaters for the branches.  The end points of the branches were set to "vertical on placement" basically so that they don't fall over on their sides.

One of the advantages of making trees from Revit native geometry (as opposed to 3d CAD trees embedded in Revit families) is the ability to apply material parameters.  I decided to have subcategories for global control of materials, & parameters to act as overrides where needed. 

I have instance parameters for the base radius & height of the trunk.  These exist in the basic tree and are linked through to matching perimeters in the final family.  I ended up with a family where the overall height is set by the inbuilt type parameter, but the trunk shape can be varied using instance parameters.  

You may have noticed that the leaf has changed.  I was struggling with displaced geometry at this point and ditched the rectangular rig.  By now I have a family that has ballooned to 6mb.  I was curious what would happen if I exported this to dumb CAD geometry and then embedded this in a planting family.  This did indeed reduce the file size, but at the price of making materials harder to control & losing the variable proportions. 

Have you ever noticed that file sizes in Revit fluctuate for no apparent reason ?  Anyway it turns out that my Revit trees settled down to around 1Mb later on.  So I dumped the CAD idea.  Instead I went for simpler branches in 3 rows.  This eliminated one level of nesting.  Just make surfaces directly from the 3 curves in the branch family.  I also added one more circle to the trunk to give it a subtle curve. 

I was pretty chuffed with this family.  Sadly attempts to control the slenderness of the branch/leaf created unpredictable geometry ... groups of branches flying into the air etc.  Couldn't understand that.  Experimented with a "ring of branches" family nested 3 times.  Also unpredictable.  Eventually I made the family again from scratch and achieved a more slender version.  In this final image most of the trees are the second version.  The trees in the background to the left are the first version.  You can also see one or two aborted experiments way back.

Second morning and I went back to the original leaf idea and rebuilt it from scratch.  For some reason it decided to behave itself this time.  Gave me a family that looks a bit like a cycad.  Used to have those in my garden in Zimbabwe.  Fascinating plants. 

I was about to nest this to enable scaling when I realised that I had all the control I needed via the adaptive family parameters. 

All good so I decided to move on.  What about a deciduous tree ?  Maybe I could use a divided surface and curtain panels to scatter triangular shaped leaves around a canopy.   Just for fun I made the canopy revolve from an old fashioned spline (not the spline through points type)

For the divided surface I used bent triangles.  Made a very simple curtain panel family, loaded it and added a trunk.  It works,  probably could add all kinds of embellishments & variations, but for now I just added a "resolution" parameter to control the number of surface divisions (in both directions).  Eventually I rigged this up to adjust automatically to the built in "height" parameter that controls scaling of planting families.  That way different sizes of tree have more or less the same leaf size.

So let's get back to the idea of an instance parameter for random variation of sizes.  You have a tree family (A) nested inside the final planting family (B).  Link the Height parameter in A to an instance parameter (Ht) in B.  Create a number factor called F.  Use the built in Height parameter of family B, multiplied by F to control Ht ... ie the Height parameter of family A.  End result ... The inbuilt Height parameter works.  You can create families with typical heights.  BUT you also have a scale factor "F" which acts as a a multiplier factor. 

Place a few trees.  Fire up randomiser (free plug in from DP Stuff) fill in the various fields, set min & max values, press randomise.  The trees randomise around the typical height.  I did this with an OOTB RPC family.  Now I'm not crazy about RPCs, they look a bit flat ... mostly because they are flat ... they look OK from street level, but with a high camera angle, not so good.  For better trees, use 3D max, or maybe Lumion.  But there are lots of times when we want to have trees directly in Revit.  RPCs are one way to do this.  Random variation in heights will help to make them more convincing.  Ramdomising the rotation angles would also be good. 

Turns out this is also very easy to do.  Just rotate family A slightly & create an angular dimension between the family and the Centre L/R reference plane.  Label this with an instance parameter.  All done.

Now we come to a big drawback with the adaptive component based trees.  Can't embed symbolic lines or detail components.  No visibility controls for selectively hiding geometry in plan view.  This is a big drawback if you want to use the mass modelling tools for regular familes (planting, plumbing, furniture)  There are 2 good reasons for using symbolic representation in orthographic views.  First to reduce processor load & speed up regeneration times; second to give a cleaner graphic representation.  Both are especially important with complex curvilinear forms.  Exactly the kinds of shapes where the mass modelling tools would help. 

Enough of the moaning.  Let's get back to RPC families.  Here we do have symbolic representation.  It's embedded in a planting family called "xxx Base" where xxx could be "Deciduous" or "Tropical" etc.  It's one of 2 objects in the RPC family, the other is a "render appearance".  It's the object we see, and somehow it links to the render appearance stored in any of the folders listed under the Rendering tab of "Options".  Whenever you select one of these appearances, the object you see in the project also changes shape in an appropriate manner. 

You probably know all this.  The point is that the 2 objects scale up and down together.  So a 10m Scarlet Oak will have a plan symbol twice as big as a 5m Scarlet Oak.  The downside is that you only have one symbol to represent all the different deciduous trees.  If you have a tall thin tree & a short fat tree, one of them is going to have an inaccurately sized plan symbol.  It would be better if the plan symbol was separated from the RPC object.  Then perhaps you could a different scaling factor to the plan symbol for each tree type.  You could also have a number of different symbols loaded into the family so that different tree types could be identified by their plan symbol.  A nice idea, but does it work ?  I did a bunch of tests with simple planting families, just a cylindrical extrusion.  Two separate instances nested into the same blank family.  I worked out how to control the two instances separately. 

Next step was to do the same with plan symbols.  It's a lot of work & you have to link each type's parameters, one by one but I got there in the end.  Struggled a bit with the proportional scaling of plan symbols, but got there in the end.  When I got really stuck I went for a lie down & scribbled a bit of algebra on a scrap of paper.  The answer was counter-intuitive (for me at least) but it seems to work. 

I spent a couple of hours converting old CAD plan symbols into Revit symbolic lines.  Did all this in a temporary RFA file and copy-pasted the end results into my "deciduous base" families.  I made quite a few and loaded 5 of them into my final trial which takes all the types in "RPC deciduous" and maps them into my host family.  Perhaps I need a diagram. 

Going to finish with a render showing the difference between standard & randomised families.  I'm quite proud of this.  Useful in shaded views & in renders.  The correct sizing of plan symbols is another breakthrough.  Combined, these 2 customisations make for much more effective RPC trees.  The adaptive component families were interesting experiments, but the RPC work has a much broader application.

Still a bit rough at the edges, but you can download my modified RPC deciduous along with a pdf summary below. (link to follow)





 

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.