Autodesk Visit – Interview With Kevin Schneider

Kevin Schneider is responsible for Inventor Fusion among other things. He is one of many Autodesk employees that I have corresponded by email and phone for years but have never met in person. And this continues to be the case because I interviewed him through one of those fancy Cisco TelePresence systems.

Click image for larger view

The only things we could not do was shake hands and exchange business cards. But apart from that it was as if he was sitting right opposite me. This is part of our conversation:

Deelip: What do you make of SolidWorks V6?
Kevin: Well, our competition is simply chasing the work that we have done. We have been saying all along that the parametrics and history are important to the user and their integrity must be maintained. From the face of it, it looks like they are trying to do the same thing.

Deelip: How about Inventor on the cloud?
Kevin: As you can imagine, putting something like Inventor on the cloud can easily become a complicated task. Having said that, the benefits of cloud computing are just too huge to ignore. We are working along those lines.

Deelip: Why is Inventor LT available in select countries only?
Kevin: I am sorry, I do not know the answer to that question. I am sure Autodesk PR will be able to get the answer for you or connect you with someone who can provide you with an answer.

Deelip: Recently, a SolidWorks product manager admitted that backward version compatibility was more of a business problem and less of a technical problem. Is that the case with Inventor as well?
Kevin: In our case, it is a technical problem. We added two new features to Inventor 2010 which cannot be saved to an Inventor 2009 file.

Deelip: Are you happy with the way the press covered Inventor Fusion?
Kevin: I am happy with the vast majority of coverage that Inventor Fusion received. As a CAD vendor, I will obviously want all the press about my product to be good. But as you can imagine, that cannot always be the case.

Deelip: Do you think a $97 Alibre Design will be a problem for Inventor or Inventor LT.
Kevin: Inventor LT was free on Autodesk Labs for two years. Even after that, a large number of users paid money to buy a license when it came out of Labs. This goes to show the kind of value that investment in terms of cost and time that our customers are willing put into our products, whether they may be free or otherwise.

Deelip: What was the logic in shipping the Inventor Fusion Technology Preview 2 in two parts – a standalone product and an add-in?
Kevin: We wanted our users to be able to install and uninstall Fusion easily at any time. Moreover, we did not want Fusion to affect the production environment of our users.

Deelip: Will Inventor Fusion Technology Preview 3 be shipped in two parts?
Kevin: Yes, it will.

Deelip: I raised this issue about packaging on this blog earlier. Because Fusion is a different application, the Change Manager needs to figure out multiple changes at one go as opposed to one at a time, like the way it will eventually work. This causes the Change Manager to fail a significant number of times. I am questioning the wisdom of giving a software to people to test in a form that it will not be when eventually delivered. Not only will the feedback you receive be negative due the Change Manager not being able to handle multiple changes at one time, but it will also be inaccurate since users will report failures when in reality the Change Manager actually works if it has to figure things sequentially.
Kevin: Yes, you have a point there.

Deelip: May I suggest something?
Kevin: Sure. I would love to hear it.

Deelip: When I was testing my theory of the Change Manager failing for multiple changes I used to keep Inventor as well as Fusion open side by side. After each change, I used to save out the file from Fusion and open it in Inventor for the Change Manager to kick in. Then I used to save the file in Inventor and open it in Fusion and repeat the whole process for every change. I found that doing this resulted in a way higher chance of the Change Manager succeeding because this is typically the workflow that the system would use anyways. So my idea is to simply try and automate this task for the user. Let the user have both applications open. When the user makes a change in Fusion, automatically start the Change Manager in Inventor and send the data back to Fusion after the change has been factored in the feature tree. This way users testing Fusion will correctly report failures and you will get high quality feedback that you can work with.
Kevin: I think this is a great idea. I think it is possible to do this and we will consider it.

  • Deelip, great post. I know we have discussed this before, but your suggestion at the end puzzles me. Why would anyone want Inventor and Fusion running at the same time? Why wouldn’t the user just stay in Inventor? The only reason that I can come up with for a user to go to Fusion for an edit is if in fact the desired edit is not possible in Inventor based on the structure of the tree. If the structure of the tree does not support the edit, Change Manager will fail and a direct edit will be added to the bottom of the tree – as with direct edits in any other history-based system. So why Fusion? Do you suppose people find direct modeling more intuitive than history-based modeling, but they are not yet ready to turn loose of the tree? Kind of like training wheels :<)

  • Paul,

    This two part thing (standalone + add-in) is only a stop gap solution to the real thing. When Autodesk is done with this the Fusion standalone application will not exist and everything will happen within Inventor itself. I am simply trying to suggest a better user experience while they are still developing/testing their stuff out.

    The Direct Modeling demo that we were shown at SolidWorks World seemed to do exactly that. My feeling is that is where Inventor is headed as well.

    The thing with this approach is that the user really gets the best of both worlds. He gets to maintain his design intent and gets modeling freedom as well.

  • Actually my basic question applies whether the two components are standalone or integrated – but I do better understand your suggestion.

    I find it interesting how quickly we relate design intent to the history tree. And what happens to this so called design intent when the system starts adding, removing and modifying features in the tree – automatically? What decision criteria are being used by the Change Manager to ensure my design intent is being maintained?

    I see a lot of CAD companies trying to make/manipulate history-trees out of nothing but geometry. When the tree is automatically generated and manipulated, how can it possibly represent my design intent? If capturing and maintaining design intent is the key value to history-based modeling – hummm, there are much better ways to capture design intent in 3D models than with the history tree.

  • I think you have to be careful making it sound like non-history technologies are just for ease of modeling. There are other problems being solved too – recompute times, broken history trees, badly captured design intent, etc.

  • Paul,

    You make a very valid point. History tree is about capturing design intent.
    That is how most experienced designers use it. The idea of divorcing geometry from intent is a bit silly – except when the end product is a purely visual artefact that need not be re-worked.