Through the Interface

Getting the extents of an AutoCAD group using .NET

Here’s an interesting question that came in from Nick Gilbert via a blog comment: Is there a simple way to get the geometric extents of the group? As discussed in this previous post, the Group object in AutoCAD presents itself as a collection of geometric objects (or entities, in ObjectARX-parlance). But a Group, in itself, isn’t a geometric object: it’s an aggregator of objects that are. So there isn’t – as Nick is clearly aware – a simple GeometricExtents property of the Group object. But we can access the contents of the Group and combine their various GeometricExtents, returning... Read more →

Running custom .NET code in the cloud using AutoCAD I/O – Part 2

As promised yesterday, this post deals with modifying your CRX module to make it work with AutoCAD I/O. A quick reminder on what writing a CRX app means for .NET developers: we’re still creating a .DLL (unlike ObjectARX developers, whose CRX modules have the .crx extension), but it can only reference AcDbMgd.dll and AcCoreMgd.dll (not AcMgd.dll). Importantly the module must be loadable – and testable – in the Core Console. The basic C# code we’re going to extend is from this previous post. The real change that’s required for commands to work in AutoCAD I/O is how they get... Read more →

Creating a rectangular jigsaw puzzle with specific dimensions inside AutoCAD using .NET

Following on from the last post, where we saw an outline for this series of posts on AutoCAD I/O, today’s post adds a command to our jigsaw application that creates the geometry for a jigsaw puzzle of a specified size and with a specified number of pieces. As jigsaw puzzle pieces are largely quite square, it actually took me some time to get my head around the mathematics needed to calculate the number of pieces we need in each of the X and Y directions to make a puzzle of a certain size. And it’s (with hindsight) obviously not... Read more →

AutoCAD I/O and custom applications

The title of this post is probably a bit misleading: I’m not actually going to show how this works, today, but I do intend to plot a path for addressing this topic over the coming weeks. 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... Read more →

Adding wiggle to jigsaw puzzles in AutoCAD using .NET

After seeing some code to create basic jigsaws in AutoCAD – and then a quick look at fabricating them using a laser cutter – in today’s post we’re adding a “wiggle” factor, making the shape of the tabs more unique than in the prior version of the application. This has been integrated into the existing JIG and JIGL commands, but we’ve also added a new command called WIGL, which applies a wiggle to the tabs of existing jigsaws (it basically checks the selection for splines with 6 fit points and runs our algorithm against those). The amount of wiggle... Read more →

Creating jigsaw puzzles inside AutoCAD using .NET

Too. Much. Fun. As mentioned in the last post, a colleague came to me with a problem… for an internal team-building exercise, he needed to manufacture a circular, 60-piece jigsaw puzzle with 6 groups of 10 pieces, each of which should be roughly the same size. The pieces will also have some text engraved on them, but that’s a minor detail. I searched the darkest corners of the Internet to find an online tool to generate a pattern for this, but then realised I’d spend my time more effectively by writing one myself and sharing it here. So that’s... Read more →

Recreating the Star Wars opening crawl in AutoCAD using F# – Part 4

Happy Friday! It’s time to unveil the completed Star Wars opening crawl inside AutoCAD… After an intro and seeing various pieces implemented, in today’s post we’re going to add the crawl text and animate its movement into the distance. The initial blue text The theme music The star field The disappearing Star Wars logo The crawling text As the surprise “bonus” item 6, I decided to add a planet and – at the end of the crawl – shift the view downwards to show its surface: an effect I’ve seen in the opening crawl for at least one of... Read more →

Recreating the Star Wars opening crawl in AutoCAD using F# – Part 3

Now that we’ve introduced the series and seen how to add some introductory text, theme music and a field of stars, it’s time for the Star Wars logo. The initial blue text The theme music The star field The disappearing Star Wars logo The crawling text The logo came, once again, from the HTML opening crawl, which embeds some SVG content representing it. I copied this into a standalone SVG text file, ran it through a web-service to translate it to DXF and then opened that inside AutoCAD. The outlines of the letters (or groups of letters) were continuous... Read more →

Connecting Three.js to an AutoCAD model – Part 2

To follow on from yesterday’s post, today we’re going to look at two C# source files that work with the HTML page – and referenced JavaScript files – which I will leave online rather than reproducing here. As a brief reminder of the functionality – if you haven’t yet watched the screencast shown last time – this version of the app shows an embedded 3D view that reacts to the creation – and deletion – of geometry from the associated AutoCAD model. You will see the bounding boxes for geometry appear in the WebGL view (powered by Three.js) as... Read more →

Displaying the area of the last AutoCAD entity in an HTML palette using JavaScript and .NET

The title of this one is a little specific – the post actually deals with the scenario of passing data from .NET to an HTML-defined palette, as well as some other tips & tricks – but it’s something I wanted to show. Here’s the basic idea: whenever a closed curve gets added to the drawing, we want to display its area as the only item in an HTML palette. We also want the palette to update when objects get erased, etc., which makes life somewhat trickier. To set the scene, here’s a quick screencast of the finished application in... Read more →

Exporting Minecraft data from AutoCAD

