Autodesk Responds to the PolyFace Mesh Issue

Kean Walmsley, Senior Manager - Developer Technical Services or Autodesk responded to my post about the PolyFace Mesh issue. This is what he said:

Deelip,

A little on how this works from Autodesk's side of things. I'll let you decide whether you "lost on votes" or not.

My team (Developer Technical Services - the staff providing the various technical services via ADN) receives bug reports and enhancement requests from ADN members, which we then validate and submit to our various engineering teams.

Once we've logged a Change Request (CR) in our CRM system, we report back to the person submitting the issue with an ID that can be used in future to refer to that CR. We also make sure we ask the person submitting the issue to justify the priority of the issue, so that we can help prioritise dealing with it.

That's our standard procedure... now for how timing can affect things.

You submitted this particular limitation in early December 2006. Now of course you're going to say "but that's given you two years to deal with this!", but let me explain why this unfortunately isn't quite how it works from our side. You submitted the issue at what was unfortunately a very late stage of our development cycle for AutoCAD 2008, and without some justification of external urgency/priority, we didn't have much choice but to defer the handling of the issue for that release. Early on in the development cycle we are much more open to such requests, but as the cycle proceeds we get very conservative - which I know can feel frustrating, but is also a pragmatic approach for maintaining the quality of the AutoCAD product/platform.

OK, your next question is probably "so why wasn't this carried over automatically for handling in the next release?" Once the CR is in the system and gets deferred for a particular release, we wait for one of two events to occur: either the developer submitting the issue gets back to us with a "business case" so that we can help engineering decide where to prioritise, or we have other developers submit the same issue, which then get linked into the same CR and cause us to ask engineering to take another look into it. In this case we unfortunately received neither a further justification from your side for making the change nor any subsequent report from a developer complaining about the issue.

When I say a business case, here's what we actually asked for in our email to you:

"If you would like to provide a business case towards implementing this Change Request, please append it to this current case and we will forward it to our development team. Your providing a business case can increase the urgency of your request with our engineering team. Please provide as much information as possible, including the impact of this issue on your application, the number of users affected, and the expected revenue impact for both you and Autodesk. "

To be clear about this... we don't necessarily need a lengthy, detailed or even a financially impressive justification for us to prioritise handling an issue, but we do need to hear from someone (whether you or someone else) that this issue is worthy of resource investment. If we had received some kind of justification, even something like "as models gets bigger, it's going to be increasingly important for customers to deal with huge meshes", then that would probably have been enough to at least have someone from engineering evaluate the amount of work required to address this.

So, a couple of suggestions for getting changes made to Autodesk software: firstly, always let us know when an issue is important to you. I know that might sound silly, but when you have software that is used by millions of end-users with a development community numbering in the thousands of companies, squeaky wheels get more attention. So be vocal.

Also, keep track of your pending CR IDs and don't be shy about sending them into my team to get status updates (and to give us a prod). We can tell you whether issues are basically in a holding pattern (i.e. a black hole) or whether something is likely to happen. As a matter of course my team now sends status updates to developers when the status of their issues changes, but that's only a process we've had in place for a year or two (and issues submitted prior to that won't be covered).

I hope this helps explain some of what went on behind the handling of this issue.

Kean Walmsley

Senior Manager
Developer Technical Services
Autodesk

I appreciate Kean's reply, which has given me (and probably you as well) a deeper insight as to how things happen in a company as large as Autodesk.

The Autodesk approach seems to be reasonable, but I find a fundamental flaw in the logic they employ. Before I delve deeper, I would like to say that the approach being discussed here pertains to the manner in which Autodesk handles Change Requests from its developer partners, which may be very different from how they handle requests from end users.

As I see it there are two kinds of Change Requests - those that help the developer and those that help Autodesk. Lets keep customers out of this for the moment. I think this whole idea of a developer being asked to submit a business case make sense only when the requested change is going to primarily help the developer. For example, suppose a developer wants Autodesk to add mesh boolean functionality to AutoCAD because a plug-in that he is developing needs it. In such a case, Autodesk is perfectly justified in requesting the developer to submit a business case for Engineering to review and decide whether it is worth making the change. But if a developer calls attention to a fundamental flaw and limitation of AutoCAD, in this case, something as serious as invisible and unselectable geometry and something which even AutoCAD's own Audit command cannot fix, I do not see the sense in asking the developer to provide a business case. Its like Obama asking the CIA to convince him that Osama with a nuke is a bad idea.

Recently, when it came to my notice that Autodesk had still not fixed the PolyFace Mesh, I brought it up with them and rightly enough, according to the system they have in place, they asked me to provide a business case. I am a software developer and whenever someone finds a bug with my software I thank him from the bottom of my heart, go ahead and fix the problem, let him know when it is fixed and thank him once again for helping me improve my software. So when Autodesk asked me for a business case to convince them why AutoCAD should be able to handle large meshes or why it should not have invisible and unseletable geometry, it ticked me off. This is part of an email I sent them:

"You have to be kidding me. As a well meaning and concerned partner I have done my part in pointing out the problem. I have done my part in suggesting a solution and now I have done my part in reminding you to solve the problem. I do not have the time nor the patience to create a business case that explains common sense."

Subsequently, after being told that, as a rule, Engineering would not consider any Change Request unless there is a business case attached to it or unless it was a stop ship issue (crash), I did supply a business case. Armed with my business case, my contact at Autodesk tried his best to convince Engineering, but it was too late. The new DWG format was already locked by then and changing it would mean conducting extensive regressing testing which would throw everything off track.

I still think I lost on votes. If more people had made a noise about this issue, it would have been noticed and I would not have been writing this. But after reading Kean's reply, I have also come to realize that I made the mistake of assuming that someone at Autodesk would see the sense in my request and fix the problem. But their system is not designed that way and I sincerely hope that they do something about it.

I have learned my lesson. The next time I submit a change request to Autodesk I know exactly what to do.

SpaceClaim Listens

In my last post I mentioned how my PolyFace Mesh related service request was ignored by Autodesk. In a stark contract, this post is about a company called SpaceClaim that does listen to what people are saying about their software. My only hope is that they continue to listen even after they have a large and probably unmanageable customer base like Autodesk does.

On 14th October 2008, I wrote a piece for upFront.eZine regarding OpenRP and how it solves problems related to the STL file format. In it I wrote:

