stressfree - cad

Autodesk Dragonfly emerges from its larvae

David — Fri, 13 Mar 2009 03:20:37 +0000

Project Dragonfly is an Autodesk Labs technology preview of a web-based, simple to use architectural planning tool. It represents a step towards a future where CAD and BIM model editors are not considered bloated, complex, or desktop-bound. Whilst the current functionality of the tool is limited, it is technically impressive, and the underlying concept hints that Autodesk’s broader web strategy (as discussed in ‘Autodesk Beyond Desktop CAD & BIM’) is proceeding at a slow, but steady pace.

An example of the 3D visualisation capabilities of Dragonfly (click to enlarge)

Dragonfly in flight

Dragonfly runs on any operating system that has a web browser which supports the latest Flash plug-in, for example Windows, OSX or Linux. Designing a floor plan primarily takes place within a constrained 2-dimensional space, but limited 3-dimensional views are available. In a nod towards its Autodesk lineage the toolbar and view controls aesthetically mimic those found in AutoCAD and Autodesk Design Review. As a result the tools are intuitive to use, but slightly limiting for those used to the responsiveness and flexibility of a desktop application. For a web-based tool in its infancy this is unsurprising, and there are certainly no fears (yet) that Autodesk is cannibalizing Revit or AutoCAD sales. However there are very strong signs that with continued development a unique and compelling product will evolve.

At Dragonfly’s core is a Flash-based model editor that enables users to manipulate architectural elements using traditional mouse gestures. In practice this editing process works best when in the 2D viewing mode, but moving of some objects whilst in the 3D view is possible. The graphic performance when making modifications is not up to par with a CAD or BIM desktop application, but for simple tasks it works quite well. What is impressive is the use of visual dimensioning aids to help quickly position elements in their correct location. Although not as powerful as the coordinate-based positioning systems used in most desktop CAD tools, for general layout it does the job admirably.

The dimensioning aids that help size elements (click to enlarge)

Beyond basic modeling the most visually appealing aspect of Dragonfly is its library of architectural furnishings and surfaces. Each element in the library has a detailed 2D and 3D representation that adds a level of scale to an otherwise blank canvas. At the moment this library is small, but there is enough there to get an idea of its versatility, and given time this will undoubtedly grow. Like the modeling tools, library components can be dragged and dropped into place and rotated to suit the designer’s needs. An issue at the moment is that once a component is placed there does not seem to be a way of displaying its name or meta-data information. From the perspective of layout design this would be useful as it would enable details such as the exact shower model and cost to be recorded.

Learning to fly: Where Dragonfly can improve

Whilst a promising initial release, a lot of development needs to take place before Dragonfly can transition from interesting preview to productive tool. Online collaboration is a key area where the Web-based Dragonfly holds a huge advantage over contemporary CAD/BIM modeling tools. Whilst further development of the modeling toolset is needed, being able to save designs as traditional 2D and 3D files is also critical for adoption. Finally expanding the component library through integration with the Seek product index would seem an obvious evolutionary step for both services.

Collaboration is key

The greatest development and deployment advantage a tool like Dragonfly has is that was conceived and built with the Web in mind. In contrast most desktop-based CAD/BIM tools use a file-based paradigm which cannot fully leverage the collaboration possibilities of the Internet. As a result sharing or collaboratively working on a design with Dragonfly is made very simple because the data and the tools are online. Unfortunately the current collaboration feature-set is limited to either exchanging an email link, or exhibiting the design within the public gallery. Whilst both are useful options, this is just the tip of a functional iceberg when it comes to professional architectural collaboration possibilities. Arguably the “holy grail” would be the inclusion of a multi-user, concurrent editing mode like that found in many Flash-based white-boarding tools. But even if technically infeasible, adding configurable read/write privileges and groups functionality would substantially increase Dragonfly’s value.

Exporting the layout for further development

The obvious market for a web-based architectural layout tool would seem to be in pre-design where clients are able to explore ideas by themselves. Once they have something they are happy with they need to be able to share it with their architect in a way that can promote further development. The first step in this process would be the ability to export scale 2D drawings in both DWF and PDF formats for printing and discussing over coffee. Architects should then be able to export the 3D model as a DWG so that more complex designs can be created within AutoCAD or Sketchup. Whilst this would probably not be used as the basis for production drawings, as far as visual exploration goes it would make an ideal starting point.

Growing the component library with Seek

An architectural layout tool is only as good as its component libraries, thus integration with Autodesk Seek would make Dragonfly very compelling. Seek is Autodesk’s product search index which contains a broad range of product descriptions along with 2D and 3D models. Integration with the Seek service would be very challenging, but if it was executed well the result would be far greater than the sum of its parts. The benefit to Dragonfly is that users would instantly be able to access a vast catalogue of components which they could add to their layout. For Seek and its content providers Dragonfly integration would provide that next step in the procurement decision making process beyond search. i.e. I have a product that I am interested in, but how does it physically sit within the space I am designing?

Where will Dragonfly land?

Dragonfly is a great example of how powerful the web browser has become, but how will this materialise into a financially viable product offering? There would seem to be three markets; a value-add service for desktop software, an advertising platform, or an engine for third-party development.

Adding value to existing products

Microsoft refers to this as a Software + Services strategy where online tools are provided alongside desktop software to extend its functionality. In the case of Microsoft this is Office Live, but for Autodesk this could be a version of Dragonfly that allowed Revit models to be interacted with online. In the foreseeable future Dragonfly is never going to match Revit in functionality, but it could allow architects to collaborate on plans with clients. For example an architect could export multi-story office plans to Dragonfly so that clients could experiment with office fittings and layouts. Once determined the Revit model could be synchronised with Dragonfly so that detailed production drawings or light renderings could be produced.

Autodesk as an advertising platform

Dragonfly’s component library would be an excellent advertising vehicle for manufacturers of furniture, fittings and surfaces. It is becoming common for these manufacturers to invest in web-based visualisation tools in order for potential clients to see what they will get. Rather than developing these tools, Dragonfly could be licensed to suppliers and the component library tailored to their promotional needs. These customised visualisation engines would be embedded into websites around the world in a similar manner as YouTube’s video player. Potential customers would then be free to experiment with how products would look and integrate within their own home.

A Dragonfly API: Third-party application development

Dragonfly’s underlying 2D layout and 3D visualisation functionality is something that can be applied to other tasks beyond basic architectural layouts. Google Maps is a great example of an innovative, web-based engine that has spawned a vast market of third-party applications. The underlying Dragonfly engine could fulfill a similar role if the API was exposed and developers were able to layer on functionality and information. Third-party development could be simple as tools for calculating the tiles needed in a space, through to applications in non-architectural domains. What the killer application would be is impossible to say, but being able to leverage Dragonfly within other web applications would be very powerful.

The big picture: bringing Dragonfly, Seek & Showroom together

Dragonfly is a nice technology preview, but its real value will only be realised once all of Autodesk’s online initiatives are seamlessly linked together. What will be most impressive is when Showroom renderings can be produced from a Dragonfly model built using components sourced from Seek. Judging by the state of these three services this day may not be too far off, and once it arrives it will stand as a remarkable online milestone. In the space of ten years something that required dedicated computer hardware and expensive software will be possible from anywhere for free. This will result in significant business model changes and the increased use of architectural modeling and rendering tools by the public.

An example rendering from Project Showroom (click to enlarge)

An unexplored opportunity: consolidating a user’s Autodesk identity

As Autodesk’s web services grow your online identity will be instrumental in monitoring activity across these different applications. Beyond Labs, Autodesk has a lot of identity-centric services, such as discussion boards, license management and an online university. As these elements coalesce it is important that Autodesk make it easy for users to manage their online identity and the information related to it. The most basic step being to ensure each online application uses the same single sign-on (SSO) service in order to create a consistent experience.

Beyond basic plumbing, a user “portal” is required that stitches together the latest news and collaboration updates from all these sources. For example as Dragonfly or Seek content is shared with others there is a need for a central location where this can be managed and monitored. A significant opportunity Autodesk has in this regard is that the majority of their online customers use their desktop software on a daily basis. Integrating online profiles within these desktop tools would add value to the customer, and promote the use of its new online services. It would also mean that no matter what Autodesk application was open, a user’s shared content and their collaboration connections would be available.

Conclusion

Project Dragonfly is a promising release that offers a glimpse into a future where CAD and BIM tools are not the exclusive domain of architects. Assuming development continues and the tool is integrated with other Labs services the end product will break a great deal of online ground. Unfortunately at this time until its collaboration and export options mature, early adopters will struggle to find productive uses for Dragonfly. Still as a technology demonstrator Dragonfly performs admirably and provides a promising glimpse into the future.

