This is an update to a much earlier post after getting a couple comments on that thread. These are three companies I'm familiar with that are providing solutions that contend with sharing details between projects and multiple model projects.
Revolution Design - Revit Workflow
26 Degrees Software - ViewAQC
Parallax Team - Parallax Linked Details
Check them out!
Showing posts with label Projects. Show all posts
Showing posts with label Projects. Show all posts
Monday, May 06, 2019
Tuesday, February 20, 2018
Copy Monitor - A Different Way?
Morning musing...
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.
Wednesday, February 11, 2015
Sorting Parameters - Shared Parameters and Projects
With 2015 it became possible to move parameters into more desirable positions within the properties of the family. In the family editor we see a Move Up and Move Down button to make this possible.
In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:
He then added:
He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.
In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:
Shared parameters are shared between families in the project. The first family to load a shared parameter definition into the project defines the behavior of the parameter (in other words when loading a family into the project the description stored in the document is the one that is used). In this case, there was probably a family that was loaded with these parameters defined as "Other than the one from the family".
He then added:
The biggest problem is the shared parameter definition in the document cannot be edited (or deleted!) from the project. Purge unused also does not clear these definitions. There is no way for the customer to fix their file.
He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.
Wednesday, January 08, 2014
Always Unless - Interacting with Dimensions
It is fun to tell someone how to behave with elements and dimensions in a project and then the next day talk about the family editor and contradict that advice.
For example in a project we select an element like a wall and then interact with the dimension value (permanent or temporary) to move it. If we select the dimension first we end up in the Dimension Text dialog instead. Revit thinks we want to override the dimension with text or add a suffix/prefix.
In the family editor however we can select a dimension that has a parameter associated with it and interact with the dimension value directly to change a referenced element's position.
Just remember, It's the same only different or It's always like this except when it isn't.
Monday, October 10, 2011
Adirondack Castle
After working in the theater equipment business (lighting, rigging and curtains) for eleven years I found myself burnt out. Truthfully I was burnt out at around year 9, or at least definitely starting to char. When I was looking for that next thing I stumbled into a good friend and fellow indoor soccer team mate, Joe. He joined a small boutique architecture firm in the little village with the unusual name, Skaneateles, NY.
Ramsgard Architectural Design is run by Andy...Ramsgard, thus the name. He's built a solid, well regarded practice, and enjoys a legacy of great projects in his still youthful practice. Joe introduced me to Andy, Andy gave me a freelance drafting assignment which turned into a full time gig. Transition from theater biz to architecture biz via the side door complete! Great experience and I still use the things I learned there today...so thanks to Andy (and Eric, Joe, Frank, and Sherie) for the memories!
As if running a business isn't enough to keep him busy Andy has taken on another challenge. He (and his family, wife Sherie, and kids Ruby and Rex) bought a unfinished castle in the Adirondacks. They've been working since to take another man's dream and see it through to completion.
A dream formed in eight year old Ed Leary's mind during 1951, a dream of building a castle. In 1983, at forty years old, he finally saved enough money to get started with buying 20 acres of land. He worked at it for just over twenty years until he died of a spinal infection at sixty-two. The property and the shell of the castle "bobbled" back and forth for a number of years between family members until the Ramsgard's came into the picture. Here's what the castle looked like during their first visit.
There's more to the story and Andy's wife, Sherie, started blogging about it in May 2010, at least it looks to me like she's doing the majority of the posting. Considering it's a weekend warrior project they've made some serious progress since. Here's a picture from recent post from last month.
If you are curious you should check out their blog and follow along. If you are in the Adirondacks you might be able to be a new friend and help out during the weekend. They've got some rocks they need to move, among other things!
A man's home is his castle and Long live the King (and his Queen and kids)!
Ramsgard Architectural Design is run by Andy...Ramsgard, thus the name. He's built a solid, well regarded practice, and enjoys a legacy of great projects in his still youthful practice. Joe introduced me to Andy, Andy gave me a freelance drafting assignment which turned into a full time gig. Transition from theater biz to architecture biz via the side door complete! Great experience and I still use the things I learned there today...so thanks to Andy (and Eric, Joe, Frank, and Sherie) for the memories!
As if running a business isn't enough to keep him busy Andy has taken on another challenge. He (and his family, wife Sherie, and kids Ruby and Rex) bought a unfinished castle in the Adirondacks. They've been working since to take another man's dream and see it through to completion.
A dream formed in eight year old Ed Leary's mind during 1951, a dream of building a castle. In 1983, at forty years old, he finally saved enough money to get started with buying 20 acres of land. He worked at it for just over twenty years until he died of a spinal infection at sixty-two. The property and the shell of the castle "bobbled" back and forth for a number of years between family members until the Ramsgard's came into the picture. Here's what the castle looked like during their first visit.
There's more to the story and Andy's wife, Sherie, started blogging about it in May 2010, at least it looks to me like she's doing the majority of the posting. Considering it's a weekend warrior project they've made some serious progress since. Here's a picture from recent post from last month.
If you are curious you should check out their blog and follow along. If you are in the Adirondacks you might be able to be a new friend and help out during the weekend. They've got some rocks they need to move, among other things!
A man's home is his castle and Long live the King (and his Queen and kids)!
Thursday, March 17, 2011
Your Project Team Should Use the Same Build!
A post at AUGI prompted me to reply and I decide to make it a post here too after discovering I haven't written about this here yet.
The essence of the question is, "Does it matter if we are using different builds in our firm?"
Short answer is...
A project team should be using the same build to work on shared project files. For example, an architecture team working on a "shell" project file and "interior/core/circulation" model (2 models) should all be using the same build. Anyone who is going to contribute to the project should be using the same build as the rest of the team.
Stretching the short answer...
Technically, you could have different builds deployed but avoid letting it happen within the same team. If a new person gets added to the team...pause and think about the build.
Personally I think it would be nice if the software would mention that situation when a file is opened. In an earlier post here on my blog I mentioned that David Baldacchino and David Kingham have written such a feature into their AutoHotKey Local File scripts. They've also shared their work here in another thread at AUGI (DK's Script & DB's Script).
Think of it this way, they don't issue new builds because they feel like it or just because a couple months went by and they are restless. They issue them because they've fixed stuff, stuff that has been aggravating users enough to report them and press for fixes. They also fix stuff that they couldn't deal with prior to other releases or builds getting issued.
When I use an old build while the rest of the team is using the new build my version can introduce a problem that the newer build fixes. When I get out of the project the rest of the team interacting with the project "fixes" what my build "broke". When I come back in and start using my build I can reintroduce the problem, starting the cycle over again. Much like passing a cold around the office "forever".
At its most harmless...nothing happens and we never notice. At its worst we have local/central file corruption and problems. How severe depends on how big the fixes are in the newer build.
I should also add that Revit doesn't have any problem opening files that use different builds as long as they are the same version, such as RAC 2011. The file format changes with a new "version". Builds are incremental changes to the code within a version.
How do you know what build you are using? Click the smallish arrow next the HELP button, then click About. Revit displays the build number in the upper right corner of the screen that appears.
The essence of the question is, "Does it matter if we are using different builds in our firm?"
Short answer is...
A project team should be using the same build to work on shared project files. For example, an architecture team working on a "shell" project file and "interior/core/circulation" model (2 models) should all be using the same build. Anyone who is going to contribute to the project should be using the same build as the rest of the team.
Stretching the short answer...
Technically, you could have different builds deployed but avoid letting it happen within the same team. If a new person gets added to the team...pause and think about the build.
Personally I think it would be nice if the software would mention that situation when a file is opened. In an earlier post here on my blog I mentioned that David Baldacchino and David Kingham have written such a feature into their AutoHotKey Local File scripts. They've also shared their work here in another thread at AUGI (DK's Script & DB's Script).
Think of it this way, they don't issue new builds because they feel like it or just because a couple months went by and they are restless. They issue them because they've fixed stuff, stuff that has been aggravating users enough to report them and press for fixes. They also fix stuff that they couldn't deal with prior to other releases or builds getting issued.
When I use an old build while the rest of the team is using the new build my version can introduce a problem that the newer build fixes. When I get out of the project the rest of the team interacting with the project "fixes" what my build "broke". When I come back in and start using my build I can reintroduce the problem, starting the cycle over again. Much like passing a cold around the office "forever".
At its most harmless...nothing happens and we never notice. At its worst we have local/central file corruption and problems. How severe depends on how big the fixes are in the newer build.
I should also add that Revit doesn't have any problem opening files that use different builds as long as they are the same version, such as RAC 2011. The file format changes with a new "version". Builds are incremental changes to the code within a version.
How do you know what build you are using? Click the smallish arrow next the HELP button, then click About. Revit displays the build number in the upper right corner of the screen that appears.
Wednesday, April 14, 2010
RAC 2011- Cannon Design and Yazdani Studio
You'll get to see a lot of this project for the next twelve months or so when you fire up Revit.
It is the Ordos Concert Hall in Ordos, Mongolia. It was designed by the Yazdani Studio in Los Angeles. From the Cannon site:
The Yazdani Studio of Cannon Design is a laboratory for exploration and excellence in architecture. Established upon the reputation and leadership of award-winning designer Mehrdad Yazdani, the Yazdani Studio integrates the best attributes of a design studio with the resources and reach of an international practice.
I took the picture above during my visit to the Autodesk office in Waltham last week. It's a 3D print of a cut-away view of the model, if it isn't obvious enough. I couldn't create a link to the description of the project the way the Yazdani Studio has their site configured so here's a screen capture of the information.
I suppose they could take exception to using the image this way but hopefully they won't mind. If they do I'll just end up pulling it. Heres a sneak peak of the new splash screen.
We should see some more images of the concert hall project during the installation, looking forward to it!
The Yazdani Studio of Cannon Design is a laboratory for exploration and excellence in architecture. Established upon the reputation and leadership of award-winning designer Mehrdad Yazdani, the Yazdani Studio integrates the best attributes of a design studio with the resources and reach of an international practice.
I took the picture above during my visit to the Autodesk office in Waltham last week. It's a 3D print of a cut-away view of the model, if it isn't obvious enough. I couldn't create a link to the description of the project the way the Yazdani Studio has their site configured so here's a screen capture of the information.
Subscribe to:
Posts (Atom)