"To store the geometric data of an assembly (many parts), the STL file would need many 'solid'/'endsolid' blocks -- which is not allowed by the STL format. Some CAD vendors, notably SpaceClaim, threw the STL standard to the wind by generating ASCII STL files with many 'solid'/'endsolid' blocks, one for each solid part in an assembly. You may think this is a good change, but I find it careless."

And I went ahead to explain why. That same day, Kevin Leblanc, Manager of Technical Services at SpaceClaim, contacted me to clarify things. I explained to him why I wrote what I wrote and he promised to fix the problem in the next release or service pack. And that is precisely what he did. I am extremely pleased to report that SpaceClaim 2009 now outputs STL files correctly. In fact, they have gone ahead and given the user the flexibility to output STL files per design, component or body, which I believe is excellent.

My world happens to revolve around CAD data exchange. 155 out of our 174 products are file import or export plug-ins for CAD systems. CAD users all over the world contact us every day with problems related to some file format or another. What pisses me off the most is when I see irresponsible software developers output CAD files with blatant disregard to the file format specification.

A typical example is the IGES file format, which is supposed to be a standard neutral file format, specially designed to ease the transfer of data from one CAD system to another. Over the years CAD vendors have abused the IGES file format by making variants of it to suit their specific needs, thereby defeating the very purpose of a neutral file standard. One look at the Rhinoceros IGES export options dialog box gives you an idea of the magnitude of the problem.

There are 60 types of "standard" IGES files. I don't think I need to say more.

The PolyFace Mesh

Two years ago I posted an article on this blog ("The long and short of AutoCAD's PolyFace Mesh") reporting a problem in the way AutoCAD stores a PolyFace Mesh object in a DWG file. I ended the article with:

"The irony of all this is that over the years Autodesk has revised the DWG file format a number of times, more recently to make it more difficult for people like ODA to reverse engineer it. I only wish they had changed the short to a long and added real value to it. There are supposedly billions of DWG files out there. Too bad not a single one can store a mesh with more than 32,767 vertices."

Two years ago I registered a formal service request with Autodesk regarding this issue and at that time I was told that this situation would be remedied only when they next change the DWG format, which was in AutoCAD 2010.

Today, with great disappointment, I have to report that AutoCAD 2010 will not be able to store a PolyFace Mesh containing more than 32,767 vertices. Why? Because they still did not change the blessed short to a long. Why? There were not enough votes for my service request.

I am trying to understand how these big companies work. From this experience I have to assume that they receive so many service requests and bug reports that they simply cannot fix all of them. I can understand that. So things get prioritized based on how many "votes" each request gets. This line of thought leads me to believe that there is nobody in Autodesk who is entrusted with the job of using a little common sense to figure out for himself whether a service request is worth attending to, without looking at the number of votes it has received.

All other CAD systems I know can deal with large meshes. All mesh formats I know use long's instead of short's when storing mesh data. Any high resolution terrain mesh will exceed this limit. Almost all dental scans with exceed the limit a few times over. And considering that Autodesk is laying special focus on 3D in AutoCAD 2010, a little common sense should have been enough to conclude that AutoCAD 2010 should support large meshes as well.

Now lets consider how AutoCAD behaves with large meshes. I open a DWG file containing a single large PolyFace Mesh in AutoCAD 2010. The drawing window comes up empty, but if I run the "list" command type "all" at the "Select objects" prompt, AutoCAD reports that it found one object and proceeds to list it as a PolyFace Mesh. So I know that the mesh is there somewhere. Now let's try and view its properties. Since I cannot select an object that I cannot see, I run the "properties" command and do an "Edit->Select All". This is what I get.

