Through the Interface

Getting to know the Project Draw API

Last week David Falck, over at the Autodesk Labs team, provided me with an API key to have a play with the API to Project Draw. This post documents what I did, and how it all worked.

Note: I'm not actually doing any coding whatsoever in this post: I used the handy API test page provided by the Autodesk Labs team, and so didn't need to write a single line of code.

So, first of all, you'll need an API key. Here's the one I got from the Draw team:

th1SIsnOTreAlLyMyapIkeyOfCourSE

Just kidding. I've changed the above key for the purpose of this post: if you want a key, get your own. :-P

Seriously, though: just email labs.draw@autodesk.com, and they will generate and send you your very own key.

OK, once you have a key, you can navigate to the test page and start playing around. I started by copying my key (the real one, of course) into the startSession test rig, and I then hit Initiate:

The Project Draw API is exposed via REST, as opposed to SOAP (another popular - if more heavyweight, from a client perspective - mechanism for exposing Web Services), which means you pass everything the service needs to identify the session etc., in each call made to Project Draw. So you will need to use your API key along with the session ID provided in the response received for the API call we just made for each further use of the Project Draw API.

The other way to start a Project Draw session is via the setXML web method, but we'll come to that later. For now we don't have any XML to provide, so we're going to open the blank session and create some geometry from scratch.

Copy the URL provided in the response to your clipboard and paste it into a new browser window. You should get a nice, new Project Draw page upon which to draw some geometry:

I drew some simple geometry using the Project Draw interface and saved it using File -> Save. This is an important step: if you don't save to the server, then clearly any calls to access the session's geometry via the Web Service will not retrieve anything very interesting.

Here's my model - please note that I just threw some filled objects onto the canvas, and had no intention of drawing a symbol with religious or nationalistic overtones (there's something vaguely masonic about the image, I have to admit, but it's nothing I drew consciously, honestly... which should be obvious from the colours I used, if nothing else :-)

Once we've saved our geometry, we can head back to the API test page and see what we can do with it.

Firstly, we can retrieve the XML representation of this geometry, by calling the getXML web method:

You can copy & paste the returned XML fragment into a text file, if you wish. The XML returned for my feeble artistic efforts can be accessed here.

Secondly, we can retrieve a rasterized view of our design, in PNG format:

This provides us with a nice, high-quality raster of our design:

Now that we've extracted our XML content and generated a pretty image from it, we can (and indeed must) delete the session:

Now that we have some XML content - which we could have generated/transformed/manipulated programmatically in some way - we can use it to create a new session, via the setXML web method:

That's it for today's quick tour of the Project Draw API. As you should be able to see from this procedure - and from the XML representation of the design I created - it's altogether possible to populate and manipulate content in the Project Draw service programmatically, and - as the API is simply HTTP - you're able to do so from the programming language of your choice (something we did not touch on at all today).

A final, quick note: if there's something more you'd like to see exposed in the Project Draw API, don't be shy - let us know. The Autodesk Labs team is really keen to get external feedback on this technology.

Turtle fractals in AutoCAD using .NET - Part 3

In the introductory post we first looked at a simple turtle graphics engine for AutoCAD, which was followed up by this series looking at using it to generate fractals (here are parts 1 & 2).

This post continues the organic fractal theme, by looking at another fractal found in nature, the humble fern. I found some simple Logo code in a presentation on the web:

to fern :size

if :size < 4 [stop]

fd :size / 25

lt 90 fern :size * .3

rt 90

rt 90 fern :size * .3

lt 90 fern :size * .85

bk :size / 25

end

This - when translated to use our turtle engine inside AutoCAD - creates a somewhat straight, unnatural-looking fern:

To make things a little more interesting, I generalised out some of the parameters to allow easy tweaking within the code. Here's the C# code including the complete TurtleEngine implementation, as before:

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.Colors;

using System;

namespace TurtleGraphics

{

  // This class encapsulates pen

  // information and will be

  // used by our TurtleEngine

  class Pen

  {

    // Private members

    private Color m_color;

    private double m_width;

    private bool m_down;

    // Public properties

    public Color Color

    {

      get { return m_color; }

      set { m_color = value; }

    }

    public double Width

    {

      get { return m_width; }

      set { m_width = value; }

    }

    public bool Down

    {

      get { return m_down; }

      set { m_down = value; }

    }

    // Constructor

    public Pen()

    {

      m_color =

        Color.FromColorIndex(ColorMethod.ByAci, 0);

      m_width = 0.0;

      m_down = false;

    }

  }

  // The main Turtle Graphics engine

  class TurtleEngine

  {

    // Private members

    private Transaction m_trans;

    private Polyline m_poly;

    private Pen m_pen;

    private Point3d m_position;

    private Vector3d m_direction;

    private bool m_updateGraphics;

    // Public properties

    public Point3d Position

    {

      get { return m_position; }

      set { m_position = value; }

    }

    public Vector3d Direction

    {

      get { return m_direction; }

      set { m_direction = value; }

    }

    // Constructor

    public TurtleEngine(Transaction tr)

    {

      m_pen = new Pen();

      m_trans = tr;

      m_poly = null;

      m_position = Point3d.Origin;

      m_direction = new Vector3d(1.0, 0.0, 0.0);

      m_updateGraphics = false;

    }

    // Public methods

    public void Turn(double angle)

    {

      // Rotate our direction by the

      // specified angle

      Matrix3d mat =

        Matrix3d.Rotation(

          angle,

          Vector3d.ZAxis,

          Position

        );

      Direction =

        Direction.TransformBy(mat);

    }

    public void Move(double distance)

    {

      // Move the cursor by a specified

      // distance in the direction in

      // which we're pointing

      Point3d oldPos = Position;

      Position += Direction * distance;

      // If the pen is down, we draw something

      if (m_pen.Down)

        GenerateSegment(oldPos, Position);

    }

    public void PenDown()

    {

      m_pen.Down = true;

    }

    public void PenUp()

    {

      m_pen.Down = false;

      // We'll start a new entity with the next

      // use of the pen

      m_poly = null;

    }

    public void SetPenWidth(double width)

    {

      m_pen.Width = width;

    }

    public void SetPenColor(int idx)

    {

      // Right now we just use an ACI,

      // to make the code simpler

      Color col =

        Color.FromColorIndex(

          ColorMethod.ByAci,

          (short)idx

        );

      // If we have to change the color,

      // we'll start a new entity

      // (if the entity type we're creating

      // supports per-segment colors, we

      // don't need to do this)

      if (col != m_pen.Color)

      {

        m_poly = null;

        m_pen.Color = col;

      }

    }