Autodesk Beyond Desktop CAD & BIM

David — Thu, 21 Aug 2008 12:30:52 +0000

or: How they Stopped Worrying and Learned to Love the Internet

It is my opinion that Autodesk is in the early stages of implementing a bold Internet-centric strategy that if successful will position it as the Software + Services giant within the Architecture, Engineering and Construction (AEC) industry. Excluding the spin-off and re-purchase of Buzzsaw during the Dot-com bubble one could say Autodesk's attitude towards the Web, like the rest of the AEC industry, has been tepid at the best. In a similar manner to Microsoft, the historical and financial foundations of Autodesk lie in the traditional, desktop software market. Here its catalogue of heavy-weight tools compete for domination of the competitive CAD, BIM, animation and rendering markets. Unlike Microsoft vs Google, Autodesk and its competitors (such as Bentley Systems) have yet to face serious competition from an Internet savvy, AEC software heavy-weight. Rather than waiting for such a competitor to emerge Mike Haley, Jeff Wright and the rest of Autodesk's Content division are building it 'in-house'.

The goal: building really big 3D models in the cloud

AEC software vendors have largely ignored the Internet and have been content to focus on what can be done on a single workstation. The problem is that simultaneously other industries have demonstrated what is possible on the network, for example virtual worlds and photo-realistic visual experiences. Hence as our expectations have grown we are finding a single workstation cannot hope to keep up with these perpetually increasing processing demands. Consequently at some point the AEC software industry must make the step from tried and true desktop CAD/BIM to the less understood, but potentially more capable platform now referred to as cloud computing.

But why are really big, 3D models important in the eyes of industry professionals and public? The answer is simple, architecture is not mass production and the first time a design gets built is generally the last. From the perspective of understanding the design and its issues this is not ideal as the shift from the abstract to real world almost never happens painlessly. Not only is there design problems, for example 'does the detailing of the design match the overall aesthetic and its surroundings?', but there are also performance questions such as 'what are the temperature and light qualities like in the lounge in late winter when the sun goes behind the building across the road?'. The ability to digitally realise the entire design - from the exact detailing of its window frames to its geographic context, enables those involved to 'virtually' build and experience the architecture in a very cost effective manner.

At this point many will be thinking, isn't this what I do in Revit, Microstation or ArchiCAD every day? The answer is yes, but on a scale that is almost impossible to fathom. At this level it is not just about what you as a single person can record about a model, but rather the bringing together of vast quantities of data from multiple sources in order for it to be experienced in one place and time.

An outsiders overview of the strategy

Whilst I have recently spoken with Mike Haley and Abhi Singh from Autodesk about Seek and their evolving Internet strategy, what follows is primarily my own summary of the bigger picture drawn from the thoughts of some of those involved. Expect to hear and see more definitive things from Autodesk during the course of the year, especially at December's Autodesk Univserity.

Note: Buzzsaw is not included in this discussion as it is a closed tool that is not widely available on the Internet (i.e. it conforms to the classical notion of the closed, corporate Intranet).

Autodesk's Internet strategy is driven by the Content division within Autodesk. The goal of the strategy is to harness the potential of Internet-centric infrastructure to scale beyond that considered possible on the desktop or traditional corporate network. With the efficient scaling of digital infrastructure comes the ability to push the boundaries of the digital model - not only in its scope and depth of detail, but also in the designer's ability to simulate its properties.

The infrastructure for achieving this goal has been broken down into four distinct functional components as illustrated by the diagram below.

Whilst each functional component is at a different stage of development, aspects of each have been demonstrated to the public in some way, shape or form:

Seek - Product and material index: http://seek.autodesk.com/
Dragonfly - Web-centric modelling: http://labs.autodesk.com/technologies/draw/
Showroom - Render-wall service: http://labs.autodesk.com/technologies/showroom/
Metropolis - Massive 3D environment space: Autodesk University demo video

Individually these projects break a little new ground, but when viewed as an integrated suite of cloud-based services their true potential becomes apparent. Together the four services form a platform that if successfully implemented, may revolutionise the way AEC professionals conceive, produce and experience digital models.

Seek

Seek is a sophisticated data conduit for architectural information. I have covered Seek previously and Mike Haley has an even better video presentation. The intention behind Seek is to build an index of architectural details and materials, their associated meta-data and any digital files which maybe associated to them (e.g. DWG and PDF files). Unlike a supplier-centric materials index, Seek's primary motive is to facilitate information sharing amongst architectural suppliers and professionals. The intention is that this data-store can be leveraged to help construct more precise 3D models, add richness to renderings and provide material performance data for thermal simulations.

Metropolis

Metropolis is the bridging of virtual world concepts (a.k.a Google Earth) and serious 3D modelling. Rather than focusing on the macro OR the micro the emphasis of Metropolis is to create a virtual space capable of handling everything from the planet down to a pencil. The challenge this project is attempting to overcome is how to efficiently retrieve and process massive amounts of 3D data. Whilst the technical barriers are huge, if they can be surmounted being able to quickly visualise fully furnished, architectural designs within their actual geographic context is a real possibility.

Dragonfly

Dragonfly is attempting to bring CAD concepts to the cloud computing environment. The intention of Dragonfly is not to recreate AutoCAD or Revit within the Internet browser, but to leverage this ubiquitous platform to deliver and manipulate 3D content. For example smart-phones ship with Web browsers capable of displaying rich content (i.e. images and Flash). Along another line is the growth of browser-based, virtual worlds such as Google's Lively. Whilst these technologies are currently in their infancy, it is fairly obvious that they will mature into a very capable platforms for interactive 3D experiences.

Showroom

Showroom is photo-realistic cloud rendering made available to consumers. The concept of render-farms is certainly not new, but making the technology easily available to the general public is. The current technology preview illustrates how Showroom can efficiently render dynamic, photo-realistic scenes 'on-demand'. Conventionally this processor intensive work has been conducted on a desktop computer, tying up CPU cycles and requiring installation and maintenance of complicated rendering software. By moving this task into Showroom not only are CPU cycles freed but the software and materials libraries used can be far more sophisticated. The end result is that cloud-based rendering may prove to be faster and of a higher quality compared to its desktop counterpart.

Why the need for change?

Autodesk is a financially profitable company that dominates many of the software sectors it competes in. Why is there a need to branch out into cloud-based computing, especially when success of these initiatives may in the long-term harm their conventional, desktop business?

Moore's Law can't keep up when it comes to 3D

Nothing has reinforced the limitations of working with 3D data on a desktop computer more than my time spent teaching CAD and rendering to architecture students. Experienced digital modellers gain a subconscious understanding of the processing limitations of their desktop computer. However, like children learning about gravity the hard way, those starting out with 3D do not have the same appreciation for these boundaries. Consequently the most challenging part about teaching students how to create effective 3D models and renderings is not the creation of geometric data, it is getting them to stop. The problem is once introduced to the concept of CAD, (or more recently BIM) students have an uncontrollable urge to model every screw and light-fitting. No matter whether this was five years ago on a Pentium 3 or today with a Core2 Duo, students will do their best to overload the available hardware through simple, blissful ignorance.

"Google is like lots of PhDs driving tanks. It is all about brute force - everyone is General Patton. They don't drive around the wall, they drive through the wall. It is dumb techniques used in large scale."

Adam Bosworth
Database Requirements in the Age of Scalable Services (13:04-13:18)
MySQL Users Conference 2005

Google Earth was the first mainstream demonstration of the power of integrating a vast online 2D/3D data-store with the interactivity of a rich client interface. However as far as processing went it is very simple. Digitally representing the Earth down to the individual building is made possible because the only data downloaded and rendered by the client is what can be 'seen' on-screen. This is fine for basic, macro-level visualisation but it does not work for a richly detailed Building Information Model (BIM). In this environment AEC professionals need the ability to digitally represent all aspects of the design - from its 3D properties down to the thermal characteristics of the materials. To make effective design decisions this potentially infinite data-set needs to be right at hand. As a result the challenge facing Autodesk is not just to store the underlying data in the cloud, but also the entire, 3-dimensionally realised model so that it can be efficiently navigated, manipulated and simulated.

Breaking existing vendor relationships with on-demand services

