Sort of Off Topic: Movie Studio Software

Since I can't say anything about what I've learned about the next versions of Revit, AutoCAD, Vault, Productstream and Inventor - I'll do an off topic post.

I thought I'd blog about something else I'm working on - my family's personal Christmas-card-on-DVD... I've been using Sony's Vegas Movie Studio software to put together a year's worth of still pictures and a few video segments - and then put it all to music. It's a laborious task - this year's version will probably run 20 minutes, and I'll have 20 hours into creating it...

The Payoff
I start by slogging through the layout, order, theming and titles (which is 95% of the work). But then comes the music - and suddenly, what had seemed like a dull slideshow that even our parents would not want to watch - is transformed into something really, really cool. I sit back and watch the video, spellbound. I AM STEVEN SPIELBERG! (OK, perhaps more accurately I'm Cameron Crowe, leveraging the music unapologetically to tell the story and connect with the audience).

The Take-away
In any case - it leaves me wondering - why can't CAD software be like this more often? Where's the payoff that makes me feel like I've created something timeless and incredibly cool? Yes, in my previous post I joked that "I am Frank Gehry" - but that was comparatively minor (for a comparatively minor effort, as well)... I suspect that reducing the hurdles involved with visualization and animation might go some of the way towards reproducing "that feeling". But somehow I suspect that until we can hook our CAD software to music, we won't get the emotional leverage that I get from making a movie. It's an interesting thought...

Extreme Architecture with Inventor and Revit: You too can be Frank Gehry

One of the most interesting presentations I saw at AU this year was Autodesk's Lisa Brady, showing how Autodesk Inventor (a primarily manufacturing tool) could be used with Revit to generate both complex architectural massing shapes - as well as everyday content.

The key is the use of the ACIS SAT file as an intermediate format - as well as Revit's ability to take all kinds of massing elements and build walls and curtain systems on any face. While Revit is capable of modeling these kinds of things natively - it's certainly far, far harder than what you can do with Inventor.

See my example below:

Content Creation
Lisa also showed how to create Revit Family Content in Inventor... The trick is again to create a 3D SAT file of a part or assembly. In the case of an assembly, the SAT file made a trip thru AutoCAD - because Inventor has a strange layering convention, you need to change it to a set of DWG solids in order to place the solids onto layers. The layers, in turn, are used inside of Revit to assign different materials in the family.

What's Hot a Autodesk University? DWF...

This has been true for some years at AU - but this year it was definitely pervasive. Everywhere you looked people were touting DWF, and doing more and more with it. The (unofficial?) theme of the conference seemed to be "Experience it before you build it" - and DWF was a big part of that.

Windows Vista and DWF
One of the classic objections to pervasive use of DWF has been that "my customers know and have Acrobat Reader - they don't have this DWF thing, and they won't download it". Autodesk has pulled off quite a coup - while they didn't get the DWF Viewer included into Vista, they came close... They made DWF compatible with Microsoft's XPS (PDF competitor) spec... So Vista will be able to view 2D DWFs NATIVELY... Of course, it won't support 3D - but it will CERTAINLY help the adoption of DWF in the marketplace over the longer term (it's too bad that Vista adoption will be so slow).

Editor's Clarification: From Scott Sheppard, DWF Evangelist... It will just be the new DWF 7.0 standard files which is viewable via Microsoft XPS Viewer. XPS Viewer will also be backported to Windows XP as well. Also look for a new file extension: DWFx for future versions.

DWF Freewheel
One of the most interesting technologies I've seen lately has been Project Freewheel from Autodesk - a technology that uses AJAX (asynchronous Java and XML, and DHTML, etc) - to view DWF files on a web page with no viewer installed.

How does it work? Using only Javascript and web services, it requests that one of Autodesk's web servers render the view of your DWF file. Every time you pan and zoom, it does a quick round-trip to Autodesk to render it.

What's the downside? Well - I'm not sure if customers will have a hard time with the fact that the DWFs must be uploaded to Autodesk or otherwise publicly visible on the web in order to make use of the technology. I know that certainly manufacturing companies have been skeptical of such approaches in the past (raising the question, "how long before we see the Enterprise Freewheel project?").
http://dwfit.com

