"Edit Cut Profile" failure with Wall By Mass- RAC 2008, and Doors in Tapering Walls

So, until we get the capability to give a Wall a vertical angle in Revit without using a Mass/GM family and a Wall By Face tool, that remains my preferred method for putting walls up in non-vertical orientation.



That said, everyone who's worked with me knows im a notorious hater of Filled Regions, in Wall Sections. Even with the capability to lock/constrain them to the modeled objects, i always take the side of using Edit Cut Profile on the cut patterns of the modeled objects, wherever possible.

Most of the time this is simply for detailing and cleanup in small areas, but it also comes in to play in areas such as beam wraps, where a Wall may be used (built as a chase) instead of walls and a ceiling below, for simplicities sake. In any event, while working on detailing the above pictured tower, it become evident that Edit Cut Profile cannot be used on Walls that are created with the Wall By Face command.

When you attempt it, you are able to get in to sketch mode, and you can work until you try to finish the sketch. That is when you get the ominous "Fatal Error has occurred" window.



This file and a test file were submitted to Autodesk, who have passed it on to development, as it appears to be a code issue. Hopefully they will have it resolved in the 2009 release.


As the self proclaimed "Model Nazi" you can imagine the amount of anxiety i had, at having to concede to a project team that they could detail this portion of the building using Filled Regions, haha.






These walls presented another interesting issue as well:


When i went to place a door in the wall, the door was only able to be hosted at the very base of the wall (Right at the Level T/O Slab). As i was trying to place an Access Door from the roof, this was not useable. It would not allow us to place the door on the ground and raise it up, eiher. We received an error that the door failed to cut the wall, and that it was deleted.


The fix for this was interesting: We were able to place WINDOWS inthe walls without incident, so we used Edit Family to make a copyof the door family. We then changed the families catagory to a Window Family, and then we placed it in the tower. AFTER having placed the "window", we were then able to go back to the fmaily, and change its catagory back to a Door Family. This let it stay placed in the desired location in the tapering wall, while still scheduling it as a door.


Fun times with Tapering Walls!

Two long personal months!

I must say, writing here about the tribulations and adventures that we partake in while modeling in revit, is one of the few things that i really enjoy totally "rocking out" while doing. Suddenly, i blink, and two entire months have gone by. On the one hand, it would appear i simply had nothing of value to say anymore, LOL! In actuality, its been a fantastically busy couple of months.



The below mentioned trip to Autodesk University happened, which was adventurous as always. A few notes on my adventures in Vegas;



1. If someone asks you if the MGM and the Venetian are within walking distance, ask then to QUANTIFY walking distance. I was yelled at relentlessly all week for that one, but everyone! Be green, people! Walk! :)


2. Trying to continually follow things on the 360 degree screen on the mainstage will almost make you want to throw up. :) Awesome show, as always.

3. It WAS certified on this trip that coffee from the venetian food court CAN be an absolute substitute for sleep. :)



4. AU Unconference is a great idea. I absolutely loved the sessions i attended. I missed a few that i really wanted to sit in at, and i HOPE they continue and even expand on it in the following years. I could see the unconferences running the entire week while the classes are going on. I got some great feedback from the attendees in the session on strategies for dealing with multiple users of multiple skill levels all working together, and i've been meaning to post up about it. Ive been a bad boy, and didn't update the AU wiki either. The family Editor discussion Steve Stafford led, had a lot of great theoretical conversation, which i imagine could have gone on for hours. I would have rather enjoyed that. I STILL don't believe in the "super door" family, but then again, i don't agree with the entire tool that is in-place families, and obviously it serves a purpose. :)


In my defense for not having written in almost 60 days!! WHILE all this was going on at AU, i also had a project under a serious time constraint deadline, and i was in the middle of purchasing a house... My first one! Since i usually try to include a lot of pics here (who really wants to read anyway?) ill toss some in. Its a cute little cape, perfect for little me, all by myself. :) There is also a perfect room for the
computer, where i will spend my evenings geeking out with Revit models, as always. Oh the exciting life of a twenty-something, LOL!

I hope the 3 of you that faithfully read (har har) will still check back often. I DID get a lot of worthwhile table discussion material at AU, that id love to hear thoughts on... ALA DWF/RVT, information exchange, and the need and/or desire for what we all wan tout of our Revit models, and why. I can see DWF as the answer to so many peoples different desires from the wondrous file format that is RVT... but we really have to convince the powers that be of the validity of those wishes, or we'll never see the DWF that we (or at least i) want.

In any event, i will be updating again soon with some of these discussions... After one furious weekend of moving, which is coming up this weekend! Any of you within a few hundred miles are welcomed to the party! :)

AU Unconferences- Check it out!

Im looking forward to a productive unconference about Modeling strategies with more than one Revit modeler in a large project... Its Wednesday afternoon at 4:20 pm, for those of you attending.



Also, there are some killer unconference sessions! I can definetely tell ull be anntending a lot of the others, instead of some of my classes, hehehe.



Here is the schedule so far. (This is not final, i snagged the image from Joseph W's AU Blog (BLAUGI?):


























EDIT: The schedule is already out of date. It changes quickly. Heres a link to where it is: http://au.centraldesktop.com/auunplugged/Schedule

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. :)