SAC vs .NET

[joantopo]

Hi.

I think that now I have a good level using SAC and I am thinking to make some custom subassemblies in .NET with Visual Studio.

I have done some apps for Civil 3D using the Civil 3D API.

These are the API class functions of SAC:

http://help.autodesk.com/view/CIV3D/2014/ENU/?guid=GUID-FC2ED292-C1EB-4B2A-B4B5-C8654529FB00

Can we get more API class in .NET?

I would to get specially 2 operations:

-get the section points of a surface section (from a surface target).

-reiteration (Do while..)

But I don´t Know if the limitations in SAC is nearly the same in .NET.

Thanks in advance.

[AKoerner]

Hi Joan,

Look at the sample stock subassembly code provided with your C3D installation (e.g. C:\Program Files\Autodesk\AutoCAD 2016\C3D\Sample\Civil 3D API\C3DStockSubassemblies)...you will find samples of how to sample section points on a surface there (one such example exists at OverlayMillAndLevel1.vb at line 690:  'arrSampledSectionLinks = corridorState.SampleSection(oSurfaceId, oAlignmentId, oSampleBeginPoint, oSampleEndPoint)'). 

Be sure to take a look at the abstract base class (SATemplate) used for all of the stock subassemblies as well...you will need to replicate at least the public methods exposed by this class (and if you follow a similar architecture for your subassemblies, you'll need to more or less replicate the protected ones as well) in your assembly as C3D will be looking for methods with specific names in your subassembly.  (BTW, IMHO this would have been a textbook opportunity to use an interface that could have been used for all subassemblies instead of using reflection to find and invoke specific methods, but I digress...)  Also take a look at a few simple stock subassembly implementations to see how to implement an actual subassembly, and to find more examples of how to accomplish specific tasks.

FYI other useful methods and techniques can be found in the Utilities class among other places.

A few additional bits of advice:

• When working with subassemblies, you need to be aware of what coordinate system/origin you are using at any given time (usually local w/the coordinate system origin at the subassembly origin point), and make sure that you pay attention to the local subassembly to assembly coordinate system transformation (a simple translation) if you need to use absolute offset and/or elevation values within your subassembly.
• Subassemblies should always be implemented using a right-oriented coordinate system for internal calculations...for horizontal distances and slopes you 'flip' the sign if the subassembly is oriented to the left...  You may or may not need to do this with superelevation values depending on how it is defined and what you are doing with it.
• Start simple, experiment, and experiment some more to learn how the various parts all work...  🙂
• Don't forget about your ATC file...

[Civil3DReminders_com]

In my opinion .NET is way better to use. You can actually go in and figure out what is wrong with your subassembly and then correct the issue (such as the looping problem in one of your previous posts). You can go and use text files and other data while running the command. My favorite is a retaining wall subassembly that goes and grabs standard values as well as letting the user modify the values to meet the project conditions. After working on 50 or 60 SAC projects I've come to the conlusion SAC may be easier, but once you get into a difficult problem you would have been better off using .NET to start with. 

[joantopo]

Thanks both.

Well, I don´t understand a thing.

When you are making the subassembly in Visual Studio, you finally creates a .pkt file

You import this file as if was a pkt created from SAC. Am I right?

So, when you use that subassembly in Civil 3D, how do you import a txt file?  Can you create an imput parameter to choose a path and the file?

[AKoerner]

You're welcome Joan.

FYI, in Visual Studio you create DLL files for subassemblies (.NET Assemblies to be precise).  These, combined with images, documents (help files), and an 'ATC' file (an XML file with a particular schema) go into making a PKT file (which is actually just a ZIP archive...you can open a PKT with 7Zip, etc, or rename to .zip and open in Windows Explorer) if you want to see what goes into one.  FYI, SaC PKT files will contain other files as well.

Also, I put together a short video based on some of our conversations re iterations in subassemblies.  I know it's a lot more basic in nature than what you have in mind, but the purpose is to simply demonstrate how the key feature sets are used.  Extending this to more complex designs is generally not very difficult (depending on the subassembly design of course...).  Please have a look at the following and let me know what you think:

civil+plus on YouTube: A Benched Slope Subassembly Targeting Multiple Subsurfaces

This subassembly uses manually specified subsurface targets (0-10 --this limit is completely arbitrary...it could have just as easily been 100 or anything else), sorts by elevation, and then iterates through all valid surfaces in the sorted collection to create a series of cut slopes and benches.  Once the last subsurface is reached, it then daylights to the top-most/existing ground surface.  Pay particular attention to how simple the subassembly component list actually is (very little is required to accomplish this in Subassembly Studio).

The feature set I leveraged for this is not limited to just surfaces...it works for pipes, alignments, profiles, etc too.  Cut or fill doesn't matter...just design the logic accordingly.  The geometry created can easily be used in shape definitions, etc.  Also, we can configure this to automatically 'find' all of the subsurfaces based on name or style name so that you don't have to specify the targets.

...and the best part:  you don't need to know .NET nor do you need to attempt to manually create/modify an ATC file 😉

Best regards,

[joantopo]

Hi Adam.

I just want to practise in .NET to know the default properties and methods that API has.

My aim is not create new libraries or classes in .NET.

I admit I want to buy SaS in the future which has a lot of classes to do complex operations.

But I don't know how you choose a txt file in Civil 3d for your SA.

Regards.

[Civil3DReminders_com]

In .NET you can read a text file in. This is one way to do it. Here you can create a text file and put things into it. You'll want to check to see if the file exists first though. 

[doni49]

Joan,

I'm confused. You said that your is not to use .net. So what exactly are
you looking to do with the text file?

[joantopo]

I talked with Adam 3 weeks ago about this.

The idea is getting data from a TXT file.

What kind of data? in particular, data with the format "station,offset,elevation".

If there is no coincidence of the station, then is calculated by interpolation or extrapolation.

Instead of using a surface target in Civil 3D with a Surface object, we could use a "virtual" surface from an ASCII file. ("virtual" surface is an idea from Adam)

@Civil3DReminders_com I know the StreamReader class in .NET, in fact, I use it in my add-in, but I supose that the txt file must be included in the PKT (zip) file, don´t I?

Or maybe, you can call an external file from the subassembly, in fact, this is really my question:

Look at the picture (subassembly properties form): can we add a parameter called "path file" with a button with ellipses to show the OpenFile dialog?

Obviously, I won´t do this in .NET, is just a curiosity.

Regards.

[Civil3DReminders_com]

No, you don't need to include the text file in the packet file. You'd either copy from a location on a server, from the internet, or populate the text file with standard data that the user could then change after they run the program once. I'd put the text file at the same location as the DWG drawing so I wouldn't have to worry about path. 

What you put in the text file is endless possibilities to meet your needs. I'd use it because I could take a comma seperated text file, open it in Excel and change any of the values I wanted to change. Much easier than the properties dialog in Civil 3D. I'd have a type dropdown in Civil 3D with standard cases that would allow me to pick a row from the text file.

[joantopo]

quote:"I'd put the text file at the same location as the DWG drawing so I wouldn't have to worry about path. "

Nice!!

Do you imagine a data table object in AutoCAD with a dynamic link to the subassembly?

If we edit the table automatically updates the corridor!!

[Civil3DReminders_com]

I haven't done it that way, but theoretically it would work. The only issue would be if you wanted to two tables since AutoCAD only allows one data linked table per drawing (or at least that was the case last time I tried it).

[AKoerner]

Putting the text file in the same location as the drawing (or a subdirectory under this location) would be the correct solution for Joan's scenario - it's project data, not generic global settings for the subassembly.  Just in case it's not clear, in this scenario the text file would contain Station-Offset-Elevation data (e.g. bathymetric survey data for a channel, or laser scanned data in a tunnel bore). Of course, you are not necessarily limited to a text file for this either, nor are you limited to using a local file or data source (as Christopher correctly pointed out).  If you use a URL you could locate the data anywhere...a URI could also be used in place of a URL in the same parameter if you want to locate the data locally/relative to the drawing location, which could be easily determined via the AutoCAD API at subassembly runtime.

The problem I see is that it may be difficult to match up the corridor stationing to the SOE file stationing...how do you handle stations in the corridor where you have a 'miss' with respect to the SOE data?  Even if a generous tolerance is used, a 'miss' may still occur.  If you are working with point cloud data instead, how do you deal with sampling and filtering it for the current station?  I think I have what could be a very good solution in mind (plus a few backup options as well), but it's not a trivial implementation (unfortunately it's quite a bit of development even just to prototype this).  If there is interest in creating something like this please let me know.

