"The Helen of Geometry"

 

... Otherwise known as the Cycloid.  Not gonna lie, i had never even heard of the mathematical description before, and the reading on these fine shapes is absolutely astonishing.  But i digress.  Last week i was showing off one of our projects (the large "classic" Brick building), and if you see the image from last weeks post, there is a very wide Stone Arch above a drive lane coming under the second story of the building.  Early in Design, a lot of the Columns, and Capitals, and Profiles, and Trim pieces were appropriately placed in rough form, and as the design progressed they were iterated in to something properly proportioned for their appropriate style.  So, they bequeathed me the Wikipedia entry describing the shape of the Cycloid, a.k.a. The Helen of Geometry, which is what shall actually be placed above the Drive Lane.

The math behind it sounded pretty entertaining to me, although i admit pretty quickly that Grasshopper is probably a much better candidate for something like this. EDIT:  Zach says Python as well... Still, armed with wikipedia and Wolfram, providing formulas for coordinates and arc lengths along the form, i figured it was doable.  My first attempt seemed pretty straightforward: 

 

Armed with formulas for X and Y along the shape, i would generate 10 X points, all equidistant.  Their X distances calculatable since the overall width of the form is a direct relation to the Radius of the acting circle (The width is an unrolled circumference of the circle, exactly).

 

Then, id use the formulas to generate their Y coordinates, based on those X's.

 

(Let me start by saying:  I am not a world leading mathematician.  I got through Calculus like a champ, but i dont know how i would put a Differential Equation in a Revit Family.  That takes some Buildz skills.)

 

You can see in the image that the final product didnt go the way i originally planned, but thats because there were options:  I had intended to plan the X values, and infer the Y values based on them.  You can do it, as Wolfram has a badass Equation describing X and Y in relation to one another.

 

But there wasnt much point: My intent was simply to have an instance parameter in the family that let me type in a value from 0 to 1, with decimals.  (0, .1, .2, .3...).  From there, i wanted it to build the Y values.  But did i really care if it put them at predefined X coords?  Negatory. So in the end, xPercent still exists, but now all of the families "sit" on the same origin, and the X coord is also "pushed out" using the formulas, instead of locking the different instances to the reference planes.  It involves a few wacky variations moving between degrees and radians (and a "Number" since we know how Revit is about units...), plus a throwback reference to David Light's blog on how to enter Pi as a variable in Revit "Pi()".  That was handy. =)

 

After making it so the users could input either "r" or the CircumferenceTotal (a.k.a. the width of the drive lane), it was a Connect The Dots exercise.  I am still IMMENSELY frustrated that the Conceptual Massing / Adaptive Component Editor is the only place we can Spline Through Points (where points are the end of other Model Lines) and have them stay constrained.  But i digress.  No, i dont digress.  It pisses me off.  Because an AC cant nest in to a Face Based Family, and its not an AC for ANY other reason.  Which means i have to have my project team place an Unhosted component, then edit the Profile of a wall to trace the stone Cycloid, which they cant "trim" the sketchlines of because its a Picked Spline.  REALLY?? Sigh. (Ill post the imaged in the project once they refine the placement and the Profile). BTW, there were other issues, as well.  In a REAL Cycloid, the 0 point and the 1.0 point are tangent to vertical.  In Revit, a Spline through points wont let that happen.  I even placed two additional vertical points underneath the 0 and 1.0 points to force it *tighter,* but it doesnt matted.  So it takes a void to lop of the bottom of it.

 

Anyway, since thats the case, Adaptive Component it is.  The AC has a nested "Stilt" family, and thats whats doing everything except Connect-The-Dots, which means we will use it "for reference" inside the Window Family where we need to describe this shape as well.  The Window just wont be able to be parametric.  I would love for every Line to have Reference Points at the end that could be woven through, in the traditional Family Editor... But that continues to be my wish. 

 

Wrapping it up, the obvious question (i hope) that i had to bring to the Design Team was:  Whos building this?  And how are we documenting it?  The reason being, while a Cycloid is graceful to form in a GIF image at the top of a blog... Its awfully close to a semi-ellipse, which is awfully close to approximated arcs.  Im all for modeling it correctly, but im all for having it built correctly as well.  And if they arent going to bother, i can certainly make tangential arc segments in the traditional family editor with far less effort, and then we can tie down real X and Y dimensions for the subcontractors.  In our heart of hearts though, we wanted a Cycloid.  And... As a small part of me hopes we end up the GC on this job as well (at which point we can zing out some awesome fabrication models from this information), we figured we would do it. 

 

Its full value for the Project will ultimately live or die on "what happens" with this geometry now that its there.  It must be described for its audience, in such a way that it can get built as desired, or transmitted in such a way that it can be used again.  Otherwise, having a fancy Revit Family in a fancy Building Model just to hack dimensions on it is rather... well, basic.

 