Unlike traditional desktop software an online offering will allow Autodesk to compete head-to-head on competing vendors 'home turf'. Currently the AEC sector is a patchwork of companies each committed to a particular CAD/BIM software vendor. This is primarily due to the licensing and training costs associated with this business critical functionality, but the vendors do their bit by making their products 'more compatible' with their own offerings. If deployed in an open and ubiquitous manner, Autodesk's Internet strategy could overcome these business firewalls by enabling Autodesk-centric functionality to be embedded into competing products. For example consider the following scenario:

John is developing a building model in Microstation, his architecture practice's primary BIM tool. He likes the work-group capabilities of Microstation but wishes that it had better tools for demonstrating to the client what the building will look like in its urban context. On a whim (and without "I.T's" approval) he signs up for an Autodesk.com account and installs the Microstation plug-in so that his model can be loaded into a very large Metropolis model of the city. He then emails the client with a link to a Dragonfly web-viewer that lets them see his building design within the context of the city within their Internet browser. They are really impressed and ask if they could see some renderings of the building from the street at different times on day. As the model is already in Metropolis he takes the plunge and requests some Showroom renders using the most trusted material definitions found on Seek. He is told that the renderings will take some time to complete so he goes back to working on his Microstation model. Within minutes he receives an email from Showroom to say that his renderings are ready. The quality of the results are more than enough to impress the clients, but the practice's part-time renderer/animation guru says he could have done better if there was the budget to upgrade to the latest version of his rendering software (and a faster computer). Overall John is more than pleased with the result, especially considering instead of a large upfront expense his account was billed as he chose to use the services on offer. He could see that even though the practice was not going to migrate from Microstation anytime soon, they were going to use Autodesk's online services more often in the future.

Reaching new customers and markets

After twenty-odd years of fierce competition in the CAD software space the battle-lines are fairly well defined. The Google Earth/SketchUp combination has demonstrated there are vast, untapped reserves of potential customers for 3D tools in unconventional sectors, developing economies and the casual market. Unfortunately trying to sell $1000-$5000 software to people who do not recognise the value, cannot afford the license fees or do not want to pay is an impossible mission. Cloud-based computing can potentially overcome these barriers through its ability to scale and be delivered to users at low cost.

The proven results of this cloud-centric strategy can be seen in the success of Google and SalesForce.com. Both companies have been able to enter markets previously inaccessible to traditional vendors, and simultaneously undermine the position of the well-entrenched competitors in existing, developed markets.

For example:

Google's online advertising (AdWords) gives anyone the ability to advertise and undermined the position (and cost structure) of conventional advertisers.
SalesForce.com uses a Software as a Service (SaaS) model to deliver feature-rich Customer Relationship Management (CRM) services to a broader audience and at considerably lower costs than traditional alternatives.
Google Apps is providing a suite of business services to educators, non-profits and small-businesses at zero cost whilst undermining the unquestioned dominance of Microsoft's Exchange/Office suite in larger corporations.

Autodesk the Software + Services company

A business strategy that includes online services diversifies Autodesk's income stream and protects it from any downturn in its traditional product offerings. The ability to sell additional services to users enables the up-front cost of the software to be lowered on the assumption that lost income will be recouped over the life cycle of the product. This provides a competitive edge over software vendors who's sole income is from the software's initial sale. This lower up-front cost in turn helps make the desktop software more palatable to a broader audience.

This "shavers and razors" approach is certainly not a new business strategy, but it has not yet been exploited within the AEC software industry. It would not be unreasonable to suggest that if Autodesk's Software + Services strategy were to successfully mature, high cost items such as Revit could be sold at a significantly lower rate (currently a Revit subscription is US$725 per year, per user). The mobile phone market uses this model to great effect, so much so that even Apple have adopted it in order to ship more iPhones.

An observation on ubiquity: The part of most value in a 'stack' rises as the components below become ubiquitous

Ubiquity is a powerful yet dangerous asset for a business. Ubiquity drives adoption and product sales which leads to healthy profits. On the other hand ubiquity results in imitation and a stifling of innovation due to the momentum of legacy. Reaping the rewards of ubiquity is the goal of any software company, but escaping its pitfalls is a harder and often undervalued proposition.

"..nobody who was an ice harvester became an ice factory, and nobody who was an ice factory became a refrigerator company, and nobody who is a refrigerator company is investing in biotechnology. Because most people stay on the same curve. Better saw... more horses.... bigger ice factory... more colours of refrigerator.

Very few people have the courage or vision to get to the next curve."

Guy Kawasaki
The Art of Innovation (17:25-17:55)
MySQL Users Conference 2007

Autodesk illustrated great foresight in its acquisition of Revit on the cusp of the Building Information Model's 'tipping point'. The purchase was also timely because it preempted the demise of AutoCAD as their venerable "cash cow". We can confidently state that AutoCAD is on the way out for three reasons:

Competition: There are now many low-cost and free alternatives on the market that do an excellent job of 3D CAD. Thanks to OpenDWG these competitors can read and write AutoCAD files.
Lawsuits: Any company that needs to resort to suing the competition to maintain an edge in the market is destined to loose out in the long-term.
Ribbons: The introduction of a 'ribbon' interface as the primary feature for any software release is a clear sign that its designers are clean out of useful functionality to add which justifies the upgrade cost.

Unfortunately for Autodesk nobody can be quite sure whether Revit will become ubiquitous, and if it does how long its time will last. This initiation of a bold Internet strategy acts as a safeguard to these uncertainties. Not only would a successful suite of Internet services reinforce Revit's hold on the BIM market, but it also allows Autodesk to "get to the next curve" before the competition.

Learning from and living on Amazon's cloud

Whilst it is early days yet, the thinking and implementation of this Internet strategy has no doubt been shaped by Amazon's suite of cloud computing web services. Not only are the services offered by Autodesk hosted on Amazon, but the manner by which functionality has been compartmentalised is very similar to Amazon's architecture.

The very existence of Amazon's services has enabled Autodesk's cloud-centric strategy to be launched with relatively little investment. Only a couple of years ago such a project would have required in-house development of a compute cluster. This expensive proposition becomes very difficult to justify when moving into uncharted business waters. In contrast, the flexibility offered by today's 'pay as you go' compute services from Amazon, Google and others enable clusters to be setup in a matter of minutes at extremely low cost ($0.10 per CPU hour on EC2). A significant and very attractive property of these rented compute clouds is their linear pricing model. This greatly simplifies business models for companies like Autodesk when choosing to build services because there is no cost penalty for success. In contrast choosing to build on a traditional infrastructure does not guarantee cost effective scale. This runs the risk of breaking the business model (operating at a loss) or failing to meet demand (momentum loss) as the service becomes popular.

It will be interesting to see how closely Autodesk follows Amazon's delivery model for these services. Currently the emphasis is on exposing functionality through Autodesk's own desktop and web products. However the opportunity exists to follow Amazon and publicly expose the underlying, low-level services to external developers via a set of for-pay web service APIs. Amazon followed this exact path in the release of their cloud-based web services stack, and what started off as an internal project soon flourished into a multi-million dollar industry. If things play out in a similar manner it is not unreasonable to suggest that one day the rendering engine of ArchiCAD could be Autodesk Showroom, or that Microstation models may happily co-exist next to legacy AutoCAD ones in a Metropolis cluster.

The effect of open source (or you can teach an old dog new tricks)

It is somewhat ironic that for Autodesk, an icon of the proprietary software world, the key enabler of this Internet strategy is open source software. Open source forms the backbone of the virtualisation technology (EC2 is based on Xen) and the host images that run on top of it (currently Linux and OpenSolaris). The freedom provided by the various open source licenses which make up this software stack enable its massive scale. This open source foundation is now beginning to extend beyond the virtualisation layer and is seeping into Autodesk's own programming practices. For example Seek is built on top of Java and makes use of many open source libraries such as Lucene and Spring. Whilst this is not a sign that a Linux version of AutoCAD will be released tomorrow, the acknowledgement by Autodesk that open source is a valid development model is a promising first step.

No plan survives contact with the enemy

Grand thoughts of a cloud-centric Autodesk are nice to postulate, but the reality is in the real world things are not so clear cut. In many ways the group behind this strategy is the Autodesk equivalent of Apple's Macintosh Pirates of 1983. Like the now infamous Macintosh developers, the group is small, intentionally isolated from the mothership and proposing products that may fundamentally shake up the tried and true business model (in this case desktop CAD/BIM). Whether or not such a promising start is allowed to blossom will not simply rest on the ability of the team to execute, but also the response they get from "old school" Autodesk and its competitors as this promising plan unfolds.

What will the "old schoolers" have to say about this?

