Related Posts with Thumbnails

« Fix Fit Finish | Main | Keyboard Shortcuts »

June 09, 2009

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

1. Correct assumption - we need the section representation. I've never seen a span direction symbol on an architectural floor plan.
2. I always show the deck direction correctly

Ditto Rick

1 - We need to be able to show the span direction; if we have to, we'll create a dumb symbol and place it manually.

2 - We never show deck profiles incorrectly, unless we've made a mistake.

Keep in mind that many architects actually do structural drawings; thus we need all the tools to not only create, but to document. It is not unusual for us to generate structural drawings.

So it sounds like AE firms need to be able to place the span direction symbol yet placing the plan symbol all the time would be less optimal for the primary Architecture use case which is the better section representation.

Glad to hear the desire is to show the deck correctly. I feel this is a tenet of Revit.

Object creation and behaviour should be consistent across disciplines. Many small practices do architecture and engineering in-house. Why should they have to buy two seats of Revit just so they can draw metal decks properly? Implement the full feature set in both packages and let the *user* choose how to display the object in the drawing.

As long as I can control the deck direction some way, I don't need to show the span direction on my drawings.

However, I do want to show the deck in sections (correctly). Of course, I already do this manually.

Thanks.

I agree with x-p - keep your code base consistent and let the user choose how deep they want to go. Direction must be accurate for us as well.

This would have been wonderful on the project just completed and would have helped coordination a lot.

The general question of why there are 3 Revit packages is still the big one for me... why is marketing doing this to us? We need all the tools - used to varying degrees on different projects, of course. But as an architect, in early design phase I am thinking of structure and designing in duct paths where they are critical, and I need the tools to make the design easy and capture the intent to pass on to others as they come on board the project.

PLEASE make it easy for us!

I agree with much of the above. For small jobs, structural floorplans and foundations are often part of the architectural drawing. And so is sewage layout. As for sections, correct metal-decking (and other prefab combination floors) would gratly improve coordination.

Erik,

It's nice to see that after many years of begging for the Structural Tools to be implemented in Revit Architecture, that the Revit team is finally listening to us. Please, listen to us and implement these tools. Don't let us down.

I would like to echo the words of Joel Osburn's post. His post is exactly how our firm feels.


1 - We need to be able to show the span direction. I would prefer to have a "smart" annotation symbol that would accurately reflect the span direction. This way if we change the span direction, Revit will automatically update. This is how Revit should behave.

2 - We must be able to show deck profiles accurately. We don't need to have mistakes in our drawings.

We do all of our own Structural drawings and then later have them reviewed by a Structural Engineer. Therfore it is imperative that we be able to have access to these tools for the creation and documentation of the Structural systems.

I'm hoping that the Revit team will listen to us and implement these tools soon.

Howard

Architecturally, we show the deck correctly in Section, but don't need to label it in Plan.

Erik,

Emphatic YES we need this feature enabled in RAC. Less important to identify the span as a tagging operation but acceptable if required to make the feature work. It has been my experience that most will show the deck according to true orientation, thus deck profile in section and deck "edge" in parallel views, assuming the deck is cut.

Absolutely this is needed! Thank you so much for looking at this, I REALLY hope that it gets implemented.

As for the answer to your question, I do need a way to control the span direction, but have never needed to tag it in a plan. I know that some do A & E and would need it, but I never have personally and wouldn't want it to tag by default.

We also always show our deck cuts correctly (unless we make a mistake of course).

Thank you all for the confirmation. I agree that the tools should be consistent in behavior as well as consistently available. Here I am just confirming the Architecture requirements as these were implemented for Structure only and this created small quirks such as the span direction being the only way to control the direction. Typically this would be controlled via a parameter or control. The span direction symbol could hook up to this parameter but is not required much like a ceiling tag can control the ceiling height.

Ditto Rick and Joel O.

Here's a novel idea: Why not share features between versions of Revit? If it works in one and you've already coded it, just copy-paste it into Arch. it would be great to make spaces and do zoning too.

We need correct sections and tagging. Why does/would Autodesk prevent tagging of certain features when/if the functionality were/is present? A prime example of this dichotomy is Beam Systems.

Architects and Designers need all the modeling and tagging tools available in the other two verticals. Analysis is a different animal, and I can [somewhat] understand the diversification of that arena. But I signed on [over 9 years ago] for Revit Building, not three or more verticals.

Ahh finally.

