Sunday, June 15, 2008

Happy Father's Day

Good News: Kids made cards, pictures and breakfast.

Bad News: There is some obvious resemblance to the alien head from the previous post. ;)

Other News, Patrick Davis, Todd Williams and I are heading to Boston next week for the ADN conference. External applications certainly provide a competitive advantage (sometimes more perceived than real). I'm interested to know if there is a resolved boundary in the mind cloud of Autodesk with regard to what should be considered core functionality and what is better left resolved by others.

In particular: Massing. Massing was updated with the last release. But this is a far cry from being able to create emotive, intuitive or intentional forms without some significant end runs around existing functionality. So users must rely on other applications.

Inventor? Don't contort a tool meant to resolve manufacturing at a micro level into a tool meant to resolve architectural design intent at the macro level. And if you think that implementing Revit to a room full of designers is tough, try getting their heads around Inventor. They'll keep using Rhino. So the call to using Inventor is at best a suggestion. But not a solution.

And even Rhino isn't sufficent. While it may provide great, leveragible ACIS solids, Rhino alone doesn't contain the necessary functional ecosystem for post-rationalizing and resolving architectural form making within Revit.

Max? Great at 36,000 feet. So is SketchUp. Don't expect either to create Massings which can be leveraged in a meaningful way.

Maya?
Again - great for pretty pictures. But twisting a building out of a Maya model isn't practicable. See Rhino.

Why doesn't Revit contain the necessary geometric tools to resolve these forms? I've heard many arguments that tend to fall into a couple of categories. I'll talk about the one category of argument in this post.

Argument: "These types of forms are "edge conditions" which are infrequently used, or useful to designers."

I suppose the implication is that to take time and effort to overcome this type of form making isn't a good business investment for a software company from a market perception. And market perception may not necessarily be aligned with the customer perception. So who is the customer? The person buying stock or the person buying the solution that essentially gives the stock it's value?

I'll give you a hint: Take care if the stock in a company becomes more sought after than what that company produces.

Anyway - back on topic. On one hand, I'd agree that very few buildings require this type of macro approach to form making. On the other hand, is seems that every building contains edge conditions: fixtures, fittings, furnishings, lighting, equipment (to name just a few). It is frequently difficult to create adequately literal representations of these forms within Revit.

What we can create in the Family Editor is typically fine for 2D views and resolving documentation. But if part of the elegance of BIM is maintaining centralized information, then trying to leverage these elements to represent real-world elements in live, perspective, or rendered views becomes very difficult. But more importantly, I'd like to address this predisposition of what is an "edge condition" and what is not:

First - one user's edge condition may be very mundane form making to another.

Second - maintaining this "edge/non-edge condition" mentality becomes increasingly circular and self-fulfilling. You see, we refer to them as edge conditions because they're difficult to design and resolve with existing tools. But if we had the necessary tools to design and resolve them - they wouldn't remain edge conditions. ;)

Would there be a rush to create Hadid/Calatrava/Gehry-esque types of forms if these tools existed within the ecosystem of Revit? Not immediately. But designers often select a tool not only for what it does at present, but because of a tool's potential to evolve and surpass present expectations. Likewise, we become architects not only because of what we expect to do, but also because of what we aspire to do.

It's been nearly 9 years since the release of Revit. We know what it can and can't do elegantly. Many would like to see it develop beyond our expectations. And limitations.

3 comments:

Anonymous said...

You're thinking too much about the freeform problem. 3 reasons it hasn't happened.

1.. Performance, borderline now, freeform would kill it . Relationships the change engine would be maintaining aren't going to be simple.

2.. HTF do you wire up the change engine to the meaningful complex relationships defined by the designer? This might be part of the reason a certain Bentley person was nicked.

3.. It will never happen in RAC. Anyone who thinks Autodesk see Revit as RAC/STR/MEP is dreaming. It will either be RFree or an addon to Alias etc.

Good luck with ADN. It will be interesting to hear what they DON'T say more than what they do say. It will kill Revit if they see 3rd party apps filling functionality voids. What's needed is better intelligent abstraction.

Phil Read said...

I think you're correct Guy - the relationships would be complex. And they may not be parametrically defined by the model - but through other external definitions.

For example, complex geometric structural organizations are often better defined elsewhere, an placed via scripting. Attempting to place them manually, in a traditional two-click operation is simply not time/cost effective.

brad said...

I'll be damned, thanks for the post Phil.

1. The change engine isn't useful, kill it, implement ubiquitous tools, let the Architect define the relatinships.

It's the game of Architecture vs architecture, Craft vs commodity. When Architecture=architecture=commodity; we lose.