    // Internal helper to generate geometry

    // (this could be optimised to keep the

    // object we're generating open, rather

    // than having to reopen it each time)

    private void GenerateSegment(

      Point3d oldPos, Point3d newPos)

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Database db = doc.Database;

      Editor ed = doc.Editor;

      Autodesk.AutoCAD.ApplicationServices.

      TransactionManager tm =

        doc.TransactionManager;

      Plane plane;

      // Create the current object, if there is none

      if (m_poly == null)

      {

        BlockTable bt =

          (BlockTable)m_trans.GetObject(

            db.BlockTableId,

            OpenMode.ForRead

          );

        BlockTableRecord ms =

          (BlockTableRecord)m_trans.GetObject(

            bt[BlockTableRecord.ModelSpace],

            OpenMode.ForWrite

          );

        // Create the polyline

        m_poly = new Polyline();

        m_poly.Color = m_pen.Color;

        // Define its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

        // Add the first vertex

        m_poly.AddVertexAt(

          0, oldPos.Convert2d(plane),

          0.0, m_pen.Width, m_pen.Width

        );

        // Add the polyline to the database

        ms.AppendEntity(m_poly);

        m_trans.AddNewlyCreatedDBObject(m_poly, true);

      }

      else

      {

        // Calculate its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

      }

      // Make sure the previous vertex has its

      // width set appropriately

      if (m_pen.Width > 0.0)

      {

        m_poly.SetStartWidthAt(

          m_poly.NumberOfVertices - 1,

          m_pen.Width

        );

        m_poly.SetEndWidthAt(

          m_poly.NumberOfVertices - 1,

          m_pen.Width

        );

      }

      // Add the new vertex

      m_poly.AddVertexAt(

        m_poly.NumberOfVertices,

        newPos.Convert2d(plane),

        0.0, m_pen.Width, m_pen.Width

      );

      // Display the graphics, to avoid long,

      // black-box operations

      if (m_updateGraphics)

      {

        tm.QueueForGraphicsFlush();

        tm.FlushGraphics();

        ed.UpdateScreen();

      }

    }

  }

  public class Commands

  {

    static void Fern(

      TurtleEngine te,

      double distance

    )

    {

      const double minDist = 0.3;

      const double widthFactor = 0.1;

      const double stemFactor = 0.04;

      const double restFactor = 0.85;

      const double branchFactor = 0.3;

      const int stemSegs = 5;

      const int stemSegAngle = 1;

      if (distance < minDist)

        return;

      // Width of the trunk/branch is a fraction

      // of the length

      te.SetPenWidth(

        distance * stemFactor * widthFactor

      );

      // Draw the stem

      for (int i = 0; i < stemSegs; i++)

      {

        te.Move(distance * stemFactor / stemSegs);

        if (i < stemSegs - 1)

          te.Turn(-stemSegAngle * Math.PI / 180);

      }

      // Draw the left-hand sub-fern

      te.Turn(Math.PI / 2);

      Fern(te, distance * branchFactor);

      // Draw the right-hand sub-fern

      te.Turn(-Math.PI);

      Fern(te, distance * branchFactor);

      // Draw the rest of the fern to the front

      te.Turn(Math.PI / 2);

      Fern(te, distance * restFactor);

      // Draw back down to the start of this sub-

      // fern, with the same thickness, as this

      // may have changed in deeper sub-ferns

      te.SetPenWidth(

        distance * stemFactor * widthFactor

      );

      for (int i = 0; i < stemSegs; i++)

      {

        te.Move(-distance * stemFactor / stemSegs);

        if (i < stemSegs - 1)

          te.Turn(stemSegAngle * Math.PI / 180);

      }

    }

    static public bool GetFernInfo(

      out Point3d position,

      out double treeLength

    )

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Editor ed = doc.Editor;

      treeLength = 0;

      position = Point3d.Origin;

      PromptPointOptions ppo =

        new PromptPointOptions(

          "\nSelect base point of fern: "

        );

      PromptPointResult ppr =

        ed.GetPoint(ppo);

      if (ppr.Status != PromptStatus.OK)

        return false;

      position = ppr.Value;

      PromptDoubleOptions pdo =

        new PromptDoubleOptions(

          "\nEnter fern length <100>: "

        );

      pdo.AllowNone = true;

      PromptDoubleResult pdr =

        ed.GetDouble(pdo);

      if (pdr.Status != PromptStatus.None &&

          pdr.Status != PromptStatus.OK)

        return false;

      if (pdr.Status == PromptStatus.OK)

        treeLength = pdr.Value;

      else

        treeLength = 100;

      return true;

    }

    [CommandMethod("FF")]

    static public void FractalFern()

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      double fernLength;

      Point3d position;

      if (!GetFernInfo(out position, out fernLength))

        return;

      Transaction tr =

        doc.TransactionManager.StartTransaction();

      using (tr)

      {

        TurtleEngine te = new TurtleEngine(tr);

        // Draw a fractal fern

        te.Position = position;

        te.SetPenColor(92);

        te.SetPenWidth(0);

        te.Turn(Math.PI / 2);

        te.PenDown();

        Fern(te, fernLength);

        tr.Commit();

      }

    }

  }

}

When we run the FF command, selecting a location and the default tree length, we see a more natural (although in no way random) form:

Tweaking the stemSegAngle constant to be -2 instead of 1 gives a further differentiated result:

Incidentally, to get the original, "straight" fern, simply change the stemSegs constant to 1. The curved ferns will each take n times as much space in memory/on disk as the straight ones (where n is the value of stemSegs). This is because we're not storing actual curves, but using multiple straight line segments.

Any of the constants in the Fern() function could be presented for the user to enter, of course (i.e. populated by the GetFernInfo() function and passed as parameters into the Fern() function).

Turtle fractals in AutoCAD using .NET - Part 2

This series start with this initial post, where we looked at an implementation of a simple turtle graphics engine inside AutoCAD, and followed on with this previous post, where we refined the engine and looked at how we could use it to generate complex fractals with relatively little code.

In this post we take a further look at fractal generation using the turtle graphic engine, with the particular focus on introducing randomness to generate more realistic, organic forms. On a side note, fractals and the use of randomness in design are two of my favourite topics, so this post is hitting a sweet spot, for me. :-)

So where to start when generating organic forms? The simplest, "classic" example, in my view, is to generate trees. Trees lend themselves to automatic generation, as - in 2D, at least - they are a sequence of simple 2-way forks (at least the way I draw them, they are :-).

I picked up some simple Logo code from this site (yes, it does indeed say "fractals for children" in the title :-)