For any online strategy to be successful it must be fully supported by the traditional software products offered by Autodesk. This goes well beyond the current (minor) integration that currently exists, to a point where venerable desktop products such as AutoCAD, Revit and Max are completely reshaped to take advantage of the possibilities on offer. Such an undertaking is not a simple task, especially when product managers have conventional feature requests to address and limited resources on hand.

Well beyond this practical matter is the degree to which a paradigm shifting Internet strategy can be successfully communicated within a software behemoth. For the Internet strategy put forward to take hold and flourish a significant portion of Autodesk's 7,000+ staff will need to comprehend and fully support the idea. Furthermore this clear sense of direction needs to come from the top and flow through the company in a similar manner to Bill Gates' 1995 'Tidal Wave' memo. This now infamous directive refocused all of Microsoft's software efforts to exploiting the Web's potential at a time where it could have been superseded by others. What is promising is that Autodesk's current CEO, Carl Bass, led the Buzzsaw team so he obviously understands the Internet and does not need to experience a Gates-like "eureka" moment.

Even if the concept is well communicated and Autodesk's desktop offerings are remodelled there is still the question of how internal divisions will react when their sales numbers are impacted by competing, cloud-centric products. For example taken to their ultimate (hypothetical) conclusions Showroom (rendering) and Dragonfly (modelling) will perform tasks well enough that for a subset, or even majority, of users the purchase of traditional desktop clients like Max and AutoCAD becomes unnecessary. Internal management structures within large companies are always fractured and at war with each other, so when this happens one of four things occur:

The new, competing product is terminated (the old guys win).
The new product is hamstrung or merged with a division that cannot manage it properly (the old guys win but the boss doesn't tell the new guys).
The existing product is put out to pasture (the new guys win).
The two products begin competing against each other and loose out to a third party (both guys loose).

There are many cases were internal competition over the same user-base has lead to conflict. Perhaps the most famous example brought to light recently was the 2001 internal struggle within Microsoft between Bill Gates and Steve Ballmer over the future of NetDocs, an Internet-based, Office competitor. The end result of this conflict was that NetDocs was unofficially cancelled, handing Google a lead in the online productivity market which Microsoft may never recover.

Concluding thoughts

Autodesk are making some bold moves when it comes to the Internet. Whether or not these initiatives will be allowed to mature and foster a healthy user-base is another matter. Time to market is crucial, not only will it preempt competition but it will also act as a very clear sign of the company's overall intentions. For the good of the industry we are all hoping that services like Seek, Showroom, Dragonfly, Metropolisis and their competitors flourish. Whilst picking a winner at this early stage is impossible, the mere fact that that CAD and BIM is about to make that 'one small step' from the desktop to the cloud can only lead much bigger (and hopefully better) things.

Upcoming Revit Technology Conference in Sydney

David — Mon, 26 May 2008 02:48:14 +0000

There is an upcoming Revit Technology Conference in Sydney in June. The venue looks very nice although I doubt June is the best time of the year to be hitting the beach, even in Sydney. The schedule covers just about every conceivable functional aspect of Revit. If you can't spare the time or money to attend Autodesk University then this is probably the closest thing you'll get in the southern hemisphere.

The SketchUp Show

David — Tue, 24 Jul 2007 22:14:02 +0000

If you are a current or potential user of Google SketchUp then I would recommend checking out the SketchUp Show. It is a regular video podcast that goes through how to use the various pieces of functionality avaiable in the free modeller. The production quality of the tutorials is very high and they go through at a pace that is easy to follow along with. Because these are video podcasts they are not small downloads (about 100meg each) so do not try attempting to download them via a dial-up connection unless you can wait a few days.

cad
sketchup

Internet enabling Generative Components for a new breed of AEC consultant

David — Mon, 11 Jun 2007 05:40:33 +0000

Generative Components, also known as Smart Geometry, is a technology for describing the underlying rule-set of a geometric form. Currently it is in its infancy but potential exists for it to become the basis of a new field of AEC consultancy centered around geometric exploration. Central to its success will be the ability for its proponents to utilise the Internet to improve its technical accessibility and enable consultants to deliver the benefits of Generative Components to any interested architecture practice no matter its size or geographic location.

Even though it is smarter, BIM is still dumb

Typical CAD or BIM modeling tools are relatively simple in nature because all the major design elements are systematically defined by the architect or drafts-person building the model. Unfortunately this process depends on the person creating the model having at least some idea of the intended outcome before undertaking the work. Also once the model is built the underlying geometric motivations behind it cannot be efficiently experimented with. Generative Components empowers the designer with the ability to almost effortlessly explore many different yet related iterations of the same concept in order to determine the strongest architectural response to the given situation.

Exploring the geometric motivations behind architectural form

Generative Components (GC) are a new breed of digital modeling methodology emerging to help architects meet complex design challenges and explore new architectural forms. GC allows the designer to programmatically define a conceptual rule-set which the software can use to automatically generate a geometric response. This is a significantly different approach compared to conventional digital modeling where the designer must manually instantiate each geometric element. The benefit of a GC approach is that instead of being drawn into the struggle of creating geometry the designer is free to focus on the underlying conceptual principles, leaving the arduous task of modeling to the software. This freedom enables more time for geometric experimentation which can potentially result in innovative and more efficient architectural responses to a problem.

But when does architecture become programming?

Unfortunately Generative Components are not, and will probably never be as easy as talking to the computer about a project's geometric ambitions. Instead each geometric intention must be clearly defined using logical expressions composed in a GC-specific language. This is very different to the visually inspired tool-set of lines, walls and windows which architects have grown comfortable using thanks to the conventional processes of architectural drawing and CAD. As a consequence it can be argued that someone developing a Generative Component shares more in common with a programmer using a software language than it does to an architect on a drawing board. This poses a problem for the widespread uptake of Generative Components because AEC professionals are generally unwilling to learn an entirely new and conceptually very different way of working in order to gain its benefits.

A typical Generative Components work session within Microstation (click to enlarge)

Whilst certain functional aspects of Generative Components will filter their way into conventional CAD and BIM packages for the most part this technology will remain out of reach to the majority of architectural designers. This usability limitation is not stopping larger architectural practices from establishing Generative Components teams dedicated to mastering the technology and applying it to problems faced within the organisation. Even in these environments financial justification is difficult given the high calibre of staff required, the cost of the software and the ongoing training necessary to remain competitive in Generative Components field. Matters are made worse by the fact that even in an optimistic scenario Generative Components can only be applied to perhaps 5% of 5% of projects, i.e. a very small proportion of a practice's income generating work. Currently this unfavorable cost/benefit analysis is justified due to the threat faced by competing practices and the ability to unflinchingly say to a client that nothing is too difficult. Even given this pressure there will come a time when the financial strain of maintaining an in-house Generative Components team will become too great for even the largest of architecture practices. At this point it would not seem unreasonable to suggest these organisations would look to third-party consultants to provide a cost-effective, on-demand GC capability.

Consultants in the industry

The AEC industry has a range of consulting arms associated with it depending on the type of project and its contractual structure. Consultants are generally involved in aspects of the project where the core participants expertise maybe lacking or in need of complimenting. This can occur at the design level with the involvement of environmental, services and fire engineers, right down to a technical level with the use of I.T. consultants to help meet Internet collaboration demands. No matter what the skill-set it is generally the case that consultants are employed because it is not economically feasible to retain or maintain these skills 'in-house'. Determining economic feasibility within an architectural practice generally comes down to a question of size. Large practices can afford to maintain a fairly broad skills-base to compliment their architects and draftsmen, but for a small practice the capability (or desire) to undertake the level of work needed to justify a broad skill-set does not exist.

The field of Generative Components would appear to be an ideal candidate for outsourcing to a consultancy due to its limited applicability to the majority of a practice's work and the relatively high costs associated with it. Being a small and developing technology it is a difficult proposition for a single architecture practice to efficiently maintain and utilise the skills necessary to gain the most benefit from Generative Components. Unfortunately clouding the decision around outsourcing or retaining an 'in-house' Generative Component capability is the questionable realisable value it has on the design process and the inderminate nature of its deliverables.

Establishing costs for Generative Component consultation

An enabling factor for most external consultation is the ability for the party doing the consulting to define a pricing structure around their involvement. For many this will comprise of a quote that mixes fix-priced deliverables, such as set of building simulations, with a best-guess estimate of the consulting time required to help the project team meet their required objectives. From the perspective of the project team establishing costs and timescales for contractors is critical because it justifies their involvement to the client and establishes metrics for gauging their performance. Establishing these metrics is currently a major barrier to external Generative Components consulting due to the vague working relationships and complicated deliverables which emerge from the current process.

An abstract but interesting example of the explorative capabilities of GC (click to enlarge)

The power of Generative Components is that they enable designers to experiment with the conceptual and geometric premises of their design. However due to the complexity of current GC processes for this to occur the most efficient working relationship is for an architectural designer to operate in partnership with a GC developer. The developer's role in this relationship is to efficiently translate the designer's architectural concepts into mathematically and programatically sound Generative Components. Unfortunately the GC outcomes from this process still require the ongoing input of the developer because the non-standard software used to create the model is not immediately accessible to the designer for experimentation. As a consequence of this lack of accessibility the relationship between designer and GC developer must be ongoing and relatively close. In fact one could argue to generate the most value in the design process the designer and GC developer would need to work together from the conception of a project to its design completion. This is a difficult undertaking because the actual value derived from such a relationship cannot be immediately realised or the costs easily justified to the client over the duration of the design process.

For Generative Components to be established as a viable consulting opportunity a methodology needs to evolve whereby a set of deliverables and estimated time involvement can be clearly defined and presented to the design team. For this to be achieved the GC developer must be decoupled from the design process and be able to deliver accessible GC objects which can be experimented with by the design team in their own time. This methodology change would minimise the cost of utilising Generative Components during the design process because its application would be clearly defined rather than the product of a fuzzy design/developer relationship. Delivering Generative Components in a medium that is cost-effective and immediately accessible to architectural designers would also increase its value throughout the entire industry as the process would be transformed from high-end toy to general purpose tool. Decoupling the designer/developer relationship would also enable the GC consultant to work simultaneously a number of projects from different firms, a critical factor when considering the technology's limited applicability to the overall work within a single practice and the high costs associated with maintaining GC proficiency.

An Internet architecture for enabling distributed and accessible GC interaction

Delivering this methodology change will require the development of a set of bridging technologies between the GC model and architectural designer. The most significant component in this bridging technology would be the development of a light-weight GC server capable of exposing parameter driven GC models to the outside world as traditional 3D models (i.e. a near real-time GC to DWG/DGN converter). The overall architecture of such a bridging mechanism is outlined in the diagram below.

An diagrammatic overview of the role of a GC server in delivering Generative Components in a more accessible manner to AEC professionals (click to enlarge)

Development of a Generative Component would occur as normal but rather than dealing with the model directly the designer would be presented with a user-friendly interface for exploring the possibilities of the GC object in a controlled, parameter driven environment. This interface could range from purely Web-based (i.e. Flash) to being integrated into the architect's CAD package via a plug-in. This client interface would use Web Services to send GC parameters to the server which in response would return the geometric GC outcome for displaying to the designer. Determining exactly which GC parameters to expose to the designer would be the role of the GC developer. Internet enabling GC development would improve the participants ability to undertake design exploration in a distributed environment. In fact the GC consultant could be based on the other side of the world, collaborating with the designer via text, voice or video conference technologies.

Depending on the contractual relationship the GC consultant could also use the quality and quantity of the geometric iterations as a pricing metric. For example rather than creating entirely new Generative Components for each client the consultant would be able to expose pre-made objects to designers on a cost-per access basis (e.g. $0.50 for a basic geometric iteration, $10.00 for a high-quality iteration). This would enable designers to independently and cost-effectively experiment with an existing library of GC parts using low-quality (draft) settings. Once they have something interesting it would then be a case of requesting a single, high-quality version from the GC consultant for actual use. A business model such as this would establish multiple income streams for the GC consultant and help entice architects into experimenting with Generative Components without having to commit to a full blown relationship with the GC consulting firm.

It all comes down to delivery

If Generative Components could be delivered to architects in a more accessible and decoupled manner it would not only establish the technology as a broadly applicable architectural tool but also facilitate a new breed of AEC consulting. As a technology Generative Components demonstrates a lot of promise but until it can be exposed to and utilised by the mainstream architectural audience its capability and potential will never be fully utilised. Internet-enabling the collaborative development and delivery process behind Generative Components will be instrumental in achieving this goal.

Following up on CAD Collaboration

David — Thu, 01 Mar 2007 10:21:41 +0000

I have had a fairly positive response to my last CAD Collaboration post. Feedback has highlighted a couple of areas that need clarifying and developing a little further.

On Snapshots and Deltas

Paul Wilkinson of the Extranet Evolution blog put up a fairly long post that discussed many aspects of the article. Of most interest was his comments on the snapshots and deltas idea, significantly the fact that a similar approach had been adopted three years ago by BIW Information Channel from BIW Technologies.

BIW’s Accelerated Transfer pack condenses file revisions to a fraction of their previous size allowing faster transfer – up to ten times faster in the case of some files.

In the case of BIW it used delta encoding as a means of increasing data transfer speeds to remote, poorly connected places such as construction sites. This is slightly different to the concept I proposed because it deals with binary deltas rather than deltas at an abstracted digital model level. Binary deltas are great at a file level because they do allow changes to the same file be transferred somewhere very quickly. The problem is that binary deltas are intended to convert a file to a carbon copy of the remote source file from top to bottom.

Using delta's in a collaborative digital model is all about exchanging design intentions (i.e. rotated wall A 45 degrees) so that the model is updated but many properties of the actual file remain the same. In many respects it is more complex process than a low-level delta courtesy of a tool like diff. However this added complexity provides the benefit of enabling users to choose what design intentions they wish to inherit from other team members without worrying about the associated digital baggage that accompanies their team member's file.

Paul also raised this interesting point:

But what we need, as a commercial software developer, is some customer demand to make such R&D activity commercially viable - as with BIM, there is no huge clamour (yet) from project teams for collaboration tools to support this way of working.

Supply and demand is an interesting thing. Posing to a group of people whether they want to adopt a certain way of working without a having that method productised and easily accessible will always result in negative feedback. Twenty years ago I doubt researchers would have received a positive response if they asked architects to adapt their processes to meet the needs of a hypothesised 'Building Information Model'. The fact of the matter is that it has taken compelling yet somewhat risky tools like Archicad and Revit to convince industry professionals that a BIM approach has significant advantages over conventional CAD. This change of heart has not come about because professionals have come to terms with what the concept of BIM. Instead most have been sold on the idea because the products available have shown themselves to be more efficient and flexible than alternatives. I think a snapshots and deltas approach has significant advantages which I have previously described, but it will take the availability of a compelling product before the majority of users exhibit any degree of interest.

So how does a Satellite approach work again?

A link to the article was posted on the VectorWorks forum thread which was provided the initial spark. It received the following comment:

It still remains a bit of a mystery to me how the "master/satellite" system is actually managed. I'm not aware that in writing to disk it is possible to write only selected portions of a file (I may be in error in this belief!).

In the updating process, does software on the server take master and satellite into one file, sort each object for permission and time stamp, then integrate into one file to overwrite the original?

At the heart of the satellite model is usually a permissions system that allows only one user to lock a selected area for editing. Other people are still able to view this area but for simplicities sake write privileges are usually kept to one person. Minimising write privileges negates the need to have a complex synchronisation process where one set changes are accepted or declined in place of another. It is certainly possible to write an application that deals with these issues of change authority but it is difficult to justify given its negative impact on application efficiency and ease of use.

Because of its simple permissions system synchronising a satellite is a simple task of overwriting the area assigned to the user within the master model with what is present in their satellite copy. Once this is complete the updated areas of the master not under the user's control are copied to the satellite. The process of updating the satellite can be as simple overwriting its entire contents with what exists in the master down to fine-grained synchronisation of new and updated elements.

It is perhaps easiest to think of the process like the children's game where each child is allowed to draw on a specific side of a folded-up piece of paper. The piece of paper is handed around each of the children in turn to draw on and after everyone has had a turn the unfolded end result is revealed (usually to much hilarity). The only significant process difference with a satellite approach is that instead of drawing on the same piece of paper copies are distributed for working on and collated into a master version at a set time.

Of course one thing to remember about a digital model is that its unique 'sides' do not have to be constrained by a physical space such as a kitchen. Instead these areas could be specific elements that occur throughout the model, for example 'all the windows on the second and third floors'.

Parallels update brings Windows CAD to the OSX desktop

David — Wed, 28 Feb 2007 08:24:20 +0000

Parallels released an update today for their Parallels Desktop for Mac virtualisation software which introduced 'coherence' mode and seriously improved video drivers capable of supporting DirectX. To give the new features a test drive I installed Autodesk Design Review, Revit 9.1 (trial version) and Bentley View on the virtual instance of Windows XP and had a play. All performed very well even with minimal RAM allocated for testing purposes. Quite possibly the only let down was that before you could start using the software the virtual machine first had to load Windows.

The screencast above illustrates the boot process, coherence mode, Design Review and Revit in action. The screencast was taken at a fairly low frame rate and YouTube just makes it all that worse. Please take my word for it that performance on a 1.83 Intel Core Duo iMac was fairly snappy even with only 256meg of RAM assigned to the VM. In a production environment you would certainly want to allocate at least 512meg of RAM to Parallels which would mean needing between 1.5/2gig of RAM in the Mac.

Whilst I would hardly recommend to architects that they should use their primary productivity application in a virtualised window, from the perspective of those Mac users who need to occasionally use a piece of Windows only software this level of functionality and performance from Parallels is perfect. Sure it is not nearly as quick as running natively, but then you don't have instant access to all of OSX's niceties that you begin to miss once forced to work on a Windows desktop for a little while.

CAD Collaboration

David — Mon, 26 Feb 2007 05:00:01 +0000

(or how I learned to stop worrying and love ambiguity)

This post covers the issues surrounding CAD collaboration and past approaches to resolving it. It then concludes with a concept of how decentralised digital model development could be undertaken in a manner that reflects the ambiguous environment in which collaborative design is experienced.

The Problem of Digital Model Orientated Collaboration

Modelling an architectural design in CAD almost never occurs in an isolated environment. Typically work is undertaken with at least one other person simultaneously in order to meet development deadlines. Unfortunately issues arise when participants wish to simultaneously change the same design element, or a set of design changes inadvertently effect another aspect of the digital model.

Recently I was asked to comment on a debate that was raging in the Vectorworks forums related to its minimal set of collaboration functionality. Whilst the forum thread initially begun as a feature request it soon evolved into rather heated debate over how collaboration functionality in CAD should function (if at all). Central to this online debate was the role internal offices processes and politics held in the success of a collaborative digital model. Whilst this is typically the most visible factor we must also keep in mind the mere introduction of digital models has significantly altered our collaboration psyche.

Representational Shift

Before CAD collaborative design development had minimal effect at the drawing level because it was understood that each sheet was an isolated representation of the proposed design. Irregularities on different sheets were accepted as a byproduct of the chronological drawing process or later amended with supplementary information. In a digital world we are unwilling to accept this representational ambiguity for two reasons: either the integrity of the digital model is so important to design documentation that it cannot be ignored, or psychologically the consumers of the data expect digital models to be consistent because 'the computer is never wrong'. Whichever expectation holds true it illustrates a subtle representational shift from drawings as a means to an end, through to the digital model as a means and end unto itself.

Perception of Precision

Conventional architectural representation is of limited precision due to the inaccuracies of the tools available and the small scale applied to most drawings to fit their chosen media, for example a sheet of A2 paper. In contrast the digital model has no defined scale and a high degree of fidelity because of a computers ability to manage large quantities of data quickly and accurately. This computing capacity raises the perception that a digital model is very precise when in fact it often has the same tolerances as a conventional drawing. As a consequence when inconsistencies are identified within a digital model they are viewed as failures of the process rather than as natural artifacts of the dynamic and inherently imprecise activity that is architectural collaboration.

Due to these representational and perceptional changes there is an increasing emphasis within the Architecture, Engineering and Construction (AEC) industry to consider the digital model as the outcome of the design process in place of a conventional set of production drawings. This shift in desired outcome has heightened the challenge when it comes to enabling multiple parties to efficiently manipulate the same digital model.

Prior Teamwork Solutions

Various methodologies have been applied to the problem of enabling teamwork within a single digital model. A summary of these high-level approaches are: linked independent files, external document management, an intelligent master with satellites and an always connected, centralised digital model. Most CAD packages take advantage of one or more of these methods to enable their users to work within a team.

Linked Independent Files

Pros: Simple, supported within a wide variety of software, low barriers to entry
Cons: High management load, no warning of external changes, external data cannot be manipulated

This is the oldest and simplest method of collaborative digital model building. Within CAD circles the process of linking is often called referencing or XREF'ing depending on the software vendor. A linked-file collaborative approach enables two or more people to work independently on different files whilst still having a reasonable idea of how the entire digital model is evolving. Due to its simplicity and relative maturity as a concept most CAD applications support some form of file linking, in some cases even across different file formats (e.g. dwg to dgn linking).

Unfortunately due to its file-centric nature linked files cannot be manipulated within the working document. Another drawback of this approach is that the simple links formed only share geometry information and ignore related meta-data such versioning information and impending design change notifications. In order to account for these shortcomings high levels of external management are required to communicate this data and resolve various issues related to access permissions and naming standards.

External Document Management

Pros: Applied on top of existing CAD platforms, often deeply integrated, provides a range of extra services
Cons: Requires purchase/maintenance of separate software, issues with lock-in and upgrade cycles

The primary advantage of using an external document management system in concert with CAD software is that it allows team members to overcome many of the shortcomings of the linked file approach without changing the CAD software users have experience with. Unlike conventional documents a digital model often spans multiple files which raises problems around data consistency and interpretation. AEC-specific document management tools have evolved to meet these issues and handle change management, clarification of naming standards and communicate digital model meta-data such as unresolved design issues. Increasingly these systems are also implementing automatic file conversion functionality (i.e. digital model to PDF or DWF) in order to increase accessibility of design information to all members of a design team.

There are two distinct forms of AEC document management system, CAD vendor specific such as Buzzsaw and ProjectWise and vendor neutral such as Adept and Eskudos. Vendor specific systems work with external data sources but their real value comes through deep integration within their respective CAD platform. Deep integration provides significant advantages in productivity and user experience through tailoring both CAD and document management experiences. Unfortunately deeply integrated tools make it increasingly difficult for team members lacking vendor-specific (and often costly) software to participate equally in development of the digital model.

An Intelligent Master with Satellites

Pros: Self contained collaboration, intelligent semantic-based permissions
Cons: Requires complex synchronisation process, steeper learning curve for new users

The evolution of Building Information Model (BIM) concepts within software such as Revit and Archicad has led to development of highly structured models capable of being edited simultaneously by multiple parties. This capability stems from the models ability to internally divide itself into a number of discrete areas which can be assigned user-specific editing permissions. In theory each user could then access and modify the same file but in practice network and disk I/O problems have limited availability and reliability. To overcome these hurdles copies (satellites) of the digital model are distributed to each user for editing on their local computer. Once the changes are complete a synchronisation process replicates the working model's changes back into the master model and updates the satellite file with other updates that have occurred within the master.

The benefit of such an approach is that all design and collaboration information is contained within the same digital file rather than being distributed amongst multiple resources on the network. Management overhead is minimised as the CAD platforms which employ such an approach understand rich architectural semantics allowing their collaborative capabilities to be relatively intelligent. From the end-user's perspective their experience is also improved as they are not dependent on network or shared resource availability and performance to undertake work.

A limitation of this and the linked file approach to collaboration is that users cannot make or propose changes to design elements beyond their set of allotted permissions. Consequently careful planning must be put into the assignment of model access rights to ensure that the team's working efficiency is not impeded. In rigid teams where responsibilities are clearly understood such a task may not be difficult, but in fluid teams this can be a significant challenge and an impediment to productivity.

An Always Connected, Centralised Digital Model

Pros: Everyone is always working on the same model, real-time collaboration, fewer management issues
Cons: Requires a constant network connection, no production systems yet exist(?)

In a completely centralised digital model all information is stored at a single location such as an internally operated server or within a cluster on Internet. CAD users interface with the model via network connected devices and a piece of client side software that displays the data in a meaningful way (think Google Earth). As all write operations are performed at a single location these design changes can be viewed in real-time by team members connected to the system.

Management decisions still need to be made over who has the permission to change what and when, but in an always connected environment it is usually assumed model locking will occur at finer level than that employed within a satellite approach. This is generally because a satellite approach encourages the reservation of editing rights on a larger area than actually required. This is because unforeseen changes may need to be made and the risk exists that another party will modify a dependency such as a wall or other relevant design element. In contrast within an always connected, centralised model editing locks can be localised around specific areas because users have a real-time understanding the digital model and the context in which they are making their design decisions.

In practice a centralised model is similar to a satellite approach without the complicated synchronisation process. Unfortunately even in a world where the Internet has become ubiquitous, maintaining a network connection is still the greatest barrier to employing such an approach. As a result there are very few, if any, production-quality CAD tools that are based solely on this architecture. The most notable examples that come to mind are the IFC Server Project and Divercity research projects, both of which never left their testing environments. Given the increasing proliferation of the Internet throughout the developed world it seems inevitable that a CAD product based on such a collaboration architecture will reach the mainstream in the not too distant future.

Hybrid Approaches

CAD applications can mix and match these various collaboration architectures to reach a balance that suits their user's requirements and environment. MicroStation for example can make use of linked-file and central database collaboration architectures. Whilst most CAD applications store the digital model in memory and then save the changes to disk periodically MicroStation places its digital models within a relatively simple and open, file-based database system. Changes are recorded directly to disk and being a database multiple parties to read and write to the same resource (similar to Microsoft Access's JET back-end). Consequently MicroStation can employ a central database approach to collaborating or link independent file resources together in a more traditional manner. It must be noted that the central database collaboration functionality available within MicroStation is relatively limited compared to systems developed purely around such an approach but the fact it can operate in such a configuration makes it a very versatile collaboration platform.