It will be much easier to co-ordinate with firms now rather then relying on all sorts of crazy methods to copy items (beams & trusses) and fix them up. As I'm from both sides of the fence I can tell you this is a welcomed move. As has been iterated many times, the only real difference should be the analytical and engineering specific tools.

1. I agree keep the methodology the same across the platforms. If an Architect doesn't need to show it then they can always hide or delete the tag anyway thats all it is.

2. I would rather this be true, if people want to draw incorrect details then let them do it the hard way. Revit is about true representation of buildings, not doing the dodge. Also a 3D button to turn on and off (activate the 2D vs 3D representation would great for this feature also.

I understand that this article is trying to gather information for building on top of existing Structure features for architectural purposes, but I still want to take the time to mention that you shouldn't try to qualify at a finer level which parts of the Structure tools Architecture should get.
You already tried to do this in the first place, but at a much larger granularity, and was met with harsh criticism. Don't try and do it again.

If a user is trying to go that extra step in documenting some engineering tasks, then it stands to reason that the user is either; qualified as an engineer, has some kind of engineering background, or works with an engineer.
So it could be said that the user changes hats from architect to engineer.

Do *not* try and make architectural equivalents of the already existing engineering tools. Don't waste time programming similar tools, when tools already exist. Just take out the appropriate analysis portions/parameters, and activate them.


To answer the Q's;
1. Absolutely architects are interested in span direction, either at an architectural or structural level of documentation. By all means create extra architectural annotation content, but only as long as it doesn't diminish the architects ability to document an engineering document in the same manner as in Structure.

BTW, don't stop at engineering 'modeling' capabilities. The need to model/document a finer level of detail such as Rebar is as equally important in Architecture.

2. Always modelled/documented as it's constructed.


I am in agreeance with Steve Faust, in that tagging should not be default for 'Structure' objects. As part of the process, the engineering documentation comes later in the project, therefore you wouldn't want the architectural design/documentation being littered with such annotation.

I appreciate that this is *finally* getting some attention, but don't spend too much time with respect to deciding who gets what again.

A simple rule of thumb:
*All* verticals to have *all* modelling and documenting tools, but hold back the analysis portions respectively for each vertical.

Don't try and play god by deciding who gets access to what.

Not trying to play God or spend inordinate amounts of time. When you state "You" I assume you don't mean me personally. I am only trying to ensure that default behavior makes sense for the majority use cases. Default tagging is the best example. Aside from this I agree that the features should be consistent in capability. I can't think of existing examples where like tools have been duplicated.

Sorry, by "You" I mean The Factory.

As far as I know, no duplicate tools currently exist. I just don't want to see engineering tools duplicated and 'dumbed down' to suit architecture.

No worries. I think we are very much on the same page.

1-Yes, The symbol is not desired as long as there is a way to control direction.

2-No change required, the correct view of the model is desired.

I beleive the important point to hit on here is that the annotation symbol should not be the only means by which the direction of deck is controlled. Obviously to keep things moving the Revit Structure team made a specific decision to not maintain the "structure" of Revit where tags report information that is already accessible elsewhere.

Large A firms like mine would never, ever want to show metal deck direction, but as has already been identified we would want the correct display of deck in section. Furthermore, being required to use an annotation symbol will increase the likelihood of mistakes or errors on our documents.

Smaller A firms, contractors, tract builders and the like most definitely do need that annotation symbol.

Bring the functionality in line with other Revit functionality, and make the behavior available in Revit Arch.

I agree with what everyone else has been saying. It would be great if Revit had all the tools or modules from which we could choose.
1. Our architects need the deck representation in sections but not the span direction symbol. However, we often have engineers work in the same file who would then need to add the span direction symbol on structural plans.
2. We always show the deck orientation correctly in sections.

Thanks for hearing our cries...

1.) Span direction symbology not needed for documentation, but a control to adjust would be necessary.

2.) Always drawn correctly in section. Pebcak otherwise.

1. I don't necessarily need span direction symbology for documention as a default.

2. But, I absolutely want to be able to control it in section to show it correctly (esp. for coordination purposes...)

Thank you for seeking our input.

