I was spurred on by a tweet I received a couple of hours ago:
@keanw Dear kean, I've been looking into AutoCAD I/O and it looks like it may only execute "scripts"; so no .NET API calls or LISP?— Cyborg (@CyborgEvilHam) May 13, 2015
The short answer to this is “yes, it’s absolutely possible!”. But readers of this blog are clearly interested in details, so that’s where I want to get to.
In the last post I mentioned the two class proposals I’ve submitted for AU2015: one deals with VR and the other with AutoCAD I/O. The second class will focus, in particular, on how to leverage your own .NET modules in an AutoCAD I/O application. The class will be fuelled, as usual, by a series of posts I publish on this blog.
This is what I have in mind, specifically: you may remember the jigsaw generation application we saw a few weeks ago. I want to extend this app, implementing a command that will generate – from scratch, no existing geometry up our sleeves – a jigsaw of a given physical size and of an approximate number of pieces. That’s code I’m going to show in the next post.
I then want to build a web-site around this core AutoCAD app. This will involve making sure the module works in the Core Console – which is the component driving AutoCAD I/O – and then that we can create an app package for AutoCAD I/O to load the module, allowing us to execute scripts to generate jigsaws in the cloud.
The HTML page is going to do a bit more than just allowing the user to enter the dimensions and number of pieces, though: I’d like the user to be able to upload a custom image (or photo) via the site, and we’ll then create a drawing that can be used to laser-cut the puzzle but also to engrave the image onto it. Laser-engraving a full colour image is (as far as I’m aware) impossible, so this is going to be a little tricky. The idea is to use some image processing/computer vision techniques to create a monochrome pattern to be engraved: we’ll do some edge detection – either in the browser or in the cloud, we’ll see – and then propose that to the user in some way before they click on “generate my puzzle”. And “here are my credit card details”, of course. ;-)
The eventual aim would be to automate the preparation and dispatch of the physical puzzle, but that’s a bit out of the scope for an AU session, where we’ll probably just take a look at the resultant DWG file.
But the point is this: we could be using a .NET application inside AutoCAD I/O to do much of the heavy-lifting for this web-site, and the user will never even know. They won’t see a DWG file and they may not even see much by way of graphics (although I expect we’ll generate an image preview to show before the purchase is finalised).
This is exactly the kind of scenario we expect to see AutoCAD I/O used for, over time. And the great opportunity, here, is that you can make use of your existing .NET application code to take advantage of it.
I think this is pretty exciting… we’ll see how it all takes shape over the coming weeks!