Accepting ambiguity when the 'computer is always right'

Attaining an absolute answer from a process that is in flux until the paint literally dries is a difficult proposition. In the teamwork architectures described this need is met by having one 'correct' digital model around which we go to great lengths to preserve. Central to this mindset is that a digital model should be 'more correct' than a traditional drawing. Unfortunately at the end of the day the models we develop are just best guesses based on the information we had on hand at the time of authoring. If for some reason the context behind those guesses change, for example a wall is repositioned, it is the process by which we can adapt our design intentions to meet these changes that should be more important rather the processes followed to maintain a 'correct' digital model.

An alternative approach – snapshots and deltas

Assuming for a moment that the computer is not always correct how do we work collaboratively on a digital model in a manner that embraces this ambiguity yet still allows us to be productive? I don't have a definitive answer but what follows is my idea on how this could work based on an architecture that is distributed rather than relying on a single, all powerful point of reference.

Before explaining my alternative approach two I.T. concepts must be introduced: snapshots and delta encoding. A snapshot is a captured moment in time during the life of a piece of data. It is commonly used to enable the backup of data that is undergoing constant change such as databases. Delta encoding is the process of recording only the changes that have occurred to a piece of data over a period of time. It is more efficient than storing two different copies because generally data manipulation is a subtle affair (we add a door or move a wall) rather than an event which is completely destructive (the entire model gets deleted).