Here is hoping we can keep this somewhere past basic.

 

 

The Elusive Origin aka The Original Origin aka Not the Current Origin

I must admit:  It has been a few years since i ran up against this problem, even though i was reminded of it while explaining to someone interally why there are THREE origins in Revit:  Shared, Project, and Relative.

 

Alas, this isnt a post on Shared Coordinates, just a small reminder about another gotcha that appears in the Family editor:  The Original Origin (The Elusive Origin) versus the Real Origin.  If you know me well (or if you dont know me at all), you know one of my hundreds of obsessions is Door Content, and how it affects Architects abilities to document efficiently... Of course, the bigger picture is:  What does it REALLY mean to document doors correctly for buyout and installation?  But ill check that at the door.  Todays is a smaller issue. Im redoing the CW Doors in addition to the Regular doors to make some changes:

 

1.  Parent Families by Action.  (Most people do this, my last library iteration was a bad choice. The "action" definition was part of the Panel Type.  Horrible idea.  I have to own that).
 

2.  Panel Typology including Materiality (not finish) at the Type Level, not instance.  Less fields in the "door schedule" as more is defined by Type of Panel.
 

3.  More options to reflect the real world.  This meant adding in the potential for CW/SF doors to have a Frame inside them as well.  Sometimes Doors in Storefront Systems get an additional frame jamb and head aside from the surrounding mullions, and i wanted that capability.  So the new options looked like this. (You can see the door at left has the frame).

 

But we all know the way Doors are Curtain Wall Panels in Revit means you get two choices: 

 

1. Door Panel Sizes flex with Curtain Wall Grids, runs risk of Door Schedule showing wacky Dims.

2. Door Panel Locations flex with Curtain Wall Grids, runs risk of gaps in between the Doors.

 

I personally prefer the latter.  Reason being BOTH infuriate Project Teams, but the Door Schedule is sometimes already seen as a WonderWall of data that is more like PowerBall and less like steadfast decisions.  So any chance i can get to make the schedule not go nuts, i "jump in it."  But, i also have Check Value Reporting Parameters in our Curtain Wall Doors.  They tell the user how much they have to adjust the CW grids to make the model AND the schedule legit.

 

While working on my new CW Doors to finish out the Door Library, i found this beauty:  A rogue 7/128" hanging out somewhere between the CW Grid dimensions (which are correct:  All dims and units are rounded to 1/256" in our files), and the Reporting Parameter dims of the Doors.  Nicey nice. First i tore through the Door (CW Panel) itself, assuming i had missed something minor... But there isnt even any complex math in it.

 

So then i realized whatever it was had to be in the Mullions of the CW/SF in the Project.  Joy. Although it drives people crazy, we have a LOT of Mullion Types, and a lot of Profiles, so we can accurately model varying shim spaces, glass pockets, etc.  So i opened up the Mullions, and re-certified that the Origin-defining Ref Planes were locked centered.

 

Then i remembered this minor bit of stupidity that hit me back in 2009, when i was making NCS Compliant Section Heads in New York State:

 

That Revit sometimes forces you to use the Original Origin of a Family, and not the currently defined origin.  In that regard, its sort of like Relative versus project.  And in the Profile Family editor, you cant see origins (aside from ref planes), so i pulled the old school "Insert CAD drawing with an X at the origin OtO, and see where it comes in."

Sure enough, it wasnt sitting pretty on the 2 ref planes that were defining my origin currently... It was the ever elusive 7/128" off that my Curtain Wall Panels were reporting.

 

Thankfully its got an easy (albeit stupid and shouldnt be necessary) fix:  Picking up everything in the family and moving it towards to "original" origin by the offending amount.  In this case, 7/128".  I hadnt seen this issue in a number of years, so i forgot that back in the day it caused a few issues for me where Section Heads had a gap from the system Witness Line, and tags were somehow offset from the leaders that were supposed to be touching them.

 

It still feels a but odd that i can have Reference Planes Defining the origin and have them not be the Finite Origin that all things referencing that Profile are, but i guess its just another day with Revit.  

 

Having solved that riddle, everything now appears to be playing by the rules.  I cant say my users will be any more happy to have these CW Doors over the old ones (they are Revit Curtain Walls, after all), but they will be more functional, and will more accurately represent what i would like them to be for Documentation and Construction.

 

They certainly havent gotten any more difficult to use, even if the CW Doors are a "wash" with the old ones.  These are compatible with our new Wall Hosted Doors, which (i think) are worlds better than the last set. 

 

At the very least, i got to have a nice stroll down memory lane relearning things i forgot i used to know a couple of years ago... And now we can all make jokes about the Elusive O... O is for Origin.