Since I recently wrote a series of posts about them I thought I'd mention yet another source of information about them. Daniel Stine wrote an article recently for AECbytes. Check it out!
Thursday, February 02, 2012
Wednesday, February 01, 2012
Nano Copters
I imagine this video is going viral to some degree by now. First thing I though of was how CGI and movies could harness these things to create even more realistic flight sequences like in Star Wars for example. I particularly like how the one copter can flip. I started imagining our own flying saucers one day. Or...one night, as a prank, these guys head for farm country, hook LED lights up and fly over Old MacDonald's farm and generate some UFO sightings? Cool and fun!
Scope Boxes
Dave Baldacchino wrote a post at his blog the other day focusing some attention on these so I dug this information up.
I wrote the following documents in 2004 while I worked for Wimberly Allison Tong & Goo (WATG). It's still relevant today though some improvements in visibility control (such as using filters for managing grids instead for example) have reduced the necessity for using them, somewhat. Their facility at managing consistent views of the model for multi/many story projects probably remains the most compelling reason to use them.
Ironically I didn't focus on that in this document, I guess I took that bit for granted. What I did do is focus on their role managing the visibility of datum in views. There is a sample project file on my site. Below this first embedded document is another that is a guide to experimenting with the file.
I wrote the following documents in 2004 while I worked for Wimberly Allison Tong & Goo (WATG). It's still relevant today though some improvements in visibility control (such as using filters for managing grids instead for example) have reduced the necessity for using them, somewhat. Their facility at managing consistent views of the model for multi/many story projects probably remains the most compelling reason to use them.
Ironically I didn't focus on that in this document, I guess I took that bit for granted. What I did do is focus on their role managing the visibility of datum in views. There is a sample project file on my site. Below this first embedded document is another that is a guide to experimenting with the file.
Tuesday, January 31, 2012
Basic Worksharing Guidelines
I wrote this document five years ago (I should revisit some of it). I posted it primarily because I wanted to play around with the Box feature to embed hosted documents after seeing it used on Jay's blog yesterday, he posted a 13 page document on organizing the project browser. I remember reading when Box added it a year or so ago and thought it was cool. I promptly forgot about it afterward. Naturally seeing it on his blog was a strong reminder!
Decided to add a few comments, until I get around to rewriting it:
The recommendation to add the word "central" to a central file name is outdated, it isn't really necessary anymore. The same thing is true for the recommendation to use Copy/Paste to create a local file. Revit has adjusted the process to make this fragile process a bit more obvious and easy. Recent releases have seen the addition of better alerts to each other regarding file status and borrowing elements, through Worksharing Monitor and new graphical workset display options. Last, for now, the language has changed from Saving to Central to the more obvious Synchronize with Central.
Decided to add a few comments, until I get around to rewriting it:
The recommendation to add the word "central" to a central file name is outdated, it isn't really necessary anymore. The same thing is true for the recommendation to use Copy/Paste to create a local file. Revit has adjusted the process to make this fragile process a bit more obvious and easy. Recent releases have seen the addition of better alerts to each other regarding file status and borrowing elements, through Worksharing Monitor and new graphical workset display options. Last, for now, the language has changed from Saving to Central to the more obvious Synchronize with Central.
Autodesk's Thirtieth Birthday
Shaan Hurley posts about Autodesk's latest milestone...time flies. I stole this picture from his post...founders "floating" in air.
Happy Birthday Autodesker's, don't eat too much cake!
Happy Birthday Autodesker's, don't eat too much cake!
Monday, January 30, 2012
Revit and Drop Box
In the context of Revit and Worksharing (central and local files) and using Drop Box.
Companies like Riverbed exist, and it's taken a lot of effort at Autodesk to develop Revit Server, because data integrity (Bits and Bytes/data transfer/latency) between Central and Local files (element permissions) is not trivial. Drop Box (I really like it btw) is really just copying files from one place to many places. It does it quickly but not quick enough for concurrent activity...not all the time, every time, never fail. It does nothing to manage Revit permissions and that's what will burn you, borrowing something at the same time as another person. It comes down to what sort of gambler you are. Comfortable with losing 10,20...30 minutes works?
There is hope...IF you are extremely competent with Revit...AND...the kind of person whose pen and pencils are arranged in a very specific order on your desk and can tell if someone touched your work area in some barely perceptible way...AND...the other person(s) you are going to try this with is your twin in this way...you might be able to pull it off. Might help if you are going about it as if you are playing Halo (WoW or COD) online and communicating (via a headset) with the other person continuously as you work.
It works great to share a project file if you and your teammate are "following the sun", you start working on it when they've finished for the day. The real danger is concurrency, doing stuff at the same time and the very real risk of borrowing the same thing at the same time.
I know there are people that have done this and have had success. There are exceptions to every "rule". There is a thread at RevitForum.org and post this morning at The Revit Kid advocating it works. What I'm most concerned about is people diving into a real project and having a go, then dealing with hours of work that can't be reconciled because they weren't prepared enough for the worst.
As I wrote at the beginning, if you ignore #1, don't be upset with #2. You've been warned. Be careful out there!
- Suggestion #1 - Please don't
Suggestion #2 - If you ignore suggestion #1 please be careful and don't get mad when things go badly.
Companies like Riverbed exist, and it's taken a lot of effort at Autodesk to develop Revit Server, because data integrity (Bits and Bytes/data transfer/latency) between Central and Local files (element permissions) is not trivial. Drop Box (I really like it btw) is really just copying files from one place to many places. It does it quickly but not quick enough for concurrent activity...not all the time, every time, never fail. It does nothing to manage Revit permissions and that's what will burn you, borrowing something at the same time as another person. It comes down to what sort of gambler you are. Comfortable with losing 10,20...30 minutes works?
There is hope...IF you are extremely competent with Revit...AND...the kind of person whose pen and pencils are arranged in a very specific order on your desk and can tell if someone touched your work area in some barely perceptible way...AND...the other person(s) you are going to try this with is your twin in this way...you might be able to pull it off. Might help if you are going about it as if you are playing Halo (WoW or COD) online and communicating (via a headset) with the other person continuously as you work.
It works great to share a project file if you and your teammate are "following the sun", you start working on it when they've finished for the day. The real danger is concurrency, doing stuff at the same time and the very real risk of borrowing the same thing at the same time.
I know there are people that have done this and have had success. There are exceptions to every "rule". There is a thread at RevitForum.org and post this morning at The Revit Kid advocating it works. What I'm most concerned about is people diving into a real project and having a go, then dealing with hours of work that can't be reconciled because they weren't prepared enough for the worst.
As I wrote at the beginning, if you ignore #1, don't be upset with #2. You've been warned. Be careful out there!
Friday, January 27, 2012
Occupancy Data Application
I've written about the workaround solution for documenting occupancy information in room tags in the past. I've even shared a sample project file based on the work I did for Scott Davis' past firm WLC Architects in 2005 (before he joined Autodesk). Until the API came along we were faced with a semi-inelegant solution that involved manual data entry and checking before plot day. Even after the API nobody really addressed this issue directly, till now...
Rahul Shah (blog: Revit Sticky Notes) works for Wood Bagot in the UK. He responded to a query at AUGI with a promise to write an application to push a calculated value to make Occupancy information taggable. He posted his solution today on his BLOG.
His written instructions on the blog post are:
You can DOWNLOAD IT NOW!
Rahul Shah (blog: Revit Sticky Notes) works for Wood Bagot in the UK. He responded to a query at AUGI with a promise to write an application to push a calculated value to make Occupancy information taggable. He posted his solution today on his BLOG.
His written instructions on the blog post are:
- NOTE: In order to use this plugin you will have to add "Occupancy Load Factor (as area type)" and "Occupancy Load (as integer type)" shared parameters to your project file and assign them to Room object as Instance. Also, calculated occupany load value is not dynamically linked with other values so if you change room size or occupany load factor then you will have to rerun this tool to update occupancy load value. Please read the Readme.txt file contained in the zip file for more information.
You can DOWNLOAD IT NOW!
Tekla's BIMsight 1.4 Released
I've not mentioned subsequent updates for this IFC based model viewer since my original post when it first became available. I received an email the other day letting me know that they released version 1.4.
This release includes enhanced presentation tools and they are really pleased to provide a new dedicated UI for Windows tablets! That should help focus effort on field applications?
A day late and dollar short, they ran two webinars yesterday...should have mentioned this sooner, sorry!
If you'd like to check out some images, CLICK HERE.
Want to read their PRESS Release?
This release includes enhanced presentation tools and they are really pleased to provide a new dedicated UI for Windows tablets! That should help focus effort on field applications?
A day late and dollar short, they ran two webinars yesterday...should have mentioned this sooner, sorry!
If you'd like to check out some images, CLICK HERE.
Want to read their PRESS Release?
Parameter Grouping
Consistency, CONSISTENCY, consistency...
This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.
When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.
If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?
Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.
I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...
I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.
Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.
Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!
If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.
Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).
This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.
When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.
If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?
Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.
- Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.
I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...
I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.
Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.
Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!
If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.
Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).
Subscribe to:
Posts (Atom)