As you can see the PolyFace Mesh has -1218 vertices (yes, that's a negative number) and no faces. Let me explain. In programming parlance when a variable goes out of range, it loops around and goes negative. So you can imagine that this is no small problem. Firstly the mesh is not visible and secondly it has an invalid definition. OK, now lets try and fix it. I run the "audit" command and choose to fix errors. Audit did mention a problem with the mesh (vertex count less than zero) but then reported no errors and fixed nothing. It could not fix it because the PolyFace Mesh data structure is not capable of holding that kind of data. I guess it could have exploded the mesh into individual 3D Face objects, but with the mesh definition in the DWG file corrupted, that does not seem like a possibility either.

And so I still have a DWG file that does not show the PolyFace Mesh and which still has invalid geometry. Why? Because someone at Autodesk didn't find my service request had enough votes. So why didn't customers complain about this? I guess because they probably don't know that the problem exists. You cannot find fault in something that you cannot see or don't know about. The sad thing is that this very serious problem has a very simple no-brainer solution which I provided two years ago to Autodesk. But since they use this weird fire fighting approach of putting out only the largest fires and ignoring the small ones, without employing common sense to think for themselves, the problem still remains.

So for all these years AutoCAD users have been unknowingly working with invisible and invalid PolyFace Meshes, and if Autodesk keeps up with their three year cycle, this problem may be solved only in AutoCAD 2013, that too only if enough customers make a noise about it.

I find it very hard to believe that someone at Autodesk analysed my service request and decided not to fix the problem. I get the feeling that my service request lost on votes and just did not come up for hearing.

Neil Peterson

Continuing my series of interviews of programmers who I have worked with over the years, here is one with Neil Peterson, CTO of the Open Design Alliance. I have met Neil on two occasions - on the sidelines of COFES 2008 and at the IntelliCAD World Meeting in Athens last year.

How did you get into CAD software development? What was life like before the ODA?

Before ODA I worked for a small company called ImageMark Software Labs, who provided conversion support for a large number of graphics and engineering file formats, including DWG, IGES, PDF, PowerPoint, and most common graphics file formats. At ImageMark I had my first experience with CAD development working on an importer for R13 DWG. Prior to that I had worked with a number of presentation applications such as Corel Draw, PowerPoint, etc. The CAD work was more interesting and more challenging. Working on R13 was the most difficult task I had faced up to that point in my career, and it was that work that allowed me to step in and handle development work for the ODA.

You were the first employee of the ODA and today you are the CTO? How much has changed, apart from salary?

For me everything has changed. I was the first developer hired in 1999, and in the early years I did everything—development, bug fixing, testing, porting, client support, documentation. When I was first hired, AutoCAD 2000 had just been released and there were several hundred ODA members depending on the ODA to support it ASAP. Although I had worked extensively with DWG at my previous job, I had never worked with the ODA source code—needless to say, my first few months were interesting and intense. We got the 2000 support finished, and I had the opportunity to work closely with a number of ODA member companies. Our early success allowed us to start expanding our development team, and as the team has expanded over the years I have handed off most of my original day-to-day responsibilities. I now work as a coordinator and enabler for our various teams. I’ve had the opportunity to watch a number of talented and hard-working engineers grow into senior members of our development team, and it has been a pleasure for me to continue working with our developers as CTO.

Do you still code? Why?

I still enjoy coding, but it’s not my role any more. My current focus is on managing the growth of our organization, improving communication with existing and potential ODA members, and making sure our developers have everything they need to be successful.

What do you feel when people call the ODA a “bunch of hackers”?

I don’t take it personally. Anyone making such claims hasn’t taken a serious look at our software. Most people in our industry are aware that we perform a critical service by providing open access to the DWG file format. But our software has evolved over the past 10 years, and we now have a full-featured CAD development platform and not just a DWG I/O library. This evolution is clearly demonstrated by the fact that we now have several member companies building full CAD systems using our platform as the kernel. One of our goals this year is to get this message out to our membership and to the general public. For anyone who is interested in learning more about our software, the ODA World Conference will be held in Leiden, The Netherlands on April 27-29 this year. The conference will showcase our latest software, provide an opportunity to meet our development staff, and serve as a forum for discussions. Registration for the World Conference is now open on the ODA web site.

How much has changed at the ODA after Arnold took over as president?

Things have changed dramatically at the ODA since Arnold took over. Our infrastructure has been significantly upgraded. We’ve hired several key people to manage various parts of the organization. Our development and QA teams have grown. Communication with members has improved. Arnold has also been instrumental in initiating relationships with companies like Spatial and TechSoft3D, allowing us to provide integration solutions for third-party components such as ACIS and HOOPS. Overall the ODA is a much stronger organization today than it was a few years ago.

Autodesk is changing the DWG format for AutoCAD 2010. More than a thousand ODA members (including myself) are relying on you to deliver. Do you manage to get sound sleep at night?

I’m sleeping OK. This is the 5th DWG format change that I’ve been involved with as a developer and manager. All of our engineers understand how critical this work is, and we are ready to face this challenge.

The file size of all the ODA libraries add up to more than 12 GB. How long does it take to build all of them?

It of course depends on the platform, compiler and actual hardware, but average build time for a full set of our libraries is around 30 minutes on a reasonably fast machine.

As the CTO of the ODA do you wish to see different variants of the DRX SDK floating around? If not, can you do anything to stop it?

We want to see a single DRX standard. We take this issue seriously, and we are working with members to ensure that anyone using our DRX technology is maintaining compatibility. Member companies can build extensions on top of DRX, but they are contractually required to maintain compatibility with our core SDK.

What is stopping the ODA from developing a product for CAD end users?

Our member companies develop a wide range of end-user applications. If we were to start developing end user products, we would be in direct competition with our membership. We are a member-driven organization, and currently end-user products are not in our charter.

Will the DWGdirect SDK ever be made source compatible with ObjectARX? Don’t tell me ITC members are not asking for it.

Source compatibility with ObjectARX has never been our goal. We have a better API than ARX in many respects—for example, client code using our libraries is generally cleaner and more compact than ARX code due to our smart pointer usage, exception handling, and other features. We also run on every major UNIX platform, while ARX is Windows-only. Out of 1000+ member companies, we of course have individuals who would prefer to see us move in a slightly different direction on specific issues—but overall we do a good job of finding solutions which provide maximum benefit for the majority of our membership.


I look forward to meeting Neil once again at the first ODA World Conference in Leiden, Holland this April.

Recession and the CAD Media

With Cadalyst going down under, things do not appear to be looking good for the CAD media. Today I got yet another email from yet another publication asking me read stuff like "When the Going Gets Tough, the Tough Don't Skimp on Their Ad Budgets" and "Don't Let Hard Times Derail Your Advertising" and then buy some ad space. I couldn't help but notice that the frequency of such emails has increased significantly over the past month or so.

SYCODE is a tiny company making tiny plug-ins. We have never advertised in the past and do not have plans of advertising at present or in the near future. So this can mean one of two things. Either we are getting famous or they are getting desperate. I hope it is the former, for their sake and ours.

Mesh To Solid for Bricscad

Today SYCODE released Mesh To Solid for Bricscad, a DRX plug-in that gives Bricscad the ability to convert polygon mesh objects to 3D solids. Full press release here.

If you have been keeping track of this blog, I guess by now you have already figured that we are going ahead all guns blazing with our DRX development. Some of you may be wondering why we did not use the easier and faster approach of simply recompiling our existing AutoCAD plug-ins with the ObjectARX source compatible BRX SDK offered by Bricsys. That way we could arrive at Bricscad plug-ins in minutes, instead of taking weeks to rewrite them from scratch using the DRX SDK.

We have our reasons. Firstly, we would have to do it anyways to support IntelliCAD 7 when it is finally released. Same goes for other DWGdirect hosted applications which we are currently investigating. But most importantly, we used the DRX approach because we are seriously contemplating developing our own DWGdirect hosted applications. Don't worry, we are not going to develop another AutoCAD clone. There are far too many of them already. We have a few standalone applications that we are thinking of rewriting using the DWGdirect SDK. In doing so, the same DRX plug-ins that were are developing for Bricscad will be able to load and run in our standalone products as well.

Ralph Grabowski's recent comment about the ODA being the most important organization in the CAD world makes a lot of sense to me. I have always maintained that the ODA does not only offer libraries to read and write DWG files. They offer much more. They offer components that can be used by CAD software developers to write full blown professional applications, complete with plug-in architecture, visualization and the works.

Imagine a day when ODA members start building (or rebuilding) their products using the DWGdirect SDK and professional third party developers like me, in-house programmers, freelance programmers, students or just about anyone with programming knowledge use the free DRX SDK to build DRX plug-ins that work in all these DWGdirect hosted applications. It will be more like an ecosystem wherein intellectual property is shared across boundaries and put to best use without having to reinvent the wheel.

At SYCODE we develop plug-ins for more than a dozen CAD systems. The development process and code varies wildly with the CAD systems. Consider this. We have SketchUp SKP file import plug-ins for eleven CAD systems and if you look at the code, they are all completely different from each other. It would be great if we were able to write one plug-in that would work in all eleven CAD systems. Of course, that is not possible because there is no one standard CAD platform that CAD software vendors use. But the DWGdirect SDK is something that comes close to such an ideal situation. Smaller companies like mine that do not have the time, money and resources to develop their own CAD platform can use the DWGdirect platform as a base to build their products. Companies with in-house programming staff that develop custom software solutions for themselves, can do the same. They can build a bunch of DWGdirect hosted applications for various tasks and then build DRX plug-ins to extend them and share them across the company or even outside the company.

Maybe I am talking crap. But then, maybe I am not.

Point Cloud for Bricscad

Today SYCODE released Point Cloud for Bricscad, a reverse engineering plug-in for Bricscad, another clone for a clone.

I will be visiting Bricsys in Belgium after attending the Open Design Alliance World Conference in Holland. I look forward to meeting the programmers who have been working overtime to make Bricscad one of the best AutoCAD clones out there. Apart from congratulating them I am also going to wish them the best of luck because Autodesk has gone ahead and added some fancy stuff in AutoCAD 2010, which they will need to ape if they want to keep their Bricscad-AutoCAD feature comparison chart looking good.

On the other hand, IMSI is playing it safe with DoubleCAD. Unlike Bricsys and other ITC members who call their software an "alternative" to AutoCAD, IMSI is calling DoubleCAD a "work-alike". In their words, "Both DoubleCAD XT and XT Pro work like AutoCAD LT -- that is, you'll see a familiar menu bar, menu items, drawing tools, modify tools, command line, even a familiar intelligent cursor". I believe IMSI is cleverly handing itself a longer rope by stating that DoubleCAD is not an AutoCAD clone, thereby not obliging itself to offer everything that AutoCAD 2010 does.

But as far as keeping up with AutoCAD 2010, IMSI appears to have an edge as they have already added constraints to DoubleCAD, a key enhancement in AutoCAD 2010. This also shows that IMSI has more freedom and flexibility in adding new features to its products. They already had a constraint plug-in for AutoCAD called IDX Variable Constraint System which I guess found its way into DoubleCAD. This was made possible because they decided use their own proprietary file format for DoubleCAD called 2CD and not DWG like like other AutoCAD clones. They did not have to wait for the ODA to reverse engineer the 2010 DWG format in order to add constraints to DoubleCAD. Similarly, in order to add other AutoCAD 2010 enhancements (like the subdivision mesh), IMSI will not need to wait for the ODA to come up with a solution. And in the unlikely event that the ODA is not able to deliver, they can go ahead and develop it themselves.

So looking at this from various angles, I see three kinds of companies and their approaches:

(1) Members of the ITC who rely completely on the ITC for their products, which in turn relies on the ODA to do the hard work of cloning the underlying AutoCAD technologies. Here they need both the ODA and the ITC to deliver to get a product that they can sell and this can be quite frustrating.

(2) Companies like Bricsys who rely only on the ODA for the underlying technologies and which build their products themselves.

(3) Companies like IMSI who rely on the ODA for core technologies but are free to go ahead and develop their own technologies if required. They build their products themselves and can add new features faster since they are not restricted by the DWG file format and the ability of the ODA to crack it.

Frankly, I do not see much difference between the words "clone", "alternative", "work-alike" or whatever fancy terms these companies use in their marketing. All they are trying to do is get AutoCAD users to switch to their product, that all.

IMSI and Bricsys are attacking Autodesk on two fronts. IMSI is after the more meaty AutoCAD LT customer base by offering DoubleCAD XT Pro (which they claim is better than AutoCAD LT) for half the price. See their comparison chart. AutoCAD LT cannot be extended by means of plug-ins and neither can DoubleCAD, although that may change in the future. On the other hand, Bricsys is after customers of the full blown AutoCAD by trying to convince third party developers like myself to port our existing AutoCAD plug-ins to Bricscad. They also offer a Classic version of Bricscad which counters AutoCAD LT. But unlike AutoCAD LT, Bricscad Classic can be extended by plug-ins, which makes Bricsys products quite interesting to users of AutoCAD or LT who are contemplating making the switch.

Now since we are in the recession mood lets look at something very important - pricing. AutoCAD LT is priced at $1200. DoubleCAD XT Pro is almost half at $700. Bricscad Classic is almost half of DoubleCAD and is one third of AutoCAD LT at $400. And considering that you can extend Bricscad Classic with plug-ins it certainly looks like a steal. As far as the full blown AutoCAD is concerned, you do the math. And while you are at it, you may want to factor in subscription as well.

TerrainCAD for Bricscad

Today SYCODE released TerrainCAD for Bricscad, a DRX plug-in similar to TerrainCAD for AutoCAD. So that makes it a clone for a clone. Funny, but that is precisely what Bricsys is trying to do - encourage third party developers like us to port our existing AutoCAD plug-ins to Bricscad. Two words on the Bricscad V9 splash screen sums up their strategy - "Enabling Applications".

It is no secret that the "Powered by IntelliCAD 6 Technology" is going to soon disappear from the splash screen as Bricsys proceeds to severe it ties with the IntelliCAD Technology Consortium. And rumor has it that another ITC member may be walking out of the door.

I believe IntelliCAD 7 is going to be a make or break release for the ITC. All the members I met at the ITC World Meeting in Athens were very enthusiastic about IntelliCAD 7. What surprised me was that most of them were skeptical as well.

I am eagerly waiting for IntelliCAD 7, although I know it is going to be a long wait. Our DRX plug-ins will be ready when IntelliCAD 7 is. It is left to be seen whether the ITC members will repeat the old IntelliCAD 6 mistakes and mess around with the core IntelliCAD code.

I have taken a decision. Any ITC member coming up with a non-standard version of IntelliCAD 7 can take a hike. At SYCODE we will not build variants of our DRX plug-ins to suit their variant of IntelliCAD 7. Period.

SpaceClaim Engineer and Style

Last Friday, the CEO of SpaceClaim, Chris Randles, co-founder Blake Courter and I sat down together on opposite sides of the planet for a briefing on the new version of SpaceClaim. We had a very interesting discussion on SpaceClaim technology and its business model, or rather the change in it's business model.

Chris wanted to clear the prevailing confusion about SpaceClaim in the market. He started out by explaining the SpaceClaim vision of expanding the market for 3D. According to him, SpaceClaim is not interested in replacing existing MCAD systems. Rather it is looking at putting 3D into the hands of new customers. Sounds familiar to me. When SpaceClaim appeared to the scene, that was precisely their plan. I remember they arrived at a number for non CAD users - 4 million. They claimed that there were approximately 5 million people involved in 3D product design and only 1/5th of them were exposed to existing CAD software.

This is what I wrote on 4th December 2007 ("SpaceClaim Changing Direction - Finally"):

"SpaceClaim has been trying to woo the 4 million non-CAD users by offering them a full featured CAD system for a price of a full featured CAD system when they do not need a full featured CAD system. And then they start by not offering a trial but rather by giving online demos to all 4 million of them. And finally they allow customers to only rent the software, not purchase it. I cannot think of anything more that could be done wrong."

Those comments were based on SpaceClaim's plan at that point in time of selling their software to people like marketing executives so that they could flash out their laptops and impress prospective customers by pushing and pulling faces of a 3D model.

Little wonder that I found a particular bunch of numbers on a particular slide of Chris' presentation particularly interesting. SpaceClaim now claims that there are 15 to 25 million engineers in manufacturing worldwide and 3 to 5 million of them are in need of 3D tools in areas of industrial design, design engineering, simulation & analysis and manufacturing engineering.

So the 4 million non-CAD users that SpaceClaim was talking about two years ago sits nice between the 3 to 5 million engineers that it is trying to sell to today. But what has changed is the purpose for which these people are going to use SpaceClaim. The word used back then was "modify". SpaceClaim was being touted as a fantastic tool by which any inexperienced user could modify geometry, not create it.

This is what I said on 25th October 2007 ("SpaceClaim Finally Gets It"):

"SpaceClaim Corp. considers itself as a 'leading provider of CAD-neutral modification solutions to the extended product development team'. The keyword here is 'modification', which implies that the target company already has a CAD system that has 'created' their models."

That just changed. SpaceClaim is now being marketed as a MCAD system to "create" geometry, not just "modify" it. And they have adjusted the product names to reflect this change. "SpaceClaim Professional" is now "SpaceClaim Engineer". Priced at $1,995, it is being targeted at engineers, not just for design and manufacturing engineering applications, but also for conceptual engineering (creating geometry) and conceptual analysis (analyzing the created geometry at concept level).

"SpaceClaim LTX" is now "SpaceClaim Style". Priced at $895, it is being targeted at people doing industrial design, product styling, furniture design, jewelry design and architectural detailing. Clearly almost all of this involves "creating" geometry, not just "modifying" it. So looks like SpaceClaim has finally come around to admitting that their software is good for creating geometry. After all they now have an entire product designed just for that.

To me it was quite obvious that SpaceClaim Style is a direct competition to Rhinoceros as it is being targeted to almost same people McNeel does and is priced almost the same (actually $100 lesser). Chris was quick to clarify, "We share an excellent partnership with McNeel and SpaceClaim Style is a great companion to Rhino. Rhino does some real nice surfacing stuff with curves. I don't think Bob McNeel is losing sleep on SpaceClaim Style". Yeah, right. However, it is important to note that SpaceClaim Style does not come with an API. So you cannot extend it using add-ins like how you can extend Rhino.

The new features in 2009 include

(1) A new ribbon tab called "Prepare" containing model preparation tools detect and repair problems with imported designs and simplify models prior to analysis.

(2) Increased surfacing power for highly-stylized designs that include swept multi-curve blends, n-sided patches, surface curves. So now you know why I think Rhino has competition.

(3) Enhanced analysis tools for industrial design visualization and manufacturing validation that include curvature, zebra stripes, dihedral angle and draft analysis.

(4) Improved translators. 3D PDF's can now be opened and edited. You can even open tessellated (mesh) formats for visualization. The word to note here is "visualization". You cannot edit the imported mesh formats since they are not imported as solids. SYCODE's mesh file import add-ins for SpaceClaim create solids that can be edited using SpaceClaim's fantastic direct editing tools.

SpaceClaim is available in English, German, French, Italian, Japanese, Chinese and Korean.

SpaceClaim is now offering a flexible platform for custom 3D solid modeling applications. Just so that you know, McNeel also offers Rhino as a platform for custom applications. They call it the Rhino Application Platform.

I asked Chris what he thought about Autodesk's VP of CAD/CAE for Manufacturing Solutions Andrew Anagnost's view that SpaceClaim's direct-modeling-only approach is a dead end - unless SpaceClaim add parametrics. Chris reiterated that SpaceClaim is the only pure direct modeler was quite skeptical about Autodesk's claim to "fuse" direct and parametric seamlessly into a single environment. "They have the liberty of making tall claims since they have do not yet have a released product". When I asked Blake Courter whether SpaceClaim would consider adding parametrics to SpaceClaim in the future, he said, "SpaceClaim has excellent parametric capabilities that are a key part of our user interface and how we integrated with analysis tools. We think direct modeling and parametrics can work well together, but the marriage of history and direct modeling is not something that makes logical sense to us."

Ever since SpaceClaim appeared on the scene, people (me including) have been talking about when they will be bought and by whom. I wanted to hear it directly from the horse's mouth. So I asked Chris. "I have not heard anything to that effect", he quipped. "SpaceClaim is on solid footing. In these bad times when money is not easily available, we are getting ready for another round of funding. This goes to show that our investors are strong and believe in what we are doing."

To see a screenshot of SpaceClaim Engineer click here.

Update: Blake Courter has in formed me that mesh import has been postponed to SP1.

The Plan

I come from an average middle class Indian family and my life appears to be following pretty much the standard plan. When you are in college, you have all these wild things that you want to do and have all the time in the world to do them and but cannot because you have no money. You then take up a job and start making some money. Most of us join the rat race and work our asses off for someone else till we retire. A very few of us (like me) break out from the rat race, become entrepreneurs and make others work their asses off for us. Unknowingly, I have ended up working my ass off far more for myself, than what I would be doing if I were still in the rat race. At this stage in life, while I have all the money in the world to do the wild things that I wanted to do when I was “young”, I simply cannot find the time to do it. According to the plan, this will go on till I retire. At that point, I will have all the money and time at my disposal, but my screwed up health will make it physically impossible for me to do the wild things that I wanted to do for all these years.

I don’t like this plan and I have decided to do something about it. Iron Maiden is coming to Bangalore this Sunday and I am going to see them live in concert. I have found an equally frustrated friend who does not like the plan either. We plan to keep our wives and kids at home, fly our asses to Bangalore, stay in the best hotel, get ourselves stoned, find a place in the mosh pit, headbang till we can do it no more and fly our asses back home.

This sounds like a much better plan. My ultimate wish is to see Pink Floyd live in concert before I die or before they die, whichever is earlier.

PTC World - Product Development System

It is quite normal, even fashionable, for a company to coin a fancy phrase and use it to differentiate itself from the competition. Autodesk has "Digital Prototyping", Siemens has "Synchronous Technology", and so on. PTC is no different. Yesterday, at PTC World in Mumbai I learnt about something called "Product Development System" or PDS, and is comprised of 5 C's - Create, Collaborate, Control, Configure and Communicate.

Now I tend to look at this kind of marketing and posturing stuff with a bit of skepticism because such phrases are often (if not always) the brainchild of some well paid marketing genius. But before discounting something like this it is important to understand the underlying message that it being put across, if there is one in the first place. PTC made that message very clear and easy to understand at PTC World. Instead of slide after slide with boring bulleted text and convoluted graphs and diagrams, they gave us a demo - a very different kind of a demo. A demo in which there were many presenters and was more like a role playing game. The demo lasted for 45 minutes but I will try to size it down for you. It will be interesting to see if you are able to figure out PDS on your own after I am done with the demo.

First a little background. PTC offers 6 main products or product lines:
(1) Pro/ENGINEER - for product design (not just CAD, if you know what I mean)
(2) Windchill - for process management (to streamline your business processes and manage your design data)
(3) Arbortext - for content publishing (technical illustrations, service manuals, etc.)
(4) Mathcad - for engineering calculations (basically Excel on CAD steroids)
(5) ProductView - for visual collaboration (a vital link between Pro/E and Windchill)
(6) CoCreate - for lightweight direct modeling (something I am very excited about)

There is a seventh product called InSight which will see the light of day shortly. It is a result of the recent acquisition of Synapsis Technology and deals with product design with an eye on environmental standards and other regulations. With the exception of Mathcad the other five products will have a role in the demo.

The demo is about two fictitious companies - Mega Loaders, an OEM that manufacturers heavy earth moving equipment and its supplier InGauge Electronics that designs and manufacturers electronic components. The program manager at Mega Loaders loads a 14,000 part assembly of a earth mover designed in Pro/E into ProductView and sees the big picture. InGuage has just bagged the contract to design the instrument panel on the dashboard in the driver's cabin. So he fishes out the required reference geometry for the assembly that InGuage will need and uses Digital Rights Management to set the required levels of access for InGuage to complete the project. He then checks the data into Windchill. The Engineering Manager at Inguage checks out the data from Windchill and distributes it within his organization. The Mechanical Engineer designs the housing and does various simulation tests for strength and vibration. He works closely with the Electrical Engineer who designs the PCB, all the time checking in and out CAD data from Windchill. The Manufacturing Engineer creates a BOM for mannufacturing and modified his manufacturing plan to factor this new project. He notices a problem with an assembly fixture and quickly fixes it using CoCreate. The CAM Programmer checks out the final part file and creates the NC toolpath and documents the process for the shop floor. All these tasks by various people are performed by the different modules of the Pro/ENGINEER product family. So there is absolutely no loss of data in translation.

While all this was going on, the technical writer at InGuage checks out the data from Windchill into Arbortext and created exploded views and service manuals using a template supplied to him by Maga Loaders, publishes it to the required formats and checked it back into Windchill.

Simultaneously, the Program Manager at MegaLoaders has been keeping a close watch on the happennings at InGuage. After getting the outsourced design he integrates it into his mamoth digital mockup and does his own tests to verify the design. And thats when the shit hits the celing. Using the Pro/E Manikin extension (basically a digital human modeling an simulation tool), he notices that a bunch of levers interfere with the operators right hand when he goes to operate the buttons on the panel. To solve the problem, he makes a decision to move the buttons from the right side to the left side of the panel. He then lets InGuage know of the change and reminds them that they need to stick to the original schedule.

At InGuage the Engineering Manager, instead of swallowing hard, stays calm in the face of unexpected change. He reviews his customer's request and charts a new course for his team. The Electrical Engineer reviews the new PCB layout, captures the change, verifies the change proposal and checks it back in for the Mechanical Engineer to check whether his assembly interferes with the new PCB layout. As it turns out it does interfere and he quickly adjusts his design. He quickly reruns his simulation tests for strength and vibration and checks the data bask into Windchill. The Manufacturing Engineer learns about the late change from Engineering and updates his manufacturing plan in an instant thanks to the associativity maintained across the entire system. The CAM Programmer gets the new part and in a mouse click arrives at a new toolpath, with no rework required. Meanwhile the Technical Writer simply drags and drops the new part into Arbortext and all his illustrations are updated automatically.

The Engineering Manager knows very well that nothing can afford to go wrong at this late stage and keeps a close watch on happenings from a single vantage point using Windchill. After every member of his team played out their part he finally releases the project on-time and on budget and they all live happily ever after.

So whats the moral of this story? I believe the moral is PDS. As the name suggests PDS is quite simply a "system to develop products" wherein smooth and accurate flow of data is the key to success. With PDS you get everything under the single PTC roof and do not have to waste time and resources figuring out ways to get data from one system to another and take the risk of getting some of it lost in translation. Windchill is the key ingredient in PDS and binds other systems in a seamless fashion. I don't care what PTC marketing calls this, but if this works the way they claim it does, then this is exactly what engineers need. And I believe this example sums up what PTC believes is Product Lifecycle Management, probably one of the most debated three letter acronyms out there.

This precisely the reason why "smaller" Pro/E users are going head over heals over ProductPoint. With ProductPoint they are looking to ease the bottlenecks in their own systems to develop products.

In a private conversation, Ashutosh Parasnis, the Managing Director of PTC India, made it pretty clear to me that PTC has acquired and would continue to acquire companies that help add to their PDS. I spoke to half a dozen top PTC executives and asked them about the rumors of PTC being on sale. PTC's India Country Head, Rafiq Somani's answer pretty much sums it up, "Look at our numbers. Look at our growth. Clearly these people don't know that they are talking about."

As regards adding direct editing capabilities to Pro/E, Ashutosh Parasnis said that they would consider it if it became a priority for their customers. He said, "As of now, customers have far more important and pressing problems which we are trying to solve."

I asked Rohit Biddappa, Senoir Manager - Marketing, about PTC's marketing strategy, while comparing it to the likes of Autodesk and SolidWorks. He said, "We can easily do what they are doing and go ahead and create FUD (Fear Uncertainity Doubt). But we believe that is not what counts in the end. We know that we are technically far superior than our competition. The EADS PLM benchmark say it all. Even a phone call from the French President to EADS could not stop them from awarding the contract to us, instead of Dassault. Customers are not fools and can see through most of the guerrilla marketing that's going on."

My flight back to Goa leaves in three hours. However, judging by the perpetual state of chaos that Mumbai finds itself in, I had better leave for the airport sooner than later.

PTC World - The Speeches

I just got back to my hotel after attending PTC World, the annual PTC user meeting held at the Hyatt Regency in Mumbai. Truth be told, I do not know much about PTC or its products and this event was my first step towards the due diligence I promised myself to undertake. In April, after attending COFES in Arizona, I will be visiting the PTC headquarters at Needham, where I intend to meet more PTC employees, especially the technical people.

I was really looking forward to meeting Jim Heppelmann, PTC's CTO (actually Jim's title is Executive Vice President, Chief Product Office and Member of the Board of Directors). But unfortunately due to personal commitments, Jim could not make it to PTC World. Instead, they played a short video of him wherein he briefly touched upon the things he wanted to say. I hope I get a chance to meet him in Needham.