DWF FREEWHEEL 3D: BLOWN AWAY
The Freewheel sample has been been posted for a few months now - but only in 2D of course. Of course there was the inevitable question - what about 3D? And the word was that they were looking into it... But I was skeptical - that would mean some kind of capability of simulating 3D rotation in DHTML - and then re-rendering the 3D View dynamically... But they've done it!
That is quite the technical accomplishment...


Check out:
http://dwf.blogs.com/beyond_the_paper/2006/12/project_freewhe.html

If I had to guess, I think that they might be pre-rendering a bunch of low-resolution shots of different angles... Still impressive.

What's New in AutoCAD 2008? Reducing Customer Embarrassment.

OK - that was just a tease - Due to a Non-Disclosure Agreement, I can't reveal the specifics of what I learned at the Autodesk Developer Network conference this week... At least until February or so.

But as I was thinking about how I might vaguely characterize it - I was reminded of one of the worst parts of being a Product Manager - Customer Embarrassment. This happens when you sit and watch how your customers actually use your tools, day-in-and-day out. You quickly realize that for all the wonderful, whiz-bang features you've added, some very simple tasks are still incredibly difficult to do - or that customers work out elaborate unnatural acts to get what they need out of your software. As a Product Manager, it's painful and embarrassing to watch.

The good news is that, as a Product Manager, you have the power to fix things in the next release!

So that's all I can say for now... I'm not sure how many new features will have the WOW factor like we saw in AutoCAD 2007... But there are MANY features that will draw a collective sigh of happiness from the users in the trenches, when they realize that their day-to-day work will become much easier.

ADN Dev Days are coming...

For those of you in the Autodesk software development world, the season of joy (and occasional pain) is coming.

ADN Developer Days (and of course the larger, Autodesk University conference) provides a sweeping look at everything new that is coming in the world of Autodesk this year.

I say "joy", because Autodesk is typically demo-ing new products and new features - hopefully both the things that we've always wanted, and the things we never knew we wanted. I say "pain" because inevitably there will be features that STILL after begging, pleading, business cases and everything else - still didn't make the cut.

I'll be blogging from the show more actively this year, but most of the ADN content still happens on just Tuesday.

The other challenge will be figuring out what I'm aloud to say... The ADN conference is all technically under non-disclosure... So while I'll be learning all about new things - I'm probably restricted from blogging about them. So we'll have to see how we walk that tightrope. I believe that things covered in the AU general session (which usually has it's share of sizzle) will be fair game for blogging.

Case in point - I think that Shaan Hurley made the first public announcement that AutoCAD 2008 will have a 64-bit version. Now that's out of the bag - and although I've "sort of" known that it's been coming for 6 months, I'm still grappling with what it will mean for us... How quickly will our customers move? How are all of my developers going to build and test 64-bit versions?

Finally, we're entering the season where I'll have lots to talk about - new releases of all of the Autodesk 2008 product line, and their corresponding APIs... But that's still a ways off yet.

In any case, it's an exciting time of year.

.NET vs. COM in AutoCAD - What should I use?

Kean Walmsley writes about the pros and cons of .NET vs. COM in AutoCAD on the "Through the Interface" blog.

In general, a good article - but I don't think it addresses two of the biggest "gotchas" of AutoCAD.NET...

The Blessing/Curse of Versions
One of the goals of .NET was to avoid some of the issues of "DLL Hell", where different programs linked with different versions of DLLs without worrying about whether the differences were significant.

Now when I make an AutoCAD.NET application, it gets linked against the file "acmgd.dll" version 17.0.54.0 (in vanilla AutoCAD 2007). If 17.0.54.0 is not available later, you're out of luck...

Problem #1: Versions within AutoCAD and vertical Releases
In the AutoCAD 2005 release, we ran into a problem where vanilla AutoCAD was version 16.1.63.0, but the version of Autodesk Map3D 2005 and in various service packs was version 16.1.84.0...

Now - Autodesk has been far better about being nice about not changing the version randomly in 2006 and 2007... But there may come a time when it's necessary in mid-release, and that makes a lot of stuff break!

Problem #2: Versions between AutoCAD Releases
This one there's really no getting around... Each release of AutoCAD will have a different version of acmgd.dll... And as a result, your application will need to be recompiled for each version.

This is a disadvantage compared to both ARX and COM... In ARX, Autodesk has been fairly succesful at making ARX applications binary compatible within 3 release blocks (2004, 2005, 2006, for example)... With COM, I suspect because the COM layer "insulates" the application from changes even further, there are people who can still run the VB application they wrote for AutoCAD 2000 in AutoCAD 2007 (OK, so there might be some changes - but it's the exception rather than the rule)...

Summary
Don't get me wrong - I'm still a HUGE fan of .NET for application development... But the benefits that it brings are not without their costs compared to ARX and COM. I've also noticed that there may be some relief from this in Visual Studio 2005 (although I don't quite have my head wrapped around the "Specific Version=FALSE" option).

Editor's Update: Kean has put in a comment that clarifies this issue:
http://www.blogger.com/comment.g?blogID=23382408&postID=115816634885341203
The short, tongue-in-cheek version: In 2005, 2006 and 2007 it was intentionally broken, but going forward it will be the same as ARX ... So 2007,2008, and 2009 would presumably be binary compatible. Thanks Kean!

What's new in the Revit 9.1 API?

I don't know if you're like me... but as a CAD application developer, each new release is like your birthday... You have a stack of gifts in the form of new API calls that you have access to... And it's much more intense in products that are in early stages such as Revit (as opposed to how I felt about Pro/Engineer's 24th release).

