Future of Civil 3D Toolkit and Camber Packages

Civil 3D
21

Hi, in my opinion, the simplest and most meaningful name for all customers and users would be Civil3DToolbox.

After a lengthy discussion with ChatGPT, I believe the best name would be Civil3DCator.

“Ca” refer to Camber, “t” refer to toolkit “or” refer to “origins”.

“Cato” refer to a historical figure Cato the Elder, a Roman statesman. He wrote “Origines”.

“Origines” is a Latin word meaning “origins” or “beginnings.” In the context of historical writings, “Origines” often refers to works that discuss the early history or origins of a particular society, civilization, or institution. For example, Cato the Elder’s work “Origines” was a historical treatise that explored the early history of Rome. It likely covered topics such as the legendary founding of Rome, the early Roman monarchy, and the establishment of the Roman Republic.

“Cato” is from “Catus”, which is a Latin adjective meaning “sharp” or “clever.”

22

Did your chat gpt know that “ We do roads and stuff” was already taken?

23

TOOLKIT-DWG
\------------ TOOLKIT-CAD to Autocad api nodes
\------------ TOOLKIT-C3D to C3D api nodes
\------------ TOOLKIT-RVT to include Civil Comunication
\------------ TOOLKIT-EXT to inculde External Tools
\------------ TOOLKIT-ARK to include Arkance Systems
\------------ TOOLKIT-OMP to include Open Mep Autocad
Very basic and technic i know is just an idea :cowboy_hat_face:

24

Pretty sure it’s just Civil 3D Toolkit and Camber which are merging into one repo… OpenMEP and Arkance will still be stand alone (though if we got all of Dynamo for Civil 3D Open Sourced they might be able to be rolled into the core via a PR)…

25
  • CamberKit ? too obvious?
  • Community > emphasis on why we are doing this
  • CerealKiller
  • Ninjaneers
26

As to say that road design did not improve much after romans :slight_smile:
After reading this I’d propose also ‘Cardo’ and ‘Decumano’ (the two main roads of any roman cities), from there you know where to start and then you can literally go anywhere.

27

Well if it is an integration project why stop only with Camber and Civil3DToolkit perhaps create a structure of namespaces to let open the door for future colaboration and posible integrations with others packages with amazing classes and methods will be interesting!! (I’m writing since user point of view i know is not so simple as that), but is already a great initiative!!

28

Taking inspiration from Paolo’s suggestion of “Community” …

  • CampFire (suggests imagery of people sitting together as a community)
    or
  • CivilCampFire (to more explicitly emphasise the intended audience)

I did a quick check in the Forum search and Package Manager, it would seem to be available.

29

I’m really liking the community theme that is emerging.

What do you all think of CivilCollab?

30

Tribe

31

Almost more important than a name, when will it be released? We all have Civil 3D 2025 already installed but can’t do anything yet :wink:

And not too modest, just name it: “The Civil 3D Node Collection”

32

I personally won’t have any time to work on this for a few months, and Paolo’s time is limited as well. I would feel pretty confident about committing to having the first version ready by the end of summer, so let’s go with that for now.

33

We’ve got a few naming options now, so let’s do a poll. I tried to grab at least one from each person. You get up to 3 votes!

What should we name the new package?
  • CamberKit
  • Civil3DCator
  • Civil3DNodeCollection
  • Civil3DToolbox
  • CivilCampfire
  • CivilCollab
  • Civilize
  • Community
  • DynaCivil
  • Toolkit-C3D
0 voters
34

Looks like we had a tie at the top for DynaCivil and Civil3DToolbox, so I’m just going to pick one so we can keep things moving. We’ll go with DynaCivil since it’s fresh and will provide a little more distinction/separation from the existing Civil3DToolkit.

Thanks for voting! I’ll get going with some preliminary stuff as soon as I’m able and keep you posted.

35

Firstly i am gratful for the contribution the authors have put into these packages.

Can the package not be called “WishTheseWasCivil3dOotb” :wink:.

On a serious note “DynaCivil” seems the better of the options because there may be elements within the package that are for “Autocad” and not just “Civils3D” therefore this seems a better package name.

36

Hi folks,

Just wanted to come back with an update on this topic. In order for the Civil 3D Toolkit (not open source) to be combined with Camber (open source), the Toolkit source code would first need to be made publicly available. I have been working on this, but for a variety of reasons this is not going to happen. This means that the two packages are going to remain separate. I am sorry for the news!

Since I am an Autodesk employee, my efforts are focused on improving the out-of-the-box experience in Dynamo for Civil 3D. Camber was a side project for me when I was still working as a civil engineer, and it no longer makes sense for me to work on it. Please see my recent post in the Camber Feedback Thread for more information.