After last week’s post on importing Minecraft data – in this case from Tinkercad – into AutoCAD, in today’s post we’re going to focus on the ultimately more interesting use case of generating Minecraft data from AutoCAD. We’re going to see some code to dice up 3D AutoCAD geometry and generate blocks in a .schematics file using Substrate. Our “dicing” process – a term I’ve just coined for iterating through a 3D space, chunk by chunk – is going to use a couple of different approaches for determining there’s any 3D geometry in each grid location. Firstly, though, we... Read more →

Importing Minecraft data into AutoCAD

A mere 2 among 100 million registered users, my boys are crazy about Minecraft. I’ve been looking into how I might be able to help them use Autodesk tools (well, AutoCAD) to generate Minecraft content. In this post we’ll take a look at importing Minecraft data into AutoCAD, but ultimately the creation/export story is clearly more interesting (something we’ll look at in the next post, I expect). To investigate dealing with Minecraft data – bearing in mind I didn’t actually know anything much about its file formats – I took a look at the Minecraft export you can perform... Read more →

Translating between AutoCAD drawing points and geographic locations using .NET – Part 2

In yesterday’s post we saw a simple implementation of two commands to translate between geographical locations (latitude-longitude values) and drawing points inside AutoCAD. In this post we’re extending that to access the current coordinate system, as returned by the GeoLocation object attached to the current drawing. Which in some ways should be simple, but then the CoordinateSystem property actually returns XML data, not just the simple coordinate system name you probably passed in when choosing it (see the IGR command, below, to see what I mean): SWISS Deprecated... Read more →

Translating between AutoCAD drawing points and geographic locations using .NET – Part 1

I received a question from Coralie Jacobi, recently, in response to this recent post: Saw your post a while ago on the geolocation in 2015. This functionality is something that we will use a great deal and I will definitely be writing some code to utilize it. What I’d like to see in your blog is something that would show me how to get to the lat\long values of the location I have picked and convert them to the coordinate system that I have selected instead of having the user have to stipulate the location in AutoCAD. In this... Read more →

Attaching geo-location data to an AutoCAD drawing using .NET

AutoCAD’s geo-location API is a topic I’ve been meaning (and even promising) to cover for some time now. So here we are. :-) The below code sample is based on one shown at ADN’s DevDays tour at the end of 2013 – for the AutoCAD 2014 release – but the API ended up not being fully usable (at least as far as I recall: someone should jump in and correct me if I have this wrong) until the 2015 release. I’ve taken the opportunity to use Editor.Command() to call a couple of commands synchronously – to turn on the... Read more →

Getting the length of the pipe centrelines in an AutoCAD drawing – Part 3

To follow on from yesterday’s post, today we’re taking a look at a more interactive – and iterative – approach to getting the length of a pipe (defined by a surface generated from an imported SAT file, we’re not talking about native Plant 3D objects). This is the second task discussed in the introductory post in this series. We’re going to add a CTRLINES2 command that asks the user to select pipe section after pipe section, and will only generate the centreline for a newly-selected section if it’s contiguous to the section of pipe that’s being “managed” (i.e. whose... Read more →

Getting the length of the pipe centrelines in an AutoCAD drawing – Part 2

After introducing the series in the last post, today we’re going to look at one potential approach for this problem: we will extract and create centrelines for surface objects created after an SAT from an external piping system has been imported into AutoCAD as well as providing a basic command to count their lengths. The code has evolved somewhat since we first saw it in this previous post: it now handles a number of previously problematic scenarios, such as the centrelines for pipe flanges being captured – it now discards polylines that intersect any cross-section circles that get captured,... Read more →

Getting the length of the pipe centrelines in an AutoCAD drawing – Part 1

Since publishing this recent post to simplify the process of generating centrelines for surfaces representing pipes – as imported from an external piping system that only generates SAT files – I’ve been thinking on and off about how best to simplify the process of measuring the lengths of these various “pipes”. Greg Robinson’s comment over the weekend spurred me on even further (thanks, Greg! :-): I'm musing on how one might code up the logic of creating a single continuous 3D poly from the horrid collection of surfaces the step file (.sat) make. This is a daunting logic issue.... Read more →

Exploding AutoCAD text and manipulating the results using .NET

Another interesting question came in by email, this week. Fredrik Skeppstedt, a long-time user of the TXTEXP Express Tool, wanted to perform a similar operation using C#: to explode text objects – as TXTEXP does – but then be able to manipulate the resulting geometry from .NET. TXTEXP is an interesting command: in order to explode text objects, it actually exports them to a Windows Metafile (.WMF) using the WMFOUT command, and then reimports the file back in using WMFIN. This, in itself, is trickier than it sounds, as WMFOUT creates the graphics in the file relative to the... Read more →

Extracting pipe centrelines from AutoCAD surfaces using .NET

This was an interesting one. I received an email from someone working on a significant BIM project that required external validation of some piping data coming from a competitive system. This system generates SAT files that – when imported into AutoCAD – represent pipes as surfaces rather than native AutoCAD (meaning Plant 3D or MEP) pipe objects. The challenge was to determine the length of these pipes inside AutoCAD, despite the fact they aren’t pipes at all. Fun! :-) The first thing I did was to take a look at the DWG data, to see what the pipes look... Read more →