So I immediately sat down when I got my hands on the Revit 9.1 Beta and tried to understand what was new - and what each new piece of capability might mean to me (and my customers)... What new powers would we have?

Well, in all the hubbub I didn't notice that Revit 9.1 was officially released last week - so here's my notes that I've been sitting on...

To extend the birthday metaphor, some presents turn out to be rockets, other presents turn out to be socks - and still other presents, like those from "Uncle Bill", just leave you scratching your head...

Related Posts:

• Theory of CAD API Maturation (forthcoming)
• What's new in Revit 9.0?

What's new in Revit 9.1???

First of all, there are a variety of new elements that can now be programmatically created:

• AreaBoundaryConditions
• BeamSystem
• LineBoundaryConditions
• MaterialSet
• ModelCurve
• ModelCurveArray
• PathReinforcement
• PointBoundaryConditions
• ReferencePlane
• Room
• RoomTag
• SketchPlane

As you can tell, this is a mixed bag - many of these are specific to analysis applications - but there are certainly some other neat ones, including Rooms and Room Tags, ModelCurves (which can include lines, arcs, splines, etc).

Materials
Materials have undergone a significant overhaul, and are much more useful. There is much better definition and control of material types (including specific handling for Wood, Steel and Concrete) - but also better handling in general for things like rendering, smoothness, shininess, fill/cut patterns, etc... Some of these things used to be available via the built in parameters on the Material Element - but many have now been promoted to actual class members, and they work much better that way...

Rooms/Room Tags
One of the nice pieces for FM or space planning related applications is being able to create Rooms, and be able to read and create Room Tags. As a side note, Room Tags can tell which Room they are associated with (however, Rooms don't know their tags).

Detection of Current Display Units
At last!!! How could we ever live without this?!?! Particularly for those of us who work in both metric and imperial worlds, and those of us who dream of someday writing a packaged application for Revit!

Suspension of Disbelief
OK, so actually it's called "SuspendUpdate" mechanism - and it allows you to temporarily suspend Revit's updates and consistency checking while you're making geometry changes. (I haven't needed it yet, but I'm sure it's there for a reason that I just haven't tripped over yet).

New Element Classes
The following elements have been promoted from type-less Elements (where you could just kind of guess what it was) to actual identifiable object status.

• Opening
• LayoutRules
• FillPattern

Generally these are things which you can now read (or update) some specifics about them - but you can't create them from scratch.

Compatibility
In terms of compatibility with Revit 9, it appears to be pretty good. The only thing I've noticed so far is that they renamed the "MaterialElement" class to just "Material" - once I fixed that everything appears to work identically.

In Summary
All in all, I have to say I got a few more socks than rockets (but that's me - who hasn't been called on to do much in the analysis integration - your excitement may vary)... But it's a solid release, and you can tell that they're committed to significant expansion of the API.

And if the various insiders that are contributing to the Revit API newsgroup are correct (here and here and here), then we have a lot to look forward to in the Revit 10 API. Maybe that will be the release that puts the API over-the-top (for me :) ).