The day started with Rafiq Somani, PTC's India Country Head, giving his opening remarks. Rafiq joined PTC as a marketing executive 13 years ago and rose to be the Country Head. He spent a major part of his speech on the ongoing recession. He was of the opinion that things are not all that bad, at least not in India. And I agree with him. Today the Times Of India reported that this year India will grow at 7.1% as opposed to the 9% that we were growing for the past couple of years. This is far better than zero or negative growth which is direction that most of the world is headed.

Next up was Peter Schmidt, Senior VicePresident - Emerging Geographies. Peter spent a good part of his speech explaining how PTC uses a process-centric approach, which means that its products are designed keeping the customer's processes in mind. At that time, I didn't quite understand what he meant, but later in the day, as I saw other presentations it all became more clear to me. He took the opportunity to take a dig at Dassault Systemes on the Airbus fiasco. He explained how after the goof up, EADS invited 5 companies to test a PLM benchmark to ensure that it would never happen again - Dassault, Siemens, Oracle, SAP and PTC. Apparently, Oracle and SAP crashed out early in the game and Siemens came close. But PTC passed the benchmark test and eventually bagged the contract. In Peter's words, "nobody can beat Windchill and the PDS system from PTC at the moment if the customer does a deep technical investigation".

And that pretty much sums up the general feeling of the people at PTC World, both PTC employees and customers. I spoke to many customers throughout the day. While some had reservations on pricing (this is India, remember), not a single one I spoke to bitched about the software. I also got the sense that customers were quite happy with the service as well. One could argue that unhappy users usually don't come to such events. But consider this. PTC has about 2,200 customers in India. Thats 2,200 companies not licenses, and 500 people attended the Mumbai event. Assuming 500 more will attend the Delhi event on the 12th, you can do the math. At least in India I guess you can say that PTC appears to be keeping its customer happy.

