So I think the news it out already, but Harry Madison (one of the most talented Revit API developers out there) has started his own blog and consulting business for developing Revit API tools.
He has put out a freebie on the Revit Exchange "Image-O-Matic". Which is a nifty little tool to generate an animation of a parametric family. There are a number of interesting possibilities with this tool, you could make a cool family such as the one Harry used for his demo. However another interesting possibility with this tool would be to demonstrate how a family works for the purposes of educating users on how to properly use a family in a project.
So on top of all that he is running a contest until the end of the month, the winner will get a free tool of their choice (some restrictions apply) if they win the content. To win you have to provide the best example of the use of Image-O-Matic.
For all the details go here.
On another front, I'm working closely with Wes Benn (chairman of RTC), some of the North American committee members and some other folks from the industry for something special at RTC NA 2013. No other details to share yet, but stay tuned!
Showing posts with label API. Show all posts
Showing posts with label API. Show all posts
Sunday, January 27, 2013
Monday, October 17, 2011
Platforms vs. Products
Depending on the tech circles you run in (or keep track of) you may have heard of (or even read) the following post that was made by a Googler who formerly worked at Amazon.
Stevey's Google Platforms Rant
Who knows if it is/had/or will have any impact within Google, but it is still a great, well thought out post/article/tirade about how to "design" something and quite honestly in my opinion the underlying tenets can be applied to the design or architecture of anything, not just software. If you're designing a building, do you want to design a "Product" or do you want to design something that people will be able to "plug into", make use of, and adapt to their needs? Sorry FLW fans, but in some respects he was a bit of unique genius like Steve Jobs, and most of us are just not that good, we can't design something that will perfectly fit the end user's needs 5, 10, 20, 50 years down the road, the best we can do is design something that will adapt well to meet those needs as they come about.
So besides a commentary on design over-all, why do I bring this up? If like me you're passionate about where Revit can go, and how it can help change the industry, or if you're just really frustrated with its current limitations and what it can't do right now, then I think it is important to look back at Revit's development history overall. Originally Revit was undoubtedly designed as a product. The stories from out of the Factory back that assertion up with no ifs, ands or butts; "tell me what they (user) needs it to do, and I'll (we'll) make a tool". That is very much a product mentality and quite honestly it is what is needed to capture people's imagination and more importantly market share, you need to be selling a product. However as the article makes note of, Facebook somehow someway did a great job of starting life as a product, and then became a platform.
And that, really is the key for Revit, and where we are today. Revit is quite clearly (and has been for the last four to five years) on a path to truly becoming a platform. The unfortunate reality though is that its taken a great deal of upfront investment that you can't see, to make that transition, particularly for a product that did not start its life with the idea to be a platform (the article also clearly talks about how this transition is not easy). The other part is that Revit isn't done yet, if you talk to anyone who knows anything about the API, they'll tell you there are numerous parts and pieces that they don't have access to yet, every year the API grows stronger, but only as feature teams tackle parts of the feature set that need updating, add news ones, or where adding API hooks are easy to add. Furthermore, developers have in the words of the posting started to "eat their own dogfood" in terms of developing against the API, and not creating custom hacks, and data transfers to make things work.
So why should you care (if you don't know already)? First off as Revit continues to evolve into a platform more and more you will see an ecosystem of Autodesk offered services (Autodesk Cloud) and tools as well as third party software tools and services that really start to get at "doing something" with these great models we've got (see my post "Quack!" for where I think the next big development bridge is). Up until recently most API tools were confined to aiding and assisting direct modeling efforts, however more and more there are tools showing up that are all about doing something more with the model data, whether it is Project Storm or Neon (structural analysis or rendering) or Newforma's plug-in (still needs some work) or some yet to be announced tools that I know are coming from developers (exciting stuff coming) or even experiments like Vasari, it is clear to see where things are headed, and none of it would be possible if Revit does not act and breath like a platform and not a product.
So for the Autodesk'ers out there that I know like to browse my blog, pay attention! I think you're already on this track, but this is only further re-enforcement of the direction that you need to head in; and for the users out there, have patience, the more that Revit acts like a platform, the easier (in the long run) it will be for Autodesk to add the new features you want, or have someone else add a feature for you, or potentially have both and you can choose.
Stevey's Google Platforms Rant
Who knows if it is/had/or will have any impact within Google, but it is still a great, well thought out post/article/tirade about how to "design" something and quite honestly in my opinion the underlying tenets can be applied to the design or architecture of anything, not just software. If you're designing a building, do you want to design a "Product" or do you want to design something that people will be able to "plug into", make use of, and adapt to their needs? Sorry FLW fans, but in some respects he was a bit of unique genius like Steve Jobs, and most of us are just not that good, we can't design something that will perfectly fit the end user's needs 5, 10, 20, 50 years down the road, the best we can do is design something that will adapt well to meet those needs as they come about.
So besides a commentary on design over-all, why do I bring this up? If like me you're passionate about where Revit can go, and how it can help change the industry, or if you're just really frustrated with its current limitations and what it can't do right now, then I think it is important to look back at Revit's development history overall. Originally Revit was undoubtedly designed as a product. The stories from out of the Factory back that assertion up with no ifs, ands or butts; "tell me what they (user) needs it to do, and I'll (we'll) make a tool". That is very much a product mentality and quite honestly it is what is needed to capture people's imagination and more importantly market share, you need to be selling a product. However as the article makes note of, Facebook somehow someway did a great job of starting life as a product, and then became a platform.
And that, really is the key for Revit, and where we are today. Revit is quite clearly (and has been for the last four to five years) on a path to truly becoming a platform. The unfortunate reality though is that its taken a great deal of upfront investment that you can't see, to make that transition, particularly for a product that did not start its life with the idea to be a platform (the article also clearly talks about how this transition is not easy). The other part is that Revit isn't done yet, if you talk to anyone who knows anything about the API, they'll tell you there are numerous parts and pieces that they don't have access to yet, every year the API grows stronger, but only as feature teams tackle parts of the feature set that need updating, add news ones, or where adding API hooks are easy to add. Furthermore, developers have in the words of the posting started to "eat their own dogfood" in terms of developing against the API, and not creating custom hacks, and data transfers to make things work.
So why should you care (if you don't know already)? First off as Revit continues to evolve into a platform more and more you will see an ecosystem of Autodesk offered services (Autodesk Cloud) and tools as well as third party software tools and services that really start to get at "doing something" with these great models we've got (see my post "Quack!" for where I think the next big development bridge is). Up until recently most API tools were confined to aiding and assisting direct modeling efforts, however more and more there are tools showing up that are all about doing something more with the model data, whether it is Project Storm or Neon (structural analysis or rendering) or Newforma's plug-in (still needs some work) or some yet to be announced tools that I know are coming from developers (exciting stuff coming) or even experiments like Vasari, it is clear to see where things are headed, and none of it would be possible if Revit does not act and breath like a platform and not a product.
So for the Autodesk'ers out there that I know like to browse my blog, pay attention! I think you're already on this track, but this is only further re-enforcement of the direction that you need to head in; and for the users out there, have patience, the more that Revit acts like a platform, the easier (in the long run) it will be for Autodesk to add the new features you want, or have someone else add a feature for you, or potentially have both and you can choose.
Monday, July 19, 2010
Navisworks 2011 Addin file
Ugh! More then a month since I last posted, and that was from my BB while at Dev Camp.
Dev Camp was fun, too bad I've not really got back into programming. :-(
However, one thing that was further clarified for me was AddIn files and lo and behold, I need to make one!
We're in the midst of prepping for full rollout of ADSK 2011 BIM products here, which includes Navisworks. I manually installed Navis, and noticed that it modified my Revit INI in order to load the export plug-in! Well that was just annoying, modifying the ini is a pain, especially with packaged deployments, the new manifest files are much friendlier to packaged deployment of software, rather then having to make sure an INI file is properly modified. So, I wrote my own!
If you feel like using an Addin file to integrate Navisworks into your 2011 installations, just copy the code below into a text file (I recommend Notepad) and save the file as a *.addin file. Place the new file in your addins directory, remove the nasty code from your ini, and presto, you'll be all set!
<?xml version="1.0" encoding="utf-8"?>
<RevitAddIns>
<AddIn Type="Command">
<Text>Export to Navisworks 2011</Text>
<Description>Exports an NWC file from Revit for Navisworks</Description>
<Assembly>C:\Program Files\Common Files\Autodesk Shared\Navisworks\2011\nwexportrevit2011\nwexportrevit2011_8.dll</Assembly>
<FullClassName>NavisWorks8.LcRevitExportCommand</FullClassName>
<ClientId>AB6AC86F-532E-439C-B3D4-D34F660CDD54</ClientId>
<VisibilityMode>NotVisibleInFamily</VisibilityMode>
<LongDescription>
<p>Use this command to export an NWC (Navisworks Cache file) file of your Revit model. NWC files can be opened in Navisworks and saved as NWD files.</p>
</LongDescription>
</AddIn>
</RevitAddIns>
Dev Camp was fun, too bad I've not really got back into programming. :-(
However, one thing that was further clarified for me was AddIn files and lo and behold, I need to make one!
We're in the midst of prepping for full rollout of ADSK 2011 BIM products here, which includes Navisworks. I manually installed Navis, and noticed that it modified my Revit INI in order to load the export plug-in! Well that was just annoying, modifying the ini is a pain, especially with packaged deployments, the new manifest files are much friendlier to packaged deployment of software, rather then having to make sure an INI file is properly modified. So, I wrote my own!
If you feel like using an Addin file to integrate Navisworks into your 2011 installations, just copy the code below into a text file (I recommend Notepad) and save the file as a *.addin file. Place the new file in your addins directory, remove the nasty code from your ini, and presto, you'll be all set!
<?xml version="1.0" encoding="utf-8"?>
<RevitAddIns>
<AddIn Type="Command">
<Text>Export to Navisworks 2011</Text>
<Description>Exports an NWC file from Revit for Navisworks</Description>
<Assembly>C:\Program Files\Common Files\Autodesk Shared\Navisworks\2011\nwexportrevit2011\nwexportrevit2011_8.dll</Assembly>
<FullClassName>NavisWorks8.LcRevitExportCommand</FullClassName>
<ClientId>AB6AC86F-532E-439C-B3D4-D34F660CDD54</ClientId>
<VisibilityMode>NotVisibleInFamily</VisibilityMode>
<LongDescription>
<p>Use this command to export an NWC (Navisworks Cache file) file of your Revit model. NWC files can be opened in Navisworks and saved as NWD files.</p>
</LongDescription>
</AddIn>
</RevitAddIns>
Subscribe to:
Posts (Atom)