Dealing with .NET 2.0

OK, so this is a little bit off my mainstream topics of CAD-specific application development... But I'm hoping that it's useful either to the CAD people or .NET developers in general...

As you may know, in the CAD world, we're (finally) being driven to .NET 2.0 (at least in the Autodesk world - I get the sense that the PTC/Dassault/UGS worlds, which are still multi-platform, are not pushing it as aggressively)...
For example:

• AutoCAD 2007 - DotNet 2.0 mandatory
• Revit 9.0 and 9.1 - DotNet 2.0 mandatory

But I ran into a problem with two of our clients in the same week, with the same issue in different applications. In both cases, they were deploying our applications onto new machines. And when they tried to run the applications, in both cases they got:

System.TypeLoadException: Could not load type`system.runtime.compilerservice.runtimecompatibilityattribute`from assembly`mscorlib, Version=2.0.0.0, Culture=neutral, publickeytoken=b77a5c561934e089`"

(or something close to that)...

What was the issue? In both cases, the machines had .NET 2.0, but they had the BETA version of DotNet 2.0 installed (build 2.0.50215). But the behavior was strange - some of the code executed, but other parts didn't... In any case, the TypeLoadException should be a red flag for developers.

How is it that these people had beta versions of .NET running around? Who knows... Obviously some early-adopter-developer sent them something that required it, and now we have to deal with the aftermath!

This is a complicated issue - I'm pretty sure that AutoCAD 2007 installs 2.0 as a pre-requisite. However, the Revit products do not (and our other product was a self-contained Vault application)...

So - to paraphrase Esterhaus on the police drama Hill Street Blues, "Let's be careful out there".

(Check during install for the existence of C:\Windows\Microsoft.NET\Framework\v2.0.50215, perhaps?).

Vault Utility with Civil3D

The introduction of Autodesk Vault into the Civil3D product line is generating some interest in the custom work we've done with Vault... in particular:

• Automated Vault Backup, which not only schedules the backup, but also sends the admin a nice report about the status of the backup.
• Active Directory Integration, batch-load a bunch of users from Active Directory into Vault, or even do synchronization and/or authentication against any LDAP database.

New Project from Template Tool

We also just completed a tool which addresses something that doesn't seem quite right... the lack of a template project infrastructure within Vault/Civil3D. While Vault can do a "Design Copy", that typically works against a single parent file, rather than a whole folder. Our tool allows you to point to multiple Vault folders as "templates", and makes it easy to get a new project folder with all of the files renamed with a job name/number (and all the XREFs preserved).

These are still custom solutions (not packaged)... but if anyone had interest in them, drop a line to devfeedback@avat.com.

Earth Connector for Revit - Open Beta

We finally opened the beta for Earth Connector for Revit to anyone, and publicized it as well. (Those few of you who read my blog were the only ones who really knew about the beta previously).

It's available here for download.

We're still trying to incorporate the feedback from our original beta testers - but the release seemed solid enough to open it up to the world.

Also in the past few weeks, the new KML spec for Google Earth 4.0 came out. While the existing KML format still exists, they've included the ability to reference in a COLLADA file as part of a KML file. This has several implications for the Earth Connector tools...

File Format
Based on what we've read so far, the Collada format is a bit more capable than KML. While I don't think it will be adopted widely by the CAD community, it WILL help us overcome some of the challenges that we've had with representing complex geometry in KML. (KML represented each surface only based on the points describing its boundary - which made certain surfaces as simple as cylinders and as complicated as concave/convex surfaces very hard to represent).