Also, you could theoretically use a text file (or other file/data source?) for storing common input to subassemblies, however, there is a much easier (and better performing) option for this particular task within Subassembly Studio (SaS) - create a 'parameters' subassembly that accepts the common values and use the x-record storage feature in SaS to store these; then have your subassemblies read from the stored x-records, which are indexed to station, etc.  The parameters subassembly is inserted to the assembly first, allowing subsequent subassemblies to utilize the stored values.  If anyone is interested in seeing this let me know and I'll put together another video 🙂  It's really quite easy to accomplish this.

BTW, we don't currently have a 'read file' feature in SaS, however, we do have a feature for exporting text/CSV files 🙂  (e.g. customized log files for corridor builds, etc.)

[joantopo]

Hi @AKoerner ;

Obviously, I will avoid those scenarios that you comment:

The problem I see is that it may be difficult to match up the corridor stationing to the SOE file stationing.

If I had this tool, I would use it just for particular scenarios:

-Example 1:

When you haven´t got a surface object in your drawing file because a third part doesn´t want to share the LandXML file about TIN surface data.

This is typical in Spain, unfortunatelly, so you only get a TXT file (station,offset,elevation) and the alignment.

With this data, you can create COGO points and add them to a empty surface.. but, you don´t know the breaklines.

So, if you have a TXT file, you can also create a surface object in Civil 3D from this data with a fast way: you will use a corridor with this custom subassembly, The Top surface will be the EG surface that you want, and you will get the properly boundary from the corridor boundary.

In fact, most of the Civil softwares have this function to create a new surface from TXT file.

I have a command in VisorNET, which can create a new SampleLineGroup and SampleLines reading this TXT file. It creates a new SampleLine in each station.

In Spain, it is typical compare data from 2 txt files (station,offset,elevation) to compute materials (from 2 surfaces), but we cannot do this in Civil 3D if we don´t have previously a Surface object...

-Example 2:

Currently, Civil 3D has a command to create a subassembly from a polyline. (CreateSubFromPline)

So, instead of drawing the vertex of the polylines, you could have a TXT file to fake a virtual corridor section.

The most times that you use the txt file to a subassembly, it is to fake a corridor section, but this will be the only assembly in that corridor, I mean, you will have just one Region in your corridor.. maybe is a setup corridor, for example.

So, about the corridor, instead of creating the station(frecuency) from the corridor, you will get the stationing from the TXT file to create Sample Lines.

Hardly ever, or never, you will combine this "technique". This subassembly( just one in the assembly), fakes a "irregular" corridor section to get its surface.

Regards.