With these two concepts in mind my intention is to now describe a methodology for digital model collaboration that attempts to satisfy the seven Project Information Cloud principles of:

Simplicity
Modularity
Decentralised
Ubiquitous
Situational Awareness
Context Sensitive
Evolutionary Semantics

The aim of the approach outlined in Figure 1 is to provide an intelligent way of understanding, comparing and merging distributed changes to the digital model. A secondary objective is to allow the participants to operate independently without tight managerial control which can be a major hindrance to productivity and creativity.

Within this architecture a snapshot can be simply a conventional CAD file but in order to satisfy the requirements of the architecture it requires a versioning index to be maintained which describes the history (authors and dates) of the digital model's snapshots. The recorded delta changes would describe in CAD terminology how the digital model has been manipulated, for example 'wall A was changed to a length of 10m'. Both the versioning index and delta changes could be maintained within the CAD file itself or stored externally as separate files or a series of database entries. For the purposes of this example it is assumed the versioning history is maintained within the snapshot whilst the delta changes are stored as separate individual files.

In the following example there are three design team members who work on the digital model at different times during the project's history.

Figure 1: An outline of the distributed CAD collaboration architecture based on snapshot and delta change concepts (click to enlarge)

A Fictional Description of Events

Andrew the architect creates a new digital model and sets to work describing the building in CAD (1). Once he has determined the basic design he meets with Carol the consultant who is charged with developing the interior fit-out of the building. It is at this point Andrew creates a snapshot of the digital model to provide Carol with a copy to work on (2). Once Carol understands what Andrew has been up to she begins adding new design elements to meet the specialised working needs of the client (3).

With her part of the design complete Carol meets with Bob the builder who has offered to help out on some construction detailing she did not know how to solve. Carol creates another snapshot of the project file and emails it to Bob (4). Bob quickly completes the detailing and resolves an issue with the placement of one of Carol's dividing walls near a structural element. Bob then arranges to meet with Andrew the architect after the weekend and go over the things he and Carol have worked on.

On the night before their meeting Bob emails Andrew a snapshot of the digital model (5). On opening the model Andrew is notified by his CAD software that the model has been modified several times by Carol and Bob for different reasons. Unfortunately over the weekend Andrew has also been working on the model which leaves him confused about who has changed what exactly and why. Looking at the work log stored within the file he determines that Carol modified model before Bob (6). With this knowledge Andrew points his Internet browser to Carol's secure file storage and downloads the file containing all the relevant delta changes she made to the digital model he originally provided her (7). The CAD software then automatically regenerates Bob's delta changes through comparison of the snapshot available and Carol's delta changes (8).

With all the relevant delta changes at hand the CAD software displays a chronological overview of the digital model's evolution from the perspective of each participant's input (9). The software then determines a list of design issues through the analysis of delta changes made by each of the design participants. For the most part the individual changes to the digital model work well together but a couple of problems do arise around Bob's repositioning of the dividing wall and some of the changes Andrew has later made (10). Andrew generates a report which includes a breakdown of these issues alongside relevant plans and sections to discuss with Bob. While the report is printing he also calls Carol to see whether she has any preference on the final location of the dividing wall as she was the person to originally propose it. Fortunately for everyone involved Carol does not mind where the wall is placed leaving the decision in the hands of Andrew and Bob.

Whilst overly simplified the hypothetical example above does illustrate that a distributed approach based around snapshots and delta changes could be a worthwhile and flexible addition to an architects collaboration vocabulary.

Benefits of a Distributed Approach

A significant benefit of a distributed approach is that no external systems have to be maintained and participants are not reliant on network access to undertake work. Compared to the satellite model a distributed approach can work with unsophisticated data models plus there are no concerns around editing permissions as anyone who has a copy of the digital model is free to make changes.

Conventionally change conflict is viewed in a negative light which leads to restrictions being placed on the digital model at the expense of the creative process. In the approach just described anyone can potentially change anything within their copy of the digital model. Rather than focusing on restricting access to the model emphasis is placed on understanding of how these design conflicts arise, navigating a way through this potential minefield and finally reaching a consensus that it suitable to all parties.

Drawbacks Compared to Alternatives

Compared to centralised systems the actual process of communication is not handled internally within the model or through a defined external system. The architecture simply defines three components: snapshots, deltas and versioning logs, that need to be exchanged between parties alongside and complimentary to other design discussion. Rather than being the center of attention this approach is intended to work alongside existing communication systems such as email and document sharing services.

Such an architecture is not a worthwhile choice if the design team is avert to disagreement and uncertainty in the exact state of the digital model. Team members who operate at a managerial level would gain the lest value from such an approach because unlike centrally managed and monitored collaboration a distributed model does not have an easily accessible 'correct' answer. The process of understanding how the model is progressing would be assessed through communicating with those involved and accepting the fact the digital model is somewhat intangible and not as precise or reliable as initially perceived.

Conclusion

With the digital model becoming the focus and eventual outcome of design development collaboration within this medium is gaining increasing importance. Currently there are four different approaches to digital model collaboration that can be applied within software tools such as CAD. These varied approaches can also be applied simultaneously within software products to provide even more collaboration flexibility to design teams. Unfortunately the majority of these collaboration approaches lead to highly centralised processes that place an emphasis on consistency over flexibility. A decentralised approach using snapshot and delta change concepts would facilitate a more efficient and fluid design collaboration environment which encourages discussion and compromise in place of conformity and hierarchy.

Web Searching of CAD content

David — Wed, 17 Jan 2007 09:41:28 +0000