Next up was Ashutosh Parasnis, the Managing Director of PTC India and the man in charge of the 1000 odd employees at PTC's Pune office, a two hour drive from Mumbai. In fact, 20% of PTC's global development force sits in the Pune office and Ashutosh has been leading them for the past 5 years. He filled in for Jim Heppelmann and delivered the keynote speech on PTC's Technology Vision. He spent quite some time on PTC's upcoming product called ProductPoint. ProductPoint is a lite version of Windchill, PTC's PLM solution, and is based on Microsoft's SharePoint. It does not replace WindChill, and is being targetted at customers that have 3 to 5 licenses of Pro/E, in his words "the kind of people who find Windchill too overwhelming". This will allow them to work effectively with users of Windchill, and it can be later upgraded to WindChill itself. Apparently there was a "phenomenol response" to ProductPoint from beta customers who are already wanting to order even though the product is not yet launched.

Ashutosh let us know about the new Customer Visit Center in Pune (the third after the ones in Needham and Shangai) where customers can directly interact with R&D and Technical Support staff. He announced that Pro/E WildFire 5.0 is expected to be launched in June 2009. According to him, the product is ready but the launch has been intentionally delayed because PTC has decided to wait for ProductPoint and launch both simultaneously. He also mentioned that they have shaken the Pro/E product mix a little. The base version (Foundation XE) will now come with more features, stuff that was part of the modules of the higher versions.