if :distance < 5 [stop]

forward :distance

right 30

tree :distance-10

left 60

tree :distance-10

right 30

back :distance

This is easy to turn into C# code harnessing our TurtleEngine, with the addition of a proportional trunk/branch width (we take the width as a tenth of the length). See the Tree() function in the code listing below. The results of this procedure (which you call via the FT command) are interesting enough, if a little perfect:

You will notice that the tree is created as a single Polyline, which is a result of us back-tracking over previous segments with the pen down, rather than up. You can see this from this image showing the tree selected:

The FT command will create the same results every single time (assuming you specify the same tree length), which may or may not be what you're after.

So let's go and add some randomness, to make life a little more interesting. This modified function in the below code, named RandomTree(), generates a separate random factor to apply to the trunk/branch length (and therefore the width, as this is proportional to the length), and to the angle of each of the two branches sprouting from the current trunk or branch. The "variability" is specified by the user for all our random factors, but we could go further and tweak it for the length and for each of the angles.

Here's the C# code, including command definitions and the TurtleEngine we refined in the last post:

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.Colors;

using System;

namespace TurtleGraphics

{

  // This class encapsulates pen

  // information and will be

  // used by our TurtleEngine

  class Pen

  {

    // Private members

    private Color m_color;

    private double m_width;

    private bool m_down;

    // Public properties

    public Color Color

    {

      get { return m_color; }

      set { m_color = value; }

    }

    public double Width

    {

      get { return m_width; }

      set { m_width = value; }

    }

    public bool Down

    {

      get { return m_down; }

      set { m_down = value; }

    }

    // Constructor

    public Pen()

    {

      m_color =

        Color.FromColorIndex(ColorMethod.ByAci, 0);

      m_width = 0.0;

      m_down = false;

    }

  }

  // The main Turtle Graphics engine

  class TurtleEngine

  {

    // Private members

    private Transaction m_trans;

    private Polyline m_poly;

    private Pen m_pen;

    private Point3d m_position;

    private Vector3d m_direction;

    private bool m_updateGraphics;

    // Public properties

    public Point3d Position

    {

      get { return m_position; }

      set { m_position = value; }

    }

    public Vector3d Direction

    {

      get { return m_direction; }

      set { m_direction = value; }

    }

    // Constructor

    public TurtleEngine(Transaction tr)

    {

      m_pen = new Pen();

      m_trans = tr;

      m_poly = null;

      m_position = Point3d.Origin;

      m_direction = new Vector3d(1.0, 0.0, 0.0);

      m_updateGraphics = false;

    }

    // Public methods

    public void Turn(double angle)

    {

      // Rotate our direction by the

      // specified angle

      Matrix3d mat =

        Matrix3d.Rotation(

          angle,

          Vector3d.ZAxis,

          Position

        );

      Direction =

        Direction.TransformBy(mat);

    }

    public void Move(double distance)

    {

      // Move the cursor by a specified

      // distance in the direction in

      // which we're pointing

      Point3d oldPos = Position;

      Position += Direction * distance;

      // If the pen is down, we draw something

      if (m_pen.Down)

        GenerateSegment(oldPos, Position);

    }

    public void PenDown()

    {

      m_pen.Down = true;

    }

    public void PenUp()

    {

      m_pen.Down = false;

      // We'll start a new entity with the next

      // use of the pen

      m_poly = null;

    }

    public void SetPenWidth(double width)

    {

      m_pen.Width = width;

    }

    public void SetPenColor(int idx)

    {

      // Right now we just use an ACI,

      // to make the code simpler

      Color col =

        Color.FromColorIndex(

          ColorMethod.ByAci,

          (short)idx

        );

      // If we have to change the color,

      // we'll start a new entity

      // (if the entity type we're creating

      // supports per-segment colors, we

      // don't need to do this)

      if (col != m_pen.Color)

      {

        m_poly = null;

        m_pen.Color = col;

      }

    }

    // Internal helper to generate geometry

    // (this could be optimised to keep the

    // object we're generating open, rather

    // than having to reopen it each time)

    private void GenerateSegment(

      Point3d oldPos, Point3d newPos)

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Database db = doc.Database;

      Editor ed = doc.Editor;

      Autodesk.AutoCAD.ApplicationServices.

      TransactionManager tm =

        doc.TransactionManager;

      Plane plane;

      // Create the current object, if there is none

      if (m_poly == null)

      {

        BlockTable bt =

          (BlockTable)m_trans.GetObject(

            db.BlockTableId,

            OpenMode.ForRead

          );

        BlockTableRecord ms =

          (BlockTableRecord)m_trans.GetObject(

            bt[BlockTableRecord.ModelSpace],

            OpenMode.ForWrite

          );

        // Create the polyline

        m_poly = new Polyline();

        m_poly.Color = m_pen.Color;

        // Define its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

        // Add the first vertex

        m_poly.AddVertexAt(

          0, oldPos.Convert2d(plane),

          0.0, m_pen.Width, m_pen.Width

        );

        // Add the polyline to the database

        ms.AppendEntity(m_poly);

        m_trans.AddNewlyCreatedDBObject(m_poly, true);

      }

      else

      {

        // Calculate its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

      }

      // Make sure the previous vertex has its

      // width set appropriately

      if (m_pen.Width > 0.0)

      {

        m_poly.SetStartWidthAt(

          m_poly.NumberOfVertices - 1,

          m_pen.Width

        );

        m_poly.SetEndWidthAt(

          m_poly.NumberOfVertices - 1,

          m_pen.Width

        );

      }

      // Add the new vertex

      m_poly.AddVertexAt(

        m_poly.NumberOfVertices,

        newPos.Convert2d(plane),

        0.0, m_pen.Width, m_pen.Width

      );

      // Display the graphics, to avoid long,

      // black-box operations

      if (m_updateGraphics)

      {

        tm.QueueForGraphicsFlush();

        tm.FlushGraphics();

        ed.UpdateScreen();

      }

    }

  }

  public class Commands

  {

    static public bool GetTreeInfo(

      out Point3d position,

      out double treeLength

    )

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Editor ed = doc.Editor;

      treeLength = 0;

      position = Point3d.Origin;

      PromptPointOptions ppo =

        new PromptPointOptions(

          "\nSelect base point of tree: "

        );

      PromptPointResult ppr =

        ed.GetPoint(ppo);

      if (ppr.Status != PromptStatus.OK)

        return false;

      position = ppr.Value;

      PromptDoubleOptions pdo =

        new PromptDoubleOptions(

          "\nEnter tree length <70>: "

        );

      pdo.AllowNone = true;

      PromptDoubleResult pdr =

        ed.GetDouble(pdo);

      if (pdr.Status != PromptStatus.None &&

          pdr.Status != PromptStatus.OK)

        return false;

      if (pdr.Status == PromptStatus.OK)

        treeLength = pdr.Value;

      else

        treeLength = 70;

      return true;

    }

    static void Tree(

      TurtleEngine te,

      double distance

    )

    {

      if (distance < 5.0)

        return;

      // Width of the trunk/branch is a tenth of

      // of the length

      te.SetPenWidth(distance / 10);

      // Draw the main trunk/branch

      te.Move(distance);

      // Draw the left-hand sub-tree

      te.Turn(Math.PI / 6);

      Tree(te, distance - 10);

      // Draw the right-hand sub-tree

      te.Turn(Math.PI / -3);

      Tree(te, distance - 10);

      // Turn back to the original angle

      te.Turn(Math.PI / 6);

      // Draw back down to the start of this sub-

      // tree, with the same thickness, as this

      // may have changed in deeper sub-trees

      te.SetPenWidth(distance / 10);

      te.Move(-distance);

    }

    static void RandomTree(

      TurtleEngine te,

      double distance,

      int variability

    )

    {

      if (distance < 5.0)

        return;

      // Generate 3 random factors, each on the same basis:

      //  a base amount = 100 - half the variability

      //  + a random amount from 0 to the variability

      // So a variability of 20 results in 90 to 110 (0.9-1.1)

      Random rnd = new Random();

      int basic = 100 - (variability / 2);

      int num = rnd.Next(variability);

      double factor = (basic + num) / 100.0;

      num = rnd.Next(variability);

      double factor1 = (basic + num) / 100.0;

      num = rnd.Next(variability);

      double factor2 = (basic + num) / 100.0;

      // Multiple out the various items by the factors

      double distance1 = factor * distance;

      double angle1 = factor1 * Math.PI / 6;

      double angle2 = factor2 * Math.PI / -3;

      // The last angle is the total angle

      double angle3 = angle1 + angle2;

      // Width of the trunk/branch is a tenth of

      // of the length

      te.SetPenWidth(distance1 / 10);

      // Draw the main trunk/branch

      te.Move(distance1);

      // Draw the left-hand sub-tree

      te.Turn(angle1);

      RandomTree(te, distance - 10, variability);

      // Draw the right-hand sub-tree

      te.Turn(angle2);

      RandomTree(te, distance - 10, variability);

      // Turn back to the original angle

      te.Turn(-angle3);

      // Draw back down to the start of this sub-

      // tree, with the same thickness, as this

      // may have changed in deeper sub-trees

      te.SetPenWidth(distance1 / 10);

      te.Move(-distance1);

    }

    [CommandMethod("FT")]

    static public void FractalTree()

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      double treeLength;

      Point3d position;

      if (!GetTreeInfo(out position, out treeLength))

        return;

      Transaction tr =

        doc.TransactionManager.StartTransaction();

      using (tr)

      {

        TurtleEngine te = new TurtleEngine(tr);

        // Draw a fractal tree

        te.Position = position;

        te.SetPenColor(0);

        te.SetPenWidth(0);

        te.Turn(Math.PI / 2);

        te.PenDown();

        Tree(te, treeLength);

        tr.Commit();

      }

    }

    [CommandMethod("RFT")]

    static public void RandomFractalTree()

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Editor ed = doc.Editor;

      double treeLength;

      Point3d position;

      if (!GetTreeInfo(out position, out treeLength))

        return;

      int variability = 20;

      PromptIntegerOptions pio =

        new PromptIntegerOptions(

          "\nEnter variability percentage <20>: "

        );

      pio.AllowNone = true;

      PromptIntegerResult pir =

        ed.GetInteger(pio);

      if (pir.Status != PromptStatus.None &&

          pir.Status != PromptStatus.OK)

        return;

      if (pir.Status == PromptStatus.OK)

        variability = pir.Value;

      Transaction tr =

        doc.TransactionManager.StartTransaction();

      using (tr)

      {

        TurtleEngine te = new TurtleEngine(tr);

        // Draw a random fractal tree

        te.Position = position;

        te.SetPenColor(0);

        te.SetPenWidth(0);

        te.Turn(Math.PI / 2);

        te.PenDown();

        RandomTree(te, treeLength, variability);

        tr.Commit();

      }

    }

  }

}

This is the first time the turtle engine has been used to apply widths to segments, so I did make a very minor change in the GenerateSegment() function: we need to apply the current pen width to the previous Polyline vertex, and not just the one we're adding. A minor change, but one that makes the engine behave in a more expected way.

When we run the RFT command, we can see a variety of trees get created - here's a quick sample:

These were created with the standard options (tree length of 70, variability of 20), but with different choices here you can get quite different results.

I hope this demonstrates the interesting capabilities turtle graphics bring to the area of modeling organic models via recursive fractals + randomness: while this was deliberately quite a simple example, this type of approach could be used/extended to generate other, more elaborate types of "natural" design in two and three dimensions.

Turtle fractals in AutoCAD using .NET - Part 1

This topic started in this recent post, where I introduced a simple turtle graphics engine for AutoCAD implemented in C#. My eventual aim is still to implement a subset of the Logo programming language in F#, calling through to this C# engine, but for now I've been side-tracked: I'm simply having too much fun with the engine itself and exploring the possibilities of turtle graphics inside AutoCAD - especially around the use of recursive algorithms to generate fractals.

This post and the next (and maybe more, depending on how much fun I continue to have) will be devoted to recursive algorithms for fractal generation with a cursor-based, turtle graphics system: in this post we'll start with performance-related improvements to the engine alluded to in the last post, and move on to code to generate precise fractals. The next post will take this further by looking at adding randomness to fractals, allowing us to create more organic forms.

So let's start with the engine enhancements: I mentioned last time that the previous implementation was sub-optimal, as it used a new transaction for each segment created. I did some benchmarking, to see what improvement gains were to be had by changing the implementation, and - interestingly - there was very little change when I modified the engine to maintain a single transaction when testing with the DTG command in the previous post. It turns out that the bottleneck for that particular scenario was the graphics update: refreshing the graphics after each segment drawn is extremely time-consuming, so the overhead of using separate transactions per segment didn't really impact performance. As we move on to much larger models - as we will in this post - it makes sense to perform two optimizations to the engine:

1. Turn off display of graphics during update
   • We will not flush any graphics and simply let AutoCAD take care of updating the display when we're done
2. A single transaction per execution
   • We will maintain references to a Transaction and a Polyline within our engine, instead of an ObjectId

Implementing this is very simple, as you can see below, and the client code only really needs to make one change: it needs to start its own transaction and pass that into the constructor of the TurtleEngine. This will be used, as needed, and must, of course, be committed and disposed of by the client at the end (we'll use the using statement to take care of the disposal).

Once the graphics flushing has been disabled (again, with a trivial change: I've added a Boolean variable - with a default value of false - to check before updating the graphics), we really start to see the relevance of maintaining a separate transaction, as our previous performance bottleneck has been removed. More on this later.

Onto the fractal algorithm we're implementing today, to put the engine through its paces: some of you may remember this previous pair of posts, where we looked at an implementation for generating Koch curves inside AutoCAD. In this case we're going to generate something called the Koch snowflake, which is basically a triangle with each segment divided a series of times:

The formula for calculating the number of sides is: 3 * 4^l, where l is the recursion level (at least from our perspective, a triangle is level 0, while the right-most shape above is level 5). I have kept two implementations of the engine in my project, for comparison: when using the old implementation, a level 7 Koch snowflake - which for us means a Polyline of 49,152 segments - takes 5 minutes to generate. With the new approach of maintaining a single transaction, this reduces to under 2 seconds. Which is clearly a significant change. [Note: neither of these implementations update graphics until the end - if we were to update the screen for each of the ~50K segments, we'd be waiting for hours, I suspect.]

A level 8 snowflake took just 7 seconds for my system to generate with the new version of the engine. I limited the level selection to 8, not because it would take too long to generate, but because unless you disable rollover highlighting AutoCAD is likely to grind to a halt for a number of seconds when you hover over an object of this complexity: a level 8 snowflake does have 196,608 segments, after all.

Here's the C# code with the modified engine and the algorithm for creating Koch snowflakes:

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.Colors;

using System;

namespace TurtleGraphics

{

  // This class encapsulates pen

  // information and will be

  // used by our TurtleEngine

  class Pen

  {

    // Private members

    private Color m_color;

    private double m_width;

    private bool m_down;

    // Public properties

    public Color Color

    {

      get { return m_color; }

      set { m_color = value; }

    }

    public double Width

    {

      get { return m_width; }

      set { m_width = value; }

    }

    public bool Down

    {

      get { return m_down; }

      set { m_down = value; }

    }

    // Constructor

    public Pen()

    {

      m_color =

        Color.FromColorIndex(ColorMethod.ByAci, 0);

      m_width = 0.0;

      m_down = false;

    }

  }

  // The main Turtle Graphics engine

  class TurtleEngine

  {

    // Private members

    private Transaction m_trans;

    private Polyline m_poly;

    private Pen m_pen;

    private Point3d m_position;

    private Vector3d m_direction;

    private bool m_updateGraphics;

    // Public properties

    public Point3d Position

    {

      get { return m_position; }

      set { m_position = value; }

    }

    public Vector3d Direction

    {

      get { return m_direction; }

      set { m_direction = value; }

    }

    // Constructor

    public TurtleEngine(Transaction tr)

    {

      m_pen = new Pen();

      m_trans = tr;

      m_poly = null;

      m_position = Point3d.Origin;

      m_direction = new Vector3d(1.0, 0.0, 0.0);

      m_updateGraphics = false;

    }

    // Public methods

    public void Turn(double angle)

    {

      // Rotate our direction by the

      // specified angle

      Matrix3d mat =

        Matrix3d.Rotation(

          angle,

          Vector3d.ZAxis,

          Position

        );

      Direction =

        Direction.TransformBy(mat);

    }

    public void Move(double distance)

    {

      // Move the cursor by a specified

      // distance in the direction in

      // which we're pointing

      Point3d oldPos = Position;

      Position += Direction * distance;

      // If the pen is down, we draw something

      if (m_pen.Down)

        GenerateSegment(oldPos, Position);

    }

    public void PenDown()

    {

      m_pen.Down = true;

    }

    public void PenUp()

    {

      m_pen.Down = false;

      // We'll start a new entity with the

      // next use of the pen

      m_poly = null;

    }

    public void SetPenWidth(double width)

    {

      m_pen.Width = width;

    }

    public void SetPenColor(int idx)

    {

      // Right now we just use an ACI,

      // to make the code simpler

      Color col =

        Color.FromColorIndex(

          ColorMethod.ByAci,

          (short)idx

        );

      // If we have to change the color,

      // we'll start a new entity

      // (if the entity type we're creating

      // supports per-segment colors, we

      // don't need to do this)

      if (col != m_pen.Color)

      {

        m_poly = null;

        m_pen.Color = col;

      }

    }

    // Internal helper to generate geometry

    // (this could be optimised to keep the

    // object we're generating open, rather

    // than having to reopen it each time)

    private void GenerateSegment(

      Point3d oldPos, Point3d newPos)

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Database db = doc.Database;

      Editor ed = doc.Editor;

      Autodesk.AutoCAD.ApplicationServices.

      TransactionManager tm =

        doc.TransactionManager;

      Plane plane;

      // Create the current object, if there is none

      if (m_poly == null)

      {

        BlockTable bt =

          (BlockTable)m_trans.GetObject(

            db.BlockTableId,

            OpenMode.ForRead

          );

        BlockTableRecord ms =

          (BlockTableRecord)m_trans.GetObject(

            bt[BlockTableRecord.ModelSpace],

            OpenMode.ForWrite

          );

        // Create the polyline

        m_poly = new Polyline();

        m_poly.Color = m_pen.Color;

        // Define its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

        // Add the first vertex

        m_poly.AddVertexAt(

          0, oldPos.Convert2d(plane),

          0.0, m_pen.Width, m_pen.Width

        );

        // Add the polyline to the database

        ms.AppendEntity(m_poly);

        m_trans.AddNewlyCreatedDBObject(m_poly, true);

      }

      else

      {

        // Calculate its plane

        plane = new Plane(

          m_poly.Ecs.CoordinateSystem3d.Origin,

          m_poly.Ecs.CoordinateSystem3d.Zaxis

        );

      }

      // Now we have our current object open,

      // add the new vertex

      m_poly.AddVertexAt(

        m_poly.NumberOfVertices,

        newPos.Convert2d(plane),

        0.0, m_pen.Width, m_pen.Width

      );

      // Display the graphics, to avoid long,

      // black-box operations

      if (m_updateGraphics)

      {

        tm.QueueForGraphicsFlush();

        tm.FlushGraphics();

        ed.UpdateScreen();

      }

    }

  }

  public class Commands

  {

    static void KochIsland(

      TurtleEngine te,

      double size,

      int level

    )

    {

      for (int i = 0; i < 3; i++)

      {

        // Draw a side

        KSide(te, size, level);

        // Turn 120 degrees to the left

        te.Turn(2 * Math.PI / 3);

      }

    }

    static void KSide(

      TurtleEngine te,

      double size,

      int level

    )

    {

      // When at level 0, draw the side and exit

      if (level == 0)

        te.Move(size);

      else

      {

        // Else recurse for each segment of the side

        KSide(te, size / 3, level - 1);

        te.Turn(Math.PI / -3);

        KSide(te, size / 3, level - 1);

        te.Turn(2 * Math.PI / 3);

        KSide(te, size / 3, level - 1);

        te.Turn(Math.PI / -3);

        KSide(te, size / 3, level - 1);

      }

    }

    [CommandMethod("KSF")]

    static public void KochSnowFlake()

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Editor ed = doc.Editor;

      // Ask for the recursion level

      int level = 6;

      PromptIntegerOptions pio =

        new PromptIntegerOptions(

          "\nEnter recursion level <6>: "

        );

      pio.AllowNone = true;

      pio.LowerLimit = 0;

      pio.UpperLimit = 8;

      PromptIntegerResult pir =

        ed.GetInteger(pio);

      if (pir.Status != PromptStatus.OK &&

          pir.Status != PromptStatus.None)

        return;

      if (pir.Status == PromptStatus.OK)

        level = pir.Value;

      Transaction tr =

        doc.TransactionManager.StartTransaction();

      using (tr)

      {

        TurtleEngine te = new TurtleEngine(tr);

        // Draw a Koch snowflake

        te.SetPenColor(0);

        te.SetPenWidth(0);

        te.PenDown();

        // 100 is an arbitrary value:

        // you could also prompt the user for this

        KochIsland(te, 100, level);

        tr.Commit();

      }

    }

  }

}

Here are the results of the KSF command, when used to generate a level 6 snowflake. Although frankly you wouldn't see a difference between a level 5 and a level 10 snowflake at this resolution. :-)

Next time we'll look at some recursive code to generate less precise, more natural forms.

Two years and counting...

Well, that came around quickly. Today is the 2nd anniversary of my first post to Through the Interface. I'll keep this one short and sweet, but expect something meatier in the next day or so. :-)

A simple turtle graphics implementation in AutoCAD using .NET

Like many thirty-something Brits (and possible non-Brits, for all I know) my earliest introduction to the world of graphics programming was via a language called Logo running on the BBC Microcomputer.

This machine and its educational software were commonplace in UK schools in the 1980s, and I have clear memories of staying late at primary school (which I suppose means I was somewhere between 8 and 10) to fool around with BBC BASIC. With a friend I used to try to write text-based adventures ("you are in a cave, there are exits North, South, East and West" - you know the kind of thing) which we padded with loads and loads of comments to stop them from loading embarrassingly quickly from tape. Oh, the memories. :-)

Anyway, I digress. Logo provided a really great introduction to vector graphics: even as we were being taught trigonometry we were exposed to an environment that allowed us to translate these concepts into graphics on a computer screen. Too cool.

Thinking back about all this, I decided to implement a simple turtle graphics engine inside AutoCAD, to allow eventual integration of a Logo-like language into it. The idea was this: to implement an engine exposing a series of methods (Move(), Turn(), PenUp(), PenDown(), SetPenColor() and SetPenWidth(), to start with) that could be used to implement a subset of the Logo language. I decided to write the engine in C#, whose object-orientation makes it well-suited to this type of task, and then look into using F# for implementing the language to drive it in a future post.

F# is very good for implementing new or existing programming languages: the whole area of Domain Specific Languages (DSLs) is a major selling point for functional languages, generally. They're very well-suited to the tasks that make up the interpretation/compilation process: lexical analysis, syntactic analysis, etc., as much of the hard work is around tokenizing strings, processing lists and mapping behaviours (and these activities are most functional programming languages' "bread and butter").

Only after deciding this approach did I stumble across an existing Logo implementation in F#, so it appears that integrating the Logo language may prove simpler than I expected.

A little more on the implementation of the turtle graphics engine: I decided to implement a 2D system, to start with, generating geometry as a series of Polyline objects. Every time the PenUp() function is called we tell the system to create a new object. We also do this for SetPenColor() in the cases where the colour is changed, as Polylines do not support per-segment colours (if we were to implement a custom object that did so, we could change the implementation to keep contiguous, multi-coloured segments in a single object). The current implementation reopens the previous object each time, and therefore creates a new transaction for every single Move() operation. This is clearly sub-optimal, but I quite like the old-school effect of watching the graphics get revealed segment by segment. :-) A more optimal technique would be to keep the object open while the pen is down and the engine is in use, and this is currently left as an exercise for the reader (or until I hit a use case where I can no longer be bothered to wait for the execution to complete :-).

It would be quite simple to take this engine into 3D, and I may well do so at some point in the future. There seem to be a number of successful 3D Logo implementations out there, and they really have great potential when generating organic models, as you can see from this page. Languages such as Logo can be applied very effectively to the task of generating fractal geometry by interpreting (and implementing) Lindenmayer (or L-) systems, for instance.

OK, enough background information... here's the C# code:

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.Colors;

using System;

namespace TurtleGraphics

{

  // This class encapsulates pen

  // information and will be

  // used by our TurtleEngine

  class Pen

  {

    // Private members

    private Color m_color;

    private double m_width;

    private bool m_down;

    // Public properties

    public Color Color

    {

      get { return m_color; }

      set { m_color = value; }

    }

    public double Width

    {

      get { return m_width; }

      set { m_width = value; }

    }

    public bool Down

    {

      get { return m_down; }

      set { m_down = value; }

    }

    // Constructor

    public Pen()

    {

      m_color =

        Color.FromColorIndex(ColorMethod.ByAci, 0);

      m_width = 0.0;

      m_down = false;

    }

  }

  // The main Turtle Graphics engine

  class TurtleEngine

  {

    // Private members

    private ObjectId m_currentObject;

    private Pen m_pen;

    private Point3d m_position;

    private Vector3d m_direction;

    // Public properties

    public Point3d Position

    {

      get { return m_position; }

      set { m_position = value; }

    }

    public Vector3d Direction

    {

      get { return m_direction; }

      set { m_direction = value; }

    }

    // Constructor

    public TurtleEngine()

    {

      m_pen = new Pen();

      m_currentObject = ObjectId.Null;

      m_position = Point3d.Origin;

      m_direction = new Vector3d(1.0, 0.0, 0.0);

    }

    // Public methods

    public void Turn(double angle)

    {

      // Rotate our direction by the

      // specified angle

      Matrix3d mat =

        Matrix3d.Rotation(

          angle,

          Vector3d.ZAxis,

          Position

        );

      Direction =

        Direction.TransformBy(mat);

    }

    public void Move(double distance)

    {

      // Move the cursor by a specified

      // distance in the direction in

      // which we're pointing

      Point3d oldPos = Position;

      Position += Direction * distance;

      // If the pen is down, we draw something

      if (m_pen.Down)

        GenerateSegment(oldPos, Position);

    }

    public void PenDown()

    {

      m_pen.Down = true;

    }

    public void PenUp()

    {

      m_pen.Down = false;

      // We'll start a new entity with the next

      // use of the pen

      m_currentObject =

        ObjectId.Null;

    }

    public void SetPenWidth(double width)

    {

      m_pen.Width = width;

    }

    public void SetPenColor(int idx)

    {

      // Right now we just use an ACI,

      // to make the code simpler

      Color col =

        Color.FromColorIndex(

          ColorMethod.ByAci,

          (short)idx

        );

      // If we have to change the color,

      // we'll start a new entity

      // (if the entity type we're creating

      // supports per-segment colors, we

      // don't need to do this)

      if (col != m_pen.Color)

      {

        m_currentObject =

          ObjectId.Null;

        m_pen.Color = col;

      }

    }

    // Internal helper to generate geometry

    // (this could be optimised to keep the

    // object we're generating open, rather

    // than having to reopen it each time)

    private void GenerateSegment(

      Point3d oldPos, Point3d newPos)

    {

      Document doc =

        Application.DocumentManager.MdiActiveDocument;

      Database db = doc.Database;

      Editor ed = doc.Editor;

      Autodesk.AutoCAD.ApplicationServices.

      TransactionManager tm =

        doc.TransactionManager;

      Transaction tr =

        tm.StartTransaction();

      using (tr)

      {

        Polyline pl;

        Plane plane;

        // Create the current object, if there is none

        if (m_currentObject == ObjectId.Null)

        {

          BlockTable bt =

            (BlockTable)tr.GetObject(

              db.BlockTableId,

              OpenMode.ForRead

            );

          BlockTableRecord ms =

            (BlockTableRecord)tr.GetObject(

              bt[BlockTableRecord.ModelSpace],

              OpenMode.ForWrite

            );

          // Create the polyline

          pl = new Polyline();

          pl.Color = m_pen.Color;

          // Define its plane

          plane = new Plane(

            pl.Ecs.CoordinateSystem3d.Origin,

            pl.Ecs.CoordinateSystem3d.Zaxis

          );

          // Add the first vertex

          pl.AddVertexAt(

            0, oldPos.Convert2d(plane),

            0.0, m_pen.Width, m_pen.Width

          );

          // Add the polyline to the database

          m_currentObject =

            ms.AppendEntity(pl);

          tr.AddNewlyCreatedDBObject(pl, true);

        }

        else

        {

          // Get the current object, if there is one

          pl =

            (Polyline)tr.GetObject(

              m_currentObject,

              OpenMode.ForWrite

            );

          // Calculate its plane

          plane = new Plane(

            pl.Ecs.CoordinateSystem3d.Origin,

            pl.Ecs.CoordinateSystem3d.Zaxis

          );

        }

        // Now we have our current object open,

        // add the new vertex

        pl.AddVertexAt(

          pl.NumberOfVertices,

          newPos.Convert2d(plane),

          0.0, m_pen.Width, m_pen.Width

        );

        // Display the graphics, to avoid long,

        // black-box operations

        tm.QueueForGraphicsFlush();

        tm.FlushGraphics();

        ed.UpdateScreen();

        tr.Commit();

      }

    }

  }

  public class Commands

  {

    // A command to create some simple geometry

    [CommandMethod("DTG")]

    static public void DrawTurtleGraphics()

    {

      TurtleEngine te = new TurtleEngine();

      // Draw a red circle

      te.SetPenColor(1);

      te.SetPenWidth(7);

      te.PenDown();

      for (int i = 0; i < 360; i++)

      {

        te.Move(2);

        te.Turn(Math.PI / 180);

      }

      // Move to the next space

      te.PenUp();

      te.Move(200);

      // Draw a green square

      te.SetPenColor(3);

      te.SetPenWidth(5);

      te.PenDown();

      for (int i = 0; i < 4; i++)

      {

        te.Move(230);

        te.Turn(Math.PI / 2);

      }

      // Move to the next space

      te.PenUp();

      te.Move(300);

      // Draw a blue triangle

      te.SetPenColor(5);

      te.SetPenWidth(3);

      te.PenDown();

      for (int i = 0; i < 3; i++)

      {

        te.Move(266);

        te.Turn(2 * Math.PI / 3);

      }

      // Move to the next space

      te.PenUp();

      te.Move(400);

      te.Turn(Math.PI / 2);

      te.Move(115);

      te.Turn(Math.PI / -2);

      // Draw a multi-colored, spirograph-like shape

      te.SetPenWidth(1);

      te.PenDown();

      for (int i = 0; i < 36; i++)

      {

        te.Turn(Math.PI / 18);

        te.SetPenColor(i);

        for (int j = 0; j < 360; j++)

        {

          te.Move(1);

          te.Turn(Math.PI / 180);

        }

      }

    }

  }

}

Here are the results of running the DTG command, which simply calls into the TurtleEngine to test out its capabilities, creating a series of shapes of different pen colours and widths:

The first three objects are single objects, but are multi-segment polylines (don't expect the engine to generate circles, for instance: most turtle graphics code to generate circles actually create objects with 360 segments). The fourth object is a series of 36 circles: as mentioned earlier, Polyline objects do not support per-segment colours, but if this was all a uniform colour (by commenting out the call to te.SetPenColor(i)), it would all be a single Polyline with 36 * 360 segments.

Cleaning up after yourself: how and when to dispose of AutoCAD objects in .NET

A question came up recently in an internal discussion and I thought I'd share it as it proved so illuminating.

If I have an object of a type which implements IDisposable, is it good practice to explicitly dispose it (whether via the using statement or calling Dispose() explicitly)?

The quick(ish) answer is:

Yes it is, but sometimes you might choose not to as the increase in code simplicity outweighs the benefits derived from manually disposing of the objects.

So, naturally, the devil is in the detail. Let's take a look at the three scenarios where you're likely to be working with IDisposable objects inside AutoCAD:

1. Temporary objects - such as those provided by Autodesk.AutoCAD.Geometry - which are never Database-resident
2. Temporary objects with the potential to be database-resident but which never actually get added to a Database
3. Database-resident objects added/accessed via a Transaction

Below follows the details on each of these categories.

Temporary objects of types not derived from DBObject

The first category of temporary objects, such as Geometry.Line, are safe to be disposed of either "manually" (by your own code) or "automatically" (by the .NET garbage collector).

Temporary objects of DBObject-derived types

The second category of temporary objects, which are of a type derived from DBObject, must be disposed of manually. It is absolutely unsafe not to dispose of objects of DBObject-derived classes from the main execution thread in AutoCAD.

Why is this the case? Firstly, the majority of the classes available through AutoCAD's .NET API are currently unmanaged, with a relatively thin wrapper exposing them to the .NET world. Inside AutoCAD, all Database-resident objects are managed by a single-threaded runtime component, AcDb (which, along with some other components, is productized as Autodesk RealDWG). A side note: if you're using ObjectARX or RealDWG from C++, don't be confused by the fact your project's C-runtime memory management is likely to be "Multi-threaded DLL", RealDWG is not thread-aware and so must be treated as single-threaded, for all intents and purposes.

And - secondly - on to the reason that automatic garbage collection is not to be trusted on DBObject-derived types: the .NET garbage collector runs on a separate, typically low-priority - unless memory is running short - thread. So if a DBObject-derived type is garbage-collected inside AutoCAD, a separate thread will essentially call into a non thread-safe component (RealDWG), which is very, very likely to cause AutoCAD to crash.

So you must always call Dispose() on temporary objects of DBObject-derived classes in your .NET code - you cannot rely on the CLR to manage your objects'  lifetimes for you.

Interestingly, this is also the reason why the F# code I posted in this prior post will not effectively leverage multiple cores (something I've just tested since getting a multi-core machine). We are using a Ray (which is a DBObject-derived class) to get intersection points with our path, and then disposing of this temporary object from an arbitrary thread (farmed off via F# Asynchronous Workflows). So this is unsafe, and won't run for long before crashing. At least now I understand why.

Database-resident, Transaction-managed objects

The third category of objects are those we use a Transaction either to add to the Database or to open for access. The good news is that - as the Transaction is aware of the objects it manages (via calls to AddNewlyCreatedDBObject() or to GetObject()), it is able to dispose of them automatically when it, itself, is disposed. So the key here is to make sure you wrap your use of Transactions in using blocks or call Dispose() on them when you're done. There is no need to explicitly dispose of the objects managed by a Transaction (unless there is a failure between the time the object is created and when it is added to the transaction via AddNewlyCreatedDBObject(), of course).

AutoCAD .NET version of the ObjectARX BlockView sample

Fenton Webb, from DevTech Americas, has been beavering away on a .NET port of the ObjectARX BlockView sample (found on the ObjectARX SDK under samples/graphics/BlockView). Thanks, Fents! :-)

Here is the C# source project for Visual Studio 2005. To build it you will almost certainly need to remap the acdbmgd.dll and acmgd.dll assembly references in the project.

One important note: if you load this project and try to view the BlockViewDialog in the Visual Studio Designer, the Visual Studio application will almost certainly crash. This is because the Designer is attempting to load into the dialog the GsPreviewCtrl component which depends on AutoCAD (and therefore cannot be instantiated outside of the AutoCAD process). At least that's what appears to be happening.

To temporarily allow the dialog to load - so you can make changes to the dialog's menu, etc. - you will need to edit the C# code in the BlockViewDialog.Designer.cs file. There are two edits that are needed - one that declares a variable for the control (lines 650-651) and one that instantiates it (lines 107-108):

Comment out line 650 and uncomment line 651, so...

  650     private GsPreviewCtrl mPreviewCtrl;

  651     //private System.Windows.Forms.Panel mPreviewCtrl;

... becomes...

  650     //private GsPreviewCtrl mPreviewCtrl;

  651     private System.Windows.Forms.Panel mPreviewCtrl;

And do the same for lines 107 and 108, so...

  107       //this.mPreviewCtrl = new System.Windows.Forms.Panel();

  108       this.mPreviewCtrl = new GsPreviewCtrl();

... becomes...

  107       this.mPreviewCtrl = new System.Windows.Forms.Panel();

  108       //this.mPreviewCtrl = new GsPreviewCtrl();

Then the dialog should load properly in the Visual Studio Designer, with no crash (although you'll need to change the code back to the way it was to build the application, of course).

As for what the application does, here's the original sample's ReadMe, updated to reflect the new application's behaviour:

------------------------

Block View Sample Readme

------------------------

- NETLOAD the BlockView.NET.dll module

- Run command BView at the AutoCAD command line.

- Default operation is to display the current drawing using the current view settings of the current drawing.

Function Descriptions

---------------------

File->Open

Opens an existing drawing into the Block View dialog (by clearing the GraphicsSystem.View).

File->Output Image to Disk

Allows you to output a JPG;BMP;TIFF;PNG files as a snaphot of the current view shown in the BlockView dialog.

File->AcGsDevice Config

View or edit the current GraphicsSystem.Device configuration settings.

View->Zoom

Allows Zoom Extents/Zoom Window/Zoom In-Out functionality

View->Settings->Show

Allows the toggling of various GraphicsSystem.View settings such as Linetype/Material and Sectioning

View->Render Mode

Allows you to switch the rendering mode.

View->View Style

Allows you to change the view style of the GraphicsSystem.View. It has the same options as the SHADEMODE command.

Tools->ReMap Colors->Custom

Allows you to remap the color palette. This is particularily useful if you want to show a GraphicsSystem.View as a paperspace layout, with a white background. In this case you will need to remap white entities to appear in a different color.

Tools->ReMap Colors->Standard Colors

Restores the Color Palette back to the original one.

Tools->Add an Entity->To This Database

Adds an entity to the Model Space and adds to the GraphicsSystem.View.

Tools->Add an Entity->Temporary

Adds an entity just to the GraphicsSystem.View.

Here's a quick snapshot of the BlockView dialog with a conceptual view of the standard 3D view sample:

A handy tool for migrating ObjectARX code to work with AutoCAD 2007 and beyond

Back in this previous post I mentioned a tool known as Teefy to help migrate C++ code to use Unicode for strings instead of MBCS.

This tool was previously only made available to ADN members, but we now have a version that is available for everyone. And here it is.

DWF Toolkit 7.5 available

Over on Beyond the Paper, Volker Joseph has just announced the availability of the latest version of the DWF Toolkit, which - excitingly to me, at least - supports the XPS-compatible DWFx format.