Recently Scott Sheppard from Autodesk blogged about Docupoint Discovery, an intranet/Internet search engine for AutoCAD files. It works by parsing binary AutoCAD files and indexing their textual and numerical content. Whilst it is not super intelligent (i.e. it doesn't make spacial assumptions based on the actual models submitted) it does help Autodesk workgroup users find information faster. The upshot of the Docupoint Discovery system is that you don't actually need a copy of AutoCAD, it reads the binary files into the index and if you need a quick preview it uses Autodesk's own DWF viewer technology to show it to you (now that is really helpful).

A similar set of functionality can be provided if you are an ArchiCAD Mac user by harnessing OSX's Spotlight functionality and the freely available ArchiCAD Spotlight plug-in. With this plug-in installed OSX can index all your ArchiCAD files (alongside all the other relevant project data like PDF files). Then with the next version of OSX (Leopard) or the open-source Weblight server you can search your Spotlight index on the intranet/Internet via a web browser. It does not offer the DWF-based preview option of Docupoint Discovery but for a zero-cost, minimum configuration solution it is not too shabby.

Personally I can envision these services operating very successfully if a services orientated architecture approach was taken and appropriate plug-ins were provided within CAD software. For example it would be ideal if AutoCAD was capable of generating its own DWF preview and submiting this plus the indexable data over a secure connection to a remote, hosted search service. Such a capability would remove the need for dedicated search infrastructure within the architecture office and provide a level of universal searching across CAD formats that was previously achieved only with text data such as HTML, PDF and Office documents.

A diagram of a service orientated approach to CAD search indexing (click to enlarge)

These search services could be operated by CAD vendors, external parties (i.e. Flikr style) or using a traditional internally maintained server model. Search results would be exposed via a Google style interface with 3D preview (in DWF/PDF depending on what is submitted) or via RSS using the OpenSearch standard. Unlike conventional Internet search engines content would be pushed to the search indexes rather than automatically gathered by automated Web spiders. This system would give content owners more control over what data files are submitted to the index and the frequency at which this process would occur. From a technical perspective this is very similar to how successful, real-time Web search engines like Technorati behave today.

Such an architecture would have a three significant benefits. Firstly users would feel comfortable using these search services as their valuable intellectual property are not being handled (or stored) by a third party. This is because all that would be exposed to the third party is the search index details and a relatively worthless (in I.P terms) 3D preview. In theory industry adoption would be relatively high given this level of data security, the low (if not free) operating costs and the relative ease by which such a service could be utilised. This widespread adoption would enable teams of people in different offices or companies to immediately gain the benefits of searchable CAD data without having to invest in expensive, internal infrastructure. Finally by exposing search results in a standard format (such as OpenSearch) AEC professionals would be able to cross the vendor barriers currently enforced when it comes to managing files of different types. Whilst a Bentley user may not be able to open the Autodesk file they would still gain important insight into what it was about (via the indexed metadata) and what it was like (via the 3D preview).

As these search services would not host the actual data file responsibilty for granting access would be in the hands of the file owner. In close working relationships the data file maybe located on a shared network drive whilst in remote situations (physically or professionally) access would be requested from the file owner via email or via some form of file transfer medium (instant messaging, FTP, etc).

Nemetschek become majority shareholders of Graphisoft

David — Wed, 10 Jan 2007 10:46:29 +0000

It would appear that the people at Nemetschek were busy over the Christmas holiday purchasing the majority of Graphisoft's shares. Nemetschek Vectorworks and Graphisoft ArchiCAD are two highly respected CAD/BIM packages that form a significant portion of the CAD marketplace (behind industry leaders AutoDesk and Bentley). At the end of December Nemetschek purchased all the privately held shares of Graphisoft and sometime during January they aim to capture the remainder which are publically held. The intital deal involved 5.7 million shares valued at 51.8 million Euros (approximately NZ$98 million). This purchase turns Nemetschek into a very serious AEC software vendor with a user-base of around 270,000 people.

What this means for the two competing CAD products is difficult to say. Vectorworks is very strong in the two-dimensional arena whilst ArchiCAD has a very mature 3-dimensional Building Information Model (BIM) core. It would be difficult for Nemetschek to continue marketing both products head to head considering the competition within the Architecture, Engineering and Construction space. It is also dubious whether the underlying software architectures are similar enough to warrant some kind of software merger considering both have a long development history. Given that it is unlikely that one of the products will be phased out (due to their entrenched users and functionality), a more likely scenario will see Vectorworks focus on the traditional 2D marketplace whilst ArchiCAD will continue to pursue BIM ideals at the expense of pure-2D functionality. This is the strategy employed by AutoDesk with their AutoCAD and Revit platforms and it seems to be working quite well for them. But unlike AutoDesk there is significantly greater functionality and ideology cross-over between Nemetschek's products which may prove harder to resolve internally in terms of where the two sit in the market and relate to each other.

Hopefully once the buyout is complete the long-term future for both entities will become a little more clearer. From a spectators position it certainly wouldn't be interesting to spend almost NZ$200 million and just maintain the status quo, but it may make the most business sense so I wouldn't be surprised if nothing exciting happens immediately.

Google releases a free version of Sketchup

David — Wed, 03 May 2006 08:20:12 +0000

As soon as Google purchased Sketchup it was obvious that a free version would soon emerge for the mass market (Windows only at the moment). From Google's perspective it is really useful for them to have their 'virtual world' (Google Earth/Maps) populated with user-created 3D models. The best tool for the average Joe when it comes to doing this is SketchUp. My guess is the ulitimate goal from Google's perspective will be to have elements SketchUp embedded within Google Earth so that general users can quickly and seamlessly add their own 3D data whilst using Google Earth. Whether or not this happens or whether users take up the challenge and recreate their 3D world within Google is uncertain but one thing that is for sure is that 'free' SketchUp will really shake-up the relatively stagnant CAD market space.

For too long the US$500 price range for sketching tools has been the norm within the sector. Google obviously does not care about taking down AutoDesk but in one move its become the dominant player in the low-end 3D modelling market.

google
cad

Adobe Acrobat 3D: a very real threat to DWF

David — Mon, 01 May 2006 23:57:38 +0000

Architosh and CADwire have feature reviews of Acrobat 3D and I must say it sounds really, really good. I am big fan of the PDF standard but not of recent Adobe Acrobat releases (the term 'bloatware' springs to mind). When I first heard that Adobe where planning on including 3D support in Acrobat I assumed it would be a token gesture in order to differentiate it from its 2D PDF competitors like Foxit (my favourite Windows pdf reader). I began to change my mind and think it was something a little more serious when AutoDesk suddenly seemed to get very anti-PDF when it came to exchanging building information.

Reading the reviews of Acrobat 3D I can see why the people at AutoDesk seemed so worried, it has one major killer feature that really sets it apart from all the competition, a 'print screen' equivalent for 3D models. This 3D importing feature does not work at the software application level like most data importers, it skips all the difficulties associated with data format translation and plucks the 3D information directly out of the OpenGL buffer. This is a really intelligent move from Adobe, it gives their product a degree of model importing support perhaps only rivaled by Right Hemisphere.

From a user perspective it means they can pluck 3D models out of a variety of applications and easily exchange them between others and thanks to Adobe's ubiquity on the desktop there will be almost no concerns about the recipient not being able to read the pdf file at the other end. From an IT manager's perspective its easier to go with Adobe than AutoDesk's DWF because PDF and Adobe Reader are in the mainstream already (according to Adobe they've distributed 1.5 billion copies) so there is no need to train users or install additional software (like AutoDesk's very fat DWF viewer). Vendors like Bentley and Graphisoft must be happy as their products will have Adobe Acrobat 3D support without having do a thing. Plus now that there is a ubiquitous alternative to DWF as a 3D document medium (above and beyond the DWG/3DS data formats) they will not have expend the time and resources implementing DWF support in their own products, if anything these resources will be put into improved 3D PDF support.

This approach does have its drawbacks, plucking data straight out of the OpenGL buffer is not the most accurate method hence you could not trust measurements taken directly off the model if building it. DWF supporters point this out along with a number of other PDF shortcomings, but at the end of the day whilst technically not the best solution, PDF (like Microsoft Office) gets the job done and is used by the majority of people.

Why are AutoDesk pushing DWF? As their own diagrams illustrate it is the glue that holds the entire AutoDesk product silo together, without it they open the door for other competitors to seamlessly replace AutoDesk products within AEC teams. This competition is not a bad thing however, I think the two rival formats are doing more for interoperability between CAD suites than what ten years of IFC development has ever done.

2006 CAD predictions

David — Wed, 18 Jan 2006 21:10:16 +0000

Rachel Dalton-Taggart has posted some 2006 predictions for the CAD industry. Blog use will grow, 3D will continue to be adopted at a snails pace, Adobe may begin a flirt into the 3D market and more software companies will move their software back to the Mac thanks to its growning popularity. I think the first two are pretty good, Adobe will be too busy integrating Macromedia into their product lineup and combating competing software from Apple and Microsoft. As for Mac migration it would be nice to see but unforunately AutoDesk and now Bentley are firmly entrenched in Microsoft's proprietary DirectX API and Graphisoft did not even bother showing up to MacWorld 2006 this year for the second time in a row.