Plan symbology for Architectural documentaiton is typically not required. However, due to the typical workflow (architect flushes out a preliminary system with Engineer's input and later Engineers take "ownership" of structural systems), the tools needs to be compatible between disciplines. So for example if the Architect lays out a preliminary structure and deck direction, the Engineer can later copy & paste this data into their project and the Architect would then take it out of their model (or through the use of enhanced copy/monitor methodology perhaps). So I guess you need to focus on making it easy to change deck direction without forcing the Architectural user to have to turn off a bunch of "structural stuff" that is essential to perform this operation. Perhaps through controls that show up when the object itself is selected (ex: the wall & door flip arrows are a good analogy). This would be better than having to rely solely on tags to drive geometry. Also perhaps certain tags should display based on discipline. That would make 'cleaning up" much easier so that in Arch. views, span symbols don't show up.

Yes. The current implementation lacks a control or a parameter for that matter. Ideally deck would have a control and the tag would be optional much like other areas in the product as you note. There could even be a make permanent option like temp dims that could create a tag instance. The span tag may be required for all disciplines until this is enhanced as it is the only way to control the direction.
The discipline idea is interesting. Current discipline specific view management is a whole other topic.

http://architechure.blogspot.com/2009/06/nein-nein-nein-nein-nein-nein-nein.html

OK. Is Phil correct? Is the 2009 interface still in or not?

I would really like a straight answer. I'm sure the SEC would as well.

I honestly can't believe we are even having this conversation. This is so NOT Revit. Wake up Autodesk!

I would love to hear the rationalizations regarding why some features are left out of Revit Architecture. Trusses, for instance. From this end it seems to make little sense. What we end up thinking is that Autodesk is leaving out stuff in an effort to get us to buy another version of Revit. I suppose that would be a good enough reason from the Autodesk end of things, but from this end it seems petty.

We've devolved here, but I think that it reflects a general discontent at not having a way to express frustrations to Autodesk. Thus this blog is attracting that some of that discontent, providing a place to express it to actual Autodesk employees.

There is no doubt in my mind that the segmentation of Revit has slowed its uptake. I know that's preposterous to the Autodesk marketing folks who created the separation, especially given the massive growth in Revit users and sales, but I am certain that the growth could have been faster. And future growth still can be.

My best tool to get one of our consultants to buy Revit is to have modeled their traditional work, and then to show them what they missed in a coordination meeting, live, in the model. We have only done this twice, once each for mechanical and structural engineers. Then our thirty day trials ran out, and we can no longer do it. But those instances both resulted in sales. The anecdotal proddings don't help nearly as much as a first hand exposure that directly relates to their performance.

The Autodesk marketing folks surely don't understand that architects are licensed to do it all themselves, and the fact that many or even most choose to hire specialists is in no way an indication that they never have a need for those tools themselves.

The fact that I still cannot make a slanted column, but my structural engineer can, is a slap in my face. But then I always thought that having both "architectural" and "structural" columns was insulting. There is a need for generic columns, just like with walls, but the dumbing down was unnecessary, as was having separate tools when different types would work just as well and be more consistent.

The feeling expressed here are understandable. For this blog I won't censor but would like to keep on topic - focus on design. The confirmation of requirements and approaches are valuable. This is just one of many blogs maintained by employees but has come to attract more general comments due to it being used on occasion as a messaging vehicle. In the top of this post I provided a link that is really the best way to provide direct feedback about marketing and product direction. Messages sent there are being read.

Thanks Erik. Email and the submitting a CSR both feel like the effort is wasted; you can never tell if it just goes into the bit bucket or if it is read. Automated responses reinforce this perception, as does the currently slow uptake of customer requested improvements (for example the AUGI wishlist). Here's hoping for a better future, though!

Just a word of warning here about this functionality. I use RS 2009/2010 and the profile representation of the deck breaks down if a void is formed on the surface of the slab ie. recess. Still awaiting the factory response for this bug...

I'll look into this to ensure the issue is properly recorded and looked at by proper individuals. There are known limitations such as behavior on shape edited slabs.
Thanks

I agree with 'all of the above'

Its so frustrating at times to see obvious functionality within RSE that has been dismissed from Revit Architecture. We (as in Arch) will normally be a long way ahead in the design process in terms of the model and will seek advice from the egineers only. We will then take on baord their advice within our Arch Model and will show decking in sections etc, and yes the correct orientation as well although we may not need the tag by default in our views.

Also - may I be so daring as to say we also need to draw Curved Beams. Could never quite understand this functionality miss from Architecure when we provide the 'design intent' to the engineers.

The comments to this entry are closed.

RSS

  • Subscribe