TRIG IN REVIT... TAKE 2!

So if you recall from two posts previous, the issue was this: We needed the angle "Theta" to generate the arc length in the trig formulas. Now, for whatever reason (can anyone efficiently articulate what we call the "Revit behavior"?) we are able to constrain the Reference Lines to the springpoint of the arc, and to the intersection of the center reference plane, and the T reference plane. This flexes perfectly... Right up until we assign Parameter Theta to the angle dim between the ref line and the center ref plane. Once we do that, it tries to hold the value, and prompts us to remove the constraints. Boy, would it be nice if we could make the constraints override a value that isn't derived by any other incidental. So, we needed to derive Theta in some fashion other than with the angle dim.

James quickly realized that he could obtain Theta as follows: The sin of "Half Theta" is equal to 1/2 Chord, divided by Radius, if we look at the triangle produced. (SOH CAH TOA anyone?)hehe). So, having created parameter Half Theta, he used an arcsin function in his formula for Half Theta "=asin((0.5*CHORD) / (RADIUS)) and achieve Half Theta, and obviously he then made Theta = twice Theta. We obviously could have achieved this in one parameter, but Half Theta came about while exploring potential ways around our math problem. Now, we obviously don't need Theta (or Half Theta) to actually be used as a label in the family itself, as I've shown it in the first image, since its being driven by the math, and not by the reference line now.

What a fun refresher about High school Math this has been. Anyone else starting to think they've lost a little bit in our old age? (lol)

We have an answer!

Dont have time to capture and post it now... But James (the coworker with the original task) has found a way around the Theta Constraint problem...

Can you say "arc sin"....?

Trig family Broken.... :(

As much as i harp on my constituients to always "Flex them before you load them," i have evidently been a victim of not practicing what i preach. Something isnt working right in the below mentioned family... Any input on this? Im a little heartbroken :(

As you can see, everything flexes perfectly, including the Reference Lines that need to define the angle/paremeter "Theta." However... Once we actually place the Label for Theta, the reference lines become locked in at that angle, and no longer flex with the rest of the family. See below:

It is trying to hold Theta, instead of holding the constraints to the Reference Plane intersections where i have set up the reference lines. So far, ive tried a few workarounds on this, but havent gotten it to perform the way i thought it was...

So were past the hard math, now its back to pesky Revit Constraint headaches! :)

Shoot me an email or a comment if you have any ideas on the matter. Things ive already tried to circumvent:

An itermediate Reference line, dividing theta by 2, in to thetaby2, and constraining those. (Creating an angled EQ toggle). Didnt work, held them even, and held them constant. :(

Nesting the family in to another family, and trying to get Theta in the nested family. Once i constrained ref lines in the parent family, it wouldnt let it flex at all. Owned.

Deriving Theta mathematically and not tying it to the reference lines at all: Circular chain of references. I need theta to derive the arc length, and need the arc length to derive theta.

Freakin constraints! Someone help my wounded pride!

Trigonometry, Revit Parameters, and Scheduling...

I do regret that there hasnt been much going on in the last month or two that has been worth mentioning in a Revit blog... Thats a byproduct of a few jobs being at the wrap up stage, and a couple others being pretty early on. I havent had to craft up many things... Until yesterday. :)

Someone in the office was tasked with finding a linear distance around an arc, where the arc was not a full semi-circle. Furthermore, scheduling said distance, around several windows. Now, recently, i know there have been several posts on AUGI asking for "list parameters," or parameters that are driven by the geometry, but dont inflict the gemometry. I suppose any parameter works, in that sense... As long as its formulated by other parameters, which is what we did here.

We started out here: Some basic formulas regarding chords, arcs, circles, etc. As we wanted to create a formula for a parameter that would derive the arc length, we realized we would need parameters and formulas to provide the necessary values to calculate the arc length. Distance "t" (length from the arc's springpoint to the arcs center point) would be necessary. Likewise, so would the Chord distance. We would need the central angle (Theta) of the arc itself. Obviously, we would need the Radius.

A few things worth mentioning:

As with all Revit families and formulas, we quickly realized that we didnt need all these for the calc. We needed them to constrain things. T, for instance. If you work your way backwards from our end result, the parameter for Length T is never used... But we had to constrain the Reference Lines endpoints to get angle Theta. To constrain them, we needed value T to adjust correctly with the radius and chord changes.

Parameter "360": We still may not need this one. But in a formula, i couldnt figure out how to type in "degrees" as a unit, so i made a static angle parameter, lol. Chime in if theres a way to type in a value like "35 degrees" directly in a formula, haha.

Parameter "CIRC": Well, this was stupid. Im looking at the notes now, and the purpose of CIRC was to establish the circumference, for use in "ARC LENGTH" but it looks like in haste, i simply typed in the formula for CIRC anyway. So CIRC was irrelevant at that point, but the point is, we needed the circumference, one way or another. (Also, yes, i know i GROSSLY estimated Pi, and i couldve used an actual formula to derive it to more accuracy, but cest la vie.)

In any event, we started deriving the formulas... Heres where i had to call in help: Mind you, i was a big math geek back in the day, and like to THINK i still am. You can see in the circle formulas (which i got from http://www.ajdesigner.com/... thanks for the page, its great!) that they derive arch Length as a fucntion of Theta (in degrees) times the Radius. Anyone else have an issue with this? I couldnt wrap my head around how i multiplied degrees and Length, to come up with a mathemtatical unit (besides degree-inch, lol). So i called in a favor:

My good friend Brian (last name with held)is a Math Specialist at a local school district. He happened to be out at happy hour with some other math teachers. So i got him to hand the phone around the Chili's bar, which his teacher friend (Secondary Education math teacher) reminded me that i would have to convert Theta in to a length, using Pi. More accurately, i could take Theta's proportion to the overall circle (360 degrees), and ise that proportion times the circumference of the circle (CIRC), and i could then get the "length" of the arc length.

In finished form, it looks so simple, as the formulas (obviously) make all the reference planes end up in such a fashion that it looks easy to obtain. Maybe it is for you, i dont know... This took a few minutes for me to figure out, i might be slow, haha.

This brings up a host of other Revit questions that we could discuss based on this issue though:

When deriving parameters for scheduling such things, you have to wonder how exactly such things get scheduled. I asked the individual who asked for help: "You want a linear length, but its an arc that has thickness. So obviously the length is different on the inner radius and the outer. This was particularly a question of interest to me, as my first attempt was based on a material takeoff: If i know the cross sectional area of the profile used (the casing profile), then i could simply get the material takeoff in Volume, and divide it by its area in the Project as a Calculated value. I did this, but the number seemed off. Of course, i dont know where such a calculation would place the length. The inside, the outside, or somewhere in between?

So how do we (as an industry) decide HOW we quantify, WHAT we quantify, and who and what will guide such arbitrary decisions? Obviously some of these decisions are based on the manufacturing principles, and how the manufacturers will want take offs... But even from a simple Revit perspective, how will you reign in everyone making such families, so that all calculations are consistant, if nothing else? Id LOVE your thoughts on the matter!

Pardon the typos and spellcheck. I biked here, and the sun is going down... Ill spellcheck this tonight. :)