File Size
One of the things that the existing KML format was horrible about was file size. There was no way to say "here is how you describe this window - now I have 1000 of them"... You actually had to make all thousand separately. This made for a big KML/KMZ file, and helped in bringing Google Earth to its knees on occasion.

Monolithic
One thing, for better or worse, with the new KML mechanism for incorporating a COLLADA file is that the "model" is monolithic... One building represents one "item" in the KML file and the "My Places" pane.

Why this is Good
This is good because they now have the ability to move your COLLADA building around directly within Google Earth... (making the positioning part of the job MUCH easier)...

Why I suspect this is Bad
I suspect that this is bad for some people in the AEC world. One of the real benefits to people who care about more than just the "look" of the building is the ability to "take apart" the building and understand its contents. Look, for example, at the sample that we post on our site for Revit. In this house model, you can toggle on and off the roof and ceilings to see inside, the walls for other views, etc. You can even pick on each object in the house and see information about that Object from Revit (door make and model, wall square footage, etc).

While I don't have any real proof yet, I presume that there is a segment of the population that will like that capability... and while I can imagine some hacks to make it happen in the new Collada format, it will also destroy some of the benefits of Collada.

In Summary
I'm still excited to see where it all goes... It's going to be interesting to support the new file formats, as well as figuring out how it will all work with Revit, AutoCAD and Civil3D.

PostScript
For those of you who have been asking... the AutoCAD 2007 version will be posted shortly... We had originally planned support for AutoCAD Solids and Regions, but we're re-evaluating in the face of the new format.

Google Earth 4.0: A New Ballgame

Here's a lesson in "be careful what you wish for"...

All along the development of Earth Connector for AutoCAD and Earth Connector for Revit (soon to be public, I promise!), I've been grumbling - the buildings look so flat, there's no textures... Google Earth has such fast rendering, but the 3D geometry is so... basic.

So along comes Google Earth 4.0 (Beta). And right off the bat, the pictures show even more impressive 3D, along with far more realistic texturing (see picture).

As I dig into what makes it possible though, I start to feel mildly ill... Instead of improving upon the geometry capabilities of KML, Google has gone down a completely different route. They've brought in Collada - an industry-standard XML format for representing 3D models (at least it claims to be industry-standard in some industries - I personally had not heard of it - apparently it's well integrated with Maya, Studio Max, etc).

The Good
Our recent efforts to pull more AutoCAD solid and region data into KML have shown the fundamental inadequacy of KML for more complicated surfaces. Because KML represents faces by their boundaries, Google Earth arbitrarily defines what a face looks like (and for a given boundary, there are many possible permutations when you talk about more complicated, non-planar faces).

Further, by pushing this data into the Collada file and then referencing it within KML, this should make it easier to "reposition" data once it has been generated (since the KML does some of the work we currently do to position the 3D model at a given lat/long).

In fact, the new mechanism for "Placing" a 3D model in space is awesome... once you have the 3D completed, you just drag it into the right location all within Google Earth (for you current architectural Earth Connector users, you know how much better that is).

The Bad
While everything in Earth Connector will continue to work, if we want to move forward with the "nicer" 3D - we'll have to re-work everything into this Collada format.

If my initial suspicion is correct, this new format may also change one of the things that I really liked about our Earth Connector products - the ability to segment models, so that you could toggle Roofs/Windows/Walls on and off - this doesn't seem to be possible within a Collada file...

The Moral of the Story
Be careful what you wish for - you might just get it!

Earth Connector for Revit is in Beta