Regarding Windchill, he reported that WindChill was gaining market share and displacing the competition. Later, in a private conversation with me, he laughed at how people called Windchill "vaporware" when it was first launched. Ashutosh also mentioned to me about PTC's intention to unify the GUI's of their products with the Microsoft Ribbon interface. ProductPoint has already inherited the ribbon from Microsoft SharePoint, on which it is based and other products could be "ribbonized" sooner than later.

It's past midnight and I think I will crash out for the night. Watch this space. Today I learnt a little more about PTC, its people and its products and I hope to write a little more about them. There is also another thing I learnt about the company. PTC is not very blogger friendly. I had to fly my sorry ass 600 kms from Goa to Mumbai and park it in a hotel at my own cost for two nights. And tommorow I fly it back to Goa.

DoubleCAD XT

IMSI has finally launched DoubleCAD XT, what they call "an AutoCAD LT work-alike, but free". A professional version called DoubleCAD XT Pro is on the way and will cost $695. They are calling it "an AutoCAD LT work-alike, but better, for about half the price".

Clearly the plan here is to hit Autodesk where it hurts them the most - AutoCAD LT, Autodesk's cash cow. I will let IMSI explain their strategy in their own words:

"We're trying to shake up the CAD world. We won't do that unless we have something special.

DoubleCAD™ XT is a full-powered 2D CAD application -- one that you already know how to use -- and is free with none of the usual limitations:

We're not constraining printing, saving, file sizes... we're not including untimely time-outs... we're not even constraining the software license -- our free DoubleCAD™ XT can be used for unlimited personal and commercial use.

Our hope is that as you need even more power, you'll consider upgrading to our enhanced DoubleCAD™ XT Pro product or DoubleCAD™ plug-ins as available."

So their plan appears to be two fold. First get Autodesk customers to dump AutoCAD LT and use the free DoubleCAD XT instead. Next, wait for these former Autodesk customers to upgrade to the Professional version.

IMSI is ramping up the rhetoric a notch by calling their free DoubleCAD XT an "upgrade" to AutoCAD LT since they claim that it has more features. But here is an interesting twist. IMSI claims to be targeting only AutoCAD LT users, not those of the full blown AutoCAD. In their own words:

"Whether you like or dislike Autodesk, AutoCAD® is the standard. As such, our goal is simply to be a better companion to AutoCAD® than AutoCAD LT® is. We've done this by creating one product that's dramatically better than AutoCAD LT® (XT Pro)... and another that's dramatically less expensive (XT free)."

This can be seen from the fact that the free and professional versions of DoubleCAD XT do not have support for plug-ins or LISP, which is one of the main advantages of AutoCAD over LT. However, IMSI intends to add plug-in functionality to DoubleCAD (I am assuming professional only) in the future.