I cannot speak for the Civil 3D Toolkit as I am not the author/maintainer. My recommendation is to direct any comments/questions to the Civil 3D Toolkit Feedback thread.

39

Unfortunate but I totally understand it. The same is true for me, I had no more bandwidth to work on the Civil 3D Toolkit for quite some time, I’ve been working on entirely different types of projects. The agreement we had with Zachri and the rest of the team was not to release any more versions of the Toolkit and I stand by that. What we could see is if we can open source the code as I did for CivilConnection many years ago (but even then it took a long time to get it approved).

40

Open sourcing packages is good, but with the number of gaps in the product it isn’t going to solve things.

Personally I feel the ideal solution here would be to open source not Toolkit but Dynamo for Civil 3D (we know this is an option as it happened already with Dynamo for Advance Steel and Dynamo for Revit) so that community members can start to contribute directly (just like happened with Dynamo for Revit).

If that happened people who are working on projects that require authoring a node to replace a toolkit or Camber node could contribute their cod to the D4C3D repo instead of another closed source solution that doesn’t coordinate with other packages. And while those PRs might not be entirely build ready for stuff like localization or help documents, but the Autodesk internal team can deal with that much easier than the total sum of all work (what is currently on their plate).

This would also allow packages from other users to consume common wrappers more readily and enable cross-functional use of nodes from packages and not as the wrappers could be pushed into D4C3D directly… Just seems a good ‘fix’ for an otherwise ugly situation.

41

Just to add my 2c.

I was already working on a new version of the Arkance Systems Node Library, but slowly, because the old .NET 4.8 Framework package seemed to work in Civil 3D 2025, contrary to expectations. When 2025.1 came out, suddenly all packages were broken. C3DToolkit and Arkance nodes no longer load. Camber can be loaded in Dynamo, but several nodes do not work.

In the Autodesk Feedback forum, Zachri stated more clearly that no updates are to be expected for C3DToolkit and Camber. This also means their plans for the combined package have been canceled.

So, suddenly I needed to accelerate in my development. In consultation with Zachri, I suggested to take over code from Camber and merge them with my nodes into a new package. Because C3DToolkit is not open-source, I suggested to reconstruct the most interesting nodes from scratch and add them too, to the new package.

Because there are lots of nodes in the Core now, that do the same or are at least similar to nodes from Camber, C3DToolkit and Arkance nodes, I made a list of all nodes that did not found a way to the Core yet. I have plans to add (part of) the list to the new package.
But because of the big API breaks in 2025.1, it takes a lot of time to rewrite my own nodes (and also make them compatible with the new Core objects), and lots of the Camber nodes don’t work either in 2025.1, which take a serious amount of work to rewrite them.

I am not finished with adding all missing nodes yet, but it feels becoming somewhat urgent to publish my new package sooner than planned. However, there is a big drawback, the new package is only for Civil 3D 2025.1 (and higher, until, but hopefully not, another big break occurs). That means that all existing scripts from users need to be rewritten and are not backwards compatible, in case such is needed.

So within a short time from now I will publish a new package for Civil 3D 2025.1 and up, with nodes combined from Arkance, Camber and C3DToolkit, with the expectation that I will add more missing nodes later. It will help users to make the step to 2025 instead of staying with older versions. It is not my intention to keep the source closed, but I know from experience that there is little to no interest in code, or contributing to programming. I also was told that Autodesk don’t want to use code from outsiders, which is understandable. What @jacob.small suggests, making Dynamo for Civil 3D open source, will likely not lead to an expansion of functionality.

And to end this tl;dr with a smiley :slight_smile: else it looks too much like a rant :stuck_out_tongue:

42

This is contrary to what we saw with Revit in the early days, so unless you can point to something which makes the Dynamo for Revit user cohort different from the Dynamo for Civil cohort I can’t say I agree, and with the overlap in the venn diagram of the two it’s pretty much impossible to say that with a straight face… And even if no PRs come from the open sourcing of the library the benefits in referring each other to functional examples vastly aid developers as ‘the core node library’ should set the standard which other packages aim to meet.

As an example, how would you add extended help to the node Geometry.CreateRectangleByDimensions (this may have been done but I don’t see it in the version I have installed at the moment)? Having a completed example in the context of Dynamo for Civil 3D is likely far more useful to you (and many others) than the generic tutorial we have now on the primer. Or how does one move a dropdown selection for getting a particular ‘TinSurface’ to the “selection” section of the library? Or how do we decide when such things go in “Selection” vs in their core category? Or how do we get Civil3D toolkit to show up in the library as something other than ‘Autodesk’?

While package authors are not required to do any of these, it certainly helps end users adopt to a package if things are consistently implemented, and production ready examples go a long way towards setting such a standard.