The sequel (sort of) to our Earth Connector for AutoCAD is available for beta-testing (if you're interested, drop a line to devfeedback@avat.com).

It works with Revit 8.1 or 9.0, and it takes your Revit design and creates a Google Earth KMZ file which can be sent/shared with others.

What's exciting about this release, for Revit users, is that the KMZ model retains a nice structure, organized by:

• Revit Category (such as floors, roofs, walls)
• Revit Element (so individual walls, doors, roofs and floors can be toggled on and off)
• Specific Geometry

The user has the option of specifying whether to include all Revit parameter BIM data attached to each Revit Element.

And as compared to the AutoCAD version, in the Revit version it will not be necessary to "prepare" the model - everything will come over as-is.

For you Revit users that like to collaborate or just communicate with owners, contractors and others - Earth Connector Revit will be a compelling way to do it!

Want to see a sample? If you have Google Earth, look here.

Zip files for Office 12, DWF

I was reading recently about the new Office 12 XML format (Office Open XML)... And it struck me how close it was to the approach that Autodesk took with DWF...

It's a Zip file, with content and folders, as well as XML to describe the meta-data.

In the case of DWF, that's property data, relationship data, etc.

In the case of DOCX (for MS Word 2007), it's meta data like the core Author/Summary/etc properties, but also information about the sections, styles, etc.

1. I think that this is a great idea of all companies - who publish structured data.
2. I wonder about who thought of this first? I seem to recall SmarTeam's iXF standard had some of this approach as well...
3. How do you get access to this data? There are different approaches...
A. Use a ZLIB library to decompress and find the files, then use Xml libraries to understand them.
B. In the DWF world, there's the DWF Toolkit (free), however I believe it's still C++ only, which puts an obstacle in front of us mere mortals (I could do it, but since C# has come out I've done so little C++ that it's withered on the proverbial vine... plus I'm in management now ;) ).
C. Most interesting, Microsoft is including a new namespace "System.Packaging" in WinFX, which will provide transparent mechanisms for reading "packaged" data such as this... Which raises the question of whether DWF will be readable based on this approach... It doesn't seem likely somehow, because the structures are not exactly the same, and System.Packaging seems very much tied to the structure that MS is using in OfficeXML... But here's hoping...

Links of Interest:
Inside a DWF: http://autodesk.blogs.com/between_the_lines/2005/03/a_look_inside_a.html
The Office XML Format:
http://www.microsoft.com/office/preview/itpro/fileoverview.mspx
Brian Jones, MS Product Manager, on Office XML:
http://blogs.msdn.com/brian_jones/archive/2005/06/06/425750.aspx

Revit and Sharepoint

One of the topics I do feel I can talk about is some work that we've done surrounding Revit and Sharepoint...

One of our clients REALLY likes Sharepoint sites for collecting project data, issues lists, etc. So the question came up - could Revit become more integrated with Sharepoint?

The answer is yes - pretty easily... Sharepoint has a Web Service API (and we've become reasonably comfortable with web services thru all the Vault and Productstream work we've done)... The API covers a lot of territory, but when you talk about publishing or synchronizing BIM data, you're pretty much correlating with SharePoint "lists" - lists are tables which can be defined by an administrator.

So we've done some prototype work to Integrate the Sharepoint Design Issues list with the Revit Elements that are related to each issue... And also publishing schedules (such as Room Schedules) out to Sharepoint - a neat FM-flavored prototype. Now all we would need to do is tie the data in Sharepoint to the corresponding DWF, and you'd REALLY have something.

So while the Revit API is still pretty limited, systems integrations applications like this are ready for prime-time...

What I can't talk about...

This blogging thing is tougher than I thought - at least in my particular situation... All day long I think of interesting topics to blog about, but I have to reject 3 out of 4 because of:

• Client-specific: I can't share things that are effectively proprietary to our clients
• Autodesk Internal: We wind up being on the inside of a variety of Autodesk product information, which we can't talk about.
• Avatech Proprietary: When we think an idea is so cool that we'd like to make a product out of it - but don't want to share the underlying info...

So - all in all - it's tougher than I thought to come up with interesting stuff to talk about...

Beyond the Paper

Whoa! Way beyond the paper, as the man says...
We've been exploring doing some work with Revit DWF for systems integration, similar to some of the stuff that we've done with Vault and Productstream - and the possibilities are amazing...
I've been working with a customer that has big visions of how BIM data can be tied to their back end systems, inside Revit, inside DWF, etc... And I'd like to say that as of 9.0, it's a reality...
Not only are all the objects there, not only are all the regular parameters there, but in particular two things show me that they went the extra mile (ok, it was probably only an extra 10 feet - but from a System Integration standpoint, it's the last mile).

Shared Parameters and User-Defined Project Parameters
It would have been so easy for them to leave this out - the parameters that the CUSTOMER thinks are important, beyond what is built in... They're in there.

The Revit Element ID
This REALLY blows me away... Each object in the DWF carries the ElementID that it was generated from, allowing you to cross-reference between what was in Revit and what was created in DWF...
I think that the door has been opened to real integration - and between what's there now, the new DWF Composer (Design Review) and the Constructware merger, I'm excited to be a part of where it's going.

The Right Mix of Features

More from OneTeamConference... A story of Product Management.

It's probably not appropriate for me to expose too much of the discussion here - but there was an interesting discussion I was involved with at OneTeam, and I think it is emblematic of the challenges all software manufacturers face when they have different "levels" of a product.

In this case, it was Vault (free, Data Management Software) and Productstream (real money, Vault + Release/Change Management, BOM, ERP integration, etc). They're down to the wire on the next release, and they're still not sure if certain features are going to be made available in Vault, or only in Productstream.

Why is it important? Well - the tough calls are when the features in question could potentially remove or reduce the compelling reasons for people to move from the (inexpensive/free) product to the more complete product.

For example, you can add a feature in Vault which is a great feature - but a side effect is that some people may use this feature in a way that allows them to implement limited change management - thus removing one of the compelling reasons to move up to Productstream.

Why would users do that? Well - users are fundamentally thrifty (my nice word for cheap) in many cases... They try to completely exhaust what is possible in the inexpensive product before moving up to a more expensive product. In fact, I've seen many cases where users invest far more in making something free work (often working badly) than it would have cost them to invest in the more advanced technology... Is it everyone? no - but in the SMB engineering space it's a very measurable percentage of the population.

In a kind of funny twist - I've been accused of doing that in the past with our Vault Access product (that is to say, the manufacturer getting miffed at a channel partner)... removing a compelling reason to upgrade by providing visualization and printing capabilities within Vault...

Maybe my views have changed a little over time, but here's my thoughts in the end:

• Segment your markets - understand if some people just won't need the higher functions, and accept that.
• Depending on your segmentation, you only owe so much to the "free customer"
• If customers will reasonably make a "stop" on the free version before moving up, then make sure that there's enough there so that they can work (if going to Vault first is a step that it's acceptable to take - don't prevent them from going to Vault).

This has another potential wrinkle, late in the game... Because Vault/Productstream clients actually use the same API that developers have available - Autodesk will need to be careful not to just "turn off the buttons" in their client... Or else some developer is going to write something that implements this "hack" of release management.

I'm not sure if it was clear from this post - but I'm actually supportive of them pulling this feature back - so that it's only in the higher-end Productstream... If customers were going to this length to implement this poor release management - then they ought to be really addressing release management with Productstream - and Autodesk and the channel ought to be doing a better job of these Vault Power Users to convince them of that.

Back from Autodesk One Team

I just spent the better part of this week at the Autodesk OneTeam conference in Las Vegas...
And I'm trying to gather my thoughts that are relevant to this blog - but I think I have to expand a little bit...

Revit Building Systems
This is the first time that I had seen the new Revit Building Systems... And it's very, very, very impressive (at least to a non-building engineer like myself). Revit is really shaping up to be the hot package for the entire building design process. For those of you who aren't in the space, the term "Building Systems" refers to MEP - Mechanical (HVAC), Electrical and Plumbing. The "systems" that architects generally do their best to hide from your view - but that ultimately have a big impact.

Of course, from an API perspective - it still has a ways to go... we keep running smack into the edge of the envelope when we've been involved in prototypes - but it will get there.

As a side note on an API for the Revit Building Systems (RBS), while I'm pretty sure that there's no API - I can tell you that there are what seems like 1000 exposed parameters relating to RBS in the API... Things like RBS_PIPE_STATIC_PRESSURE... So that makes me think that at least the energy analysis applications will have enough to work with.

The New Productstream 5.0 API

While we're speaking of new APIs, the new Autodesk Vault/Productstream 5.0 API is out in beta... and I've had a preliminary look. (They do a nice job in this group with documenting the changes between releases, so they make it easy for me).

Vault and Migration of Apps
The Vault portion of the API has stayed generally the same, with only a couple very minor exceptions (a couple of additional parameters for whether to pull hidden files, some additional methods relating to the new security model)... Pretty easy to migrate any existing application forward.

Speaking of migration - if you're like us and you like writing apps that work across multiple versions of Vault/Productstream - you'll like the new InformationService webservice... It will query a server and tell you which version of Vault is running there, as well as whether Productstream is there or not (we could do that before, but only with .NET HTTPRequest tricks, because the Web Services used for the API were release-specific - so you got nasty SOAP errors when you tried to connect to the wrong version of Vault/ProductStream).

Security
The big thing in this release is the security model (that there is one - beyond your login)... Administrators can now define groups, as well as permissions at the folder level on groups or individuals). So the Admin and Security Service have been updated to reflect that.


Productstream
For Productstream, this is the release where they promise to start "settling down" - and not changing the API so much from release-to-release.... As with Vault 3 to Vault 4, they've renamed many (like 100+) of the methods and properties associated with Productstream.

They've also added support for some of the new Productstream features like Watermarking - and some nice utility functions for finding ReleasedItems associated with a given ItemMaster...

All in all, it looks nice (other than the massive rename) and I look forward to using it on this year's projects.

RevitDbg

I'd like to compliment Fenton Web over at Autodesk Developer Network for introducing a tool to help understand the Revit API: RevitDbg...

Similar tools have been developed on the AutoCAD and ADT side for some time - but this is the first time that it's been done for Revit... Fenton also gets style points for using Reflection in .NET - which lets the application look back at itself and tell you what it sees - very handy for explaining all of the datastructures associated with Revit (although perhaps a little slow when running against a gazillion possible parameters on every element - and I only jest a little).

The tool works by scanning the entire model (bad idea - it's on the slow side) or by scanning the selected elements and telling you all of the information associated with each element (down sometimes 10 levels in a tree).

It's simple but good - and it's the kind of thing that will make all the difference in whether people pick up the API and try projects - by letting them easily see if the information that they need is "in there".

New Revit API

While much of our day-to-day business is in the manufacturing world, we've been watching with interest the ongoing development of Autodesk Revit - which really brings the architecture and construction market into the modern age of CAD systems (after spending the 90s entirely in the manufacturing side, with pervasive 3D solid modeling, parametrics, associativity - it's been hard to look at where the AEC side of the world was).

In any case, Revit introduced a real .NET API in 8.0, and built on it in 8.1 - last summer. Autodesk is preparing to release Revit 9.0, which takes the API to a new level.

In Revit 8.1, the API was pretty minimalist - while you could query everything and update some things, you could create very little...

What you can do with the Revit 8.1 API:

• Search Elements, Parameters and Data (and EVERYTHING in Revit is a Parameter)
• Modify/Create parameters
• Extract Geometry
• Load/Place/Move/Rotate Family Instances
• Create/Update Structural Elements
• Access Room Data

What you can do with the Revit 9.0 API:

Create/Update:

• Walls, Floors, Grids, Levels, 3D Views, Sheets, Drafting Views, Sections and Dimensions

(there's other odds and ends - and while it doesn't seem like much, this may be all we need to get some interesting automation projects going with it).

And what's more, Revit 9 API requires Visual Studio 2005 (Wahoo that's fun! but only because I've already purchased it - I'd be a bit mad if I hadn't yet).

Throwing my hat into the ring...

I'm not sure where that expression comes from, but I figured that I should probably start my blog before I'm the last person on the planet that doesn't have one....

In all seriousness, I've long been inpsired by the blogs of Seth Godin and Lawrence Lessig - and I've seen the growing amount of CAD blogs. I'd bet that I have the occasional interesting thing to say on the topics of Computer-Aided Design, and developing software that works with CAD, PLM, etc.

But you'll be the judge of that, won't you?