IMSI is also taking a dig at IntelliCAD. According to them:

"ITC-based products have had reliability and robustness issues over the years and, except for a few niche exceptions, have failed to gain traction in the marketplace. ITC-based products target AutoCAD® and rarely try to surpass or innovate."

As far as the change of name from A/CAD to DoubleCAD, that happenned because big daddy Autodesk threatened to sue IMSI. So I guess someone is beginning to feeling the heat.

So the big question is: "Will this plan work?". Well, it all depends on three factors:

(1) whether the software is as good as AutoCAD LT, if not better

(2) whether it is stable (and this is very important)

(3) whether IMSI can take on Autodesk Marketing (this is largely dependent on 2)

Looks like the global economic crisis has come at the right time for IMSI. It will be interesting to see if they can capitalize on it.

As IMSI says, "Why pirate -- when you can be legal -- for free."

The Future of DRX

I have been making a decent amount of noise on this blog about ObjectARX, DRX, ObjectDRX, BRX, IRX and the like. Today at SYCODE we actually went ahead and did something about it. Today we released 20 data exchange DRX plug-ins for Bricscad.

For the past year, I have been keeping a close eye on Bricsys, a member of the IntelliCAD Technology Consortium. They seem to be moving much faster than most ITC members in terms of adding features to their flavor of IntelliCAD. This is because they have been doing parallel development of their own, something which most of the ITC members I met at the IntelliCAD World Meeting in Athens told me was a foolish thing to do. It appears that Bricsys were not that foolish after all. From what I see Bricscad is almost where the new IntelliCAD 7 is going to be a year from now.

SYCODE already offers plug-ins for IntelliCAD 6, the current version which by the ITC's own admission is quite buggy. These plug-ins are the old style SDS DLL's and are a nightmare to develop and maintain. Clearly the future is DRX - the technology developed by the Open Design Alliance which is the backbone of the new IntelliCAD 7 and other AutoCAD clones. Initially we had planned to freeze DRX development till IntelliCAD 7 was released. But seeing how far Bricsys has progressed with Bricscad, we decided to take the leap and begin DRX development with Bricscad V9. In fact, these 20 DRX plug-ins work with Bricscad V8 as well because V8 was the version that Bricsys initially added DRX support.

Another ITC member, ZWSOFT from China, also "allegedly" supports DRX in their flavor of IntelliCAD called ZWCAD. See my previous post about ObjectDRX. The problem with ZWSOFT's implementation of DRX is that they have taken the source of the DRX SDK from the ODA and recompiled it for use in their product. This is precisely how the ITC members messed up IntelliCAD. Third party developer's like ourselves ended up creating different SDS plug-in DLL's, one for each flavor of IntelliCAD. This drove us crazy to a point that we decided to stop further development on IntelliCAD 6 itself. I hope history does not repeat itself with DRX. I definately do not want to see different flavors of the DRX SDK floating around. In my opinion, this is exactly what will happen if someone with vision does not step in and show some leadership.

And by someone I am referring to the ODA, more specifically its president Arnold Van Der Weide, a person who headed the ITC not too long ago. In his keynote address at the IntelliCAD World Meeting in Athens, Arnold regretted giving a free hand to ITC members during his tenure as president and let them do what they wanted with the IntelliCAD source. It would be sad if he allowed the ODA to go down the same road.

But I have hope. ZWSOFT's previous version of ZWCAD, a version called 2008i, came with the entire DRX SDK, complete with ODA copyright notices and all. I have no idea how the ODA allowed that to happen. However, their current 2009 version no longer comes with the DRX SDK. At least the trial I downloaded did not have it. I am not sure whether anything transpired between the ODA and ZWSOFT. But if it did, then it is a good sign.

I believe that there must be only one source for the DRX SDK and it should be the ODA. If any ODA member wishes to take the DRX source and screw around with it, they should not be allowed to call it DRX anymore. I am not sure whether that will prevent them from creating their flavor of DRX anyways, but at least third party developers will be able to tell their customers that their plug-ins will work with authentic DRX enabled applications only.

I am not talking crazy here. Take Bricsys for example. The 20 DRX plug-ins that we released today were built using the free DRX SDK supplied by the ODA. They load and run perfectly in Bricscad V8 and V9. I don't care if Bricsys used the original DRX source code or a modified version, as long as Bricscad loads and run our DRX plug-ins built using the ODA's free DRX SDK. And to make my point, Bricsys decided to make an ARX source compatible SDK. They could have simply gone ahead and modified the original DRX source code. Instead they came up with a a new SDK and called it BRX, which I believe simply wraps around the original DRX SDK.

I urge the ODA to institute a certification program wherein plug-in developers can get their DRX plug-ins certified directly by the ODA. And this is precisely what I am going to gun for at the ODA World Conference in April in the Netherlands. Even if it means that I have to corner Arnold in an elevator and mind ram him for an hour.

I believe that the future is DRX, but I wonder what is the future of DRX.