What’s New with the AutoCAD Civil 3D 2012 API

The 2012 releases will soon be out the door, and with them, all the excitement of the new features. We, the API team, have also very exciting news for you. We worked very hard for the past year to deliver new features and enhancements to you. Keep reading if you are curious about what’s new with the AutoCAD Civil 3D API.

The major API feature included in the 2012 release is the Surfaces .NET API. This feature was very limited in the COM API, and some will say very hard to use. The Surfaces COM API exposed the feature functionality at a very low-level, making it very hard to use even for experienced users. Using it gives me the creeps, and I find it very hard to do anything useful with it. The good news is, it is all in the past.

With the Surfaces .NET API, we took a step back and looked at the feature functionality to determine what users will want to do with the API. We redesign the interface to provide real abstractions that are easy to use and give you all the power. Long gone are the arrays of doubles required to interact with points and triangles. Now, there are surface vertices and surface triangle objects that provide the necessary interfaces to get the job done. We also looked at features customers were requesting and implemented them in the new .NET API. It took us quite some time to get it done, but I am sure you and all our customers will be very happy with the new implementation.

Back in the 2011 release time-frame, we had several customers reporting huge performance degradation when using the Corridors API. We have always told customers to move from COM to .NET as new APIs become available, but doing so with the Corridor API was near impossible because of the performance issues. We worked hard profiling Corridors, and sure enough, the API was consuming most of the resources available in high-end machines. Once we found the bottlenecks, we started refactoring the code to improve it and make memory management better. The results are outstanding, and you will notice them on your first run. These improvements were made available with the AutoCAD Civil 3D 2011 SP1 release, but 2012 includes other fixes and improvements. As an example, we added support for ‘SetAxisOfRotationCrownPoint’, ‘SetAxisOfRotationInformation’, and ‘SetAxisOfRotationSERange’ to the ‘CorridorState’ object.

You will also find other minor, although important, improvements in the new 2012 API. You will find support for new alignment entities that were added to the feature. We added new overloaded methods to the ‘AlignmentEntityCollection’ class to have more control adding curves and spirals, and expose the label type for the alignment indexed PI label style.

Finally, we completed support for existing features where we might have missed some functionality or new functionality was added. We improved the QTO API to add support for sectional, volume and quantity takeoff results, and added support for the new rotate label feature in 2012. And, we completed the Styles and Settings API, so you can access all styles and settings exposed by Civil 3D 2012.

This was a great release, and I want to congratulate my team for their effort to make it possible. There was a lot of work to be done, but they pull it out, most important, they maintained stability and quality. With the new features and improvements, I am sure our customers will be very happy to upgrade.

Comments

[Mike]

Issac,
Question concerning .NET custom subassemblies, the custom subassemblies we wrote and compiled for C3D 2011 are working fine in 2012, any reason we would need to compile them for 2012?

Thanks,
Mike Robertson
Fl. Dept. of Transportation

[Isaac Rodriguez]

There hasn't been any changes in the API's related to subassemblies, so I do not forsee any problems.

Usually, you want to look at any new functionality that may have become available in a newer version that you want to leverage, or any bug fixes that might have been included. I believe there are no changes in any of this areas, so you might be all set.

Having say that, you want to insure everything is really working as expected. Keep in mind that the .NET code is actually accessing the native code in the DBX side on the application, and there might be some binary incompatibilities that my pop-up. Usually, these incompatibilities appear right-away, meaning you find crashes or weird behavior as soon as you try to use your code. If this has not appear yet, you may be all set, but you want to make sure you test all possible scenarios with your subassemblies before you ship them to your customers.

[James Maeding]

Hi Issac,
Something that constantly puzzles me is how the data structure of an alignment and profile is fairly rich (allows vertical curves, and profile independent from what horiz align segments are doing), while the feature line data is junky (no VC's, only profile points at line/arc start/ends). yet the editing interface of feature lines is relatively rich (editing in plan view) and alignment editing is junky (grid only and in profile view). Most people i know need to see the profile points annotated in plan view and the ability to input or edit points by picks in plan. Your library could do some things to help with this. A plan view profile editing interface might be a good example project to get interest in your code.

[Isaac Rodriguez]

Hi James,

Thanks for your suggestion. Unfortunately, there are limitations on what the API can do because of the functionality the feature exposes to the API.

The kind of editing that you would like to see needs to be supported by the underlying feature for us to expose it in the API, but I will talk to the Alignments and Profiles team and suggest your feedback as a feature.

[James Maeding]

The big need I see with surfaces is a weeding mechanism. Not point weeding, like currently available, but something that detects ridges and valleys, and creates breaklines (in memory I guess) then starts to remove points between the breaklines, as well as create fewer points along the breaklines. IMO, surfaces will be crippled for a long time until someone does this, as the mechanisms for creating them cannot distinguish between flatter areas and ridged/curving areas so you have to do it after. Resampling with points like a DEM is not the answer, it too is unaware of what is important.

[Isaac Rodriguez]

Hi James,

Sounds like an interesting proposal. I'm writing it down, and we'll see what we can do about it.

[James]

I thought about my post, and have always had the opinion that it was not fair to ask someone to program something I could not explain with words. I was thinking, "how do you decide what is a valley or ridge", as everything essentially is except exactly planar tirangles. I think the answer would involve cutting thin sections, and looking at the profile for peaks and valleys. That would yield points of interest along the section. They would be seeds to start making breaklines along the triangles that formed the breakpoint. If you did that in a grid pattern, you would only maybe miss very small areas. Once you had breaklines, sample points on the surface grid style, to make the rest of the surface info. Then weed the breaklines and points as desired to simplify the surface. Not saying this is easy, but your programmers might be interested in this.