If you’re familiar with Dynamo for Civil 3D, you are likely familiar with using the Civil 3D Toolkit and Camber packages. The Toolkit was created by @Paolo_Emilio_Serra1 and @safi.hage, and I created Camber. I think it’s safe to say that both packages have been an integral part of the growth of Dynamo for Civil 3D. As of today, there has been a total of 99,000+ downloads for both packages combined, which is INCREDIBLE!
Speaking on behalf of all the authors - thank you for all your feedback to help improve these packages over the years
Both packages were developed as side projects in our spare time, because we love Dynamo and want everyone else to love it too. You’ve probably noticed that they haven’t seen much development in awhile, and it’s because our free time is more limited now. We want these packages to continue benefitting the community in a way that is sustainable.
So, what should we do next? Tell us what you think!
Keep packages separate
Merge Toolkit into Camber
Merge Camber into Toolkit, make Toolkit open-source
Combine projects and publish as a new open-source package
I’m all for consolidation but need a way to update Camber and Toolkit nodes used in legacy scripts automatically too! I’m sure you have that figured out already though :). Would also be great to have a way of enabling others developing custom nodes to submit for approval and integration into the new consolidated approach you all come up with! A lot of the scripts I create and share out with my peers require them to install multiple packages to properly run, so anything we can do to streamline that coordination the better off we’ll all be.
Yes! Both Camber and Civil 3d toolkit are awesome and power a multitude of very functional scripts in the community. We would need to minimize the amount of rework on older scripts.
I’m but a humble low-code user with a few questions:
Could you explain what making Toolkit “open source” means and why it matters?
Will this potential combination result in Camber and Toolkit nodes becoming compatible with each other?
Is this project another side project for your free time or is this an Autodesk project?
If this is an Autodesk project, does this mean that there will be a support sytem put in place around these packages so that the 45,000+ users of Camber and Toolkit do not have to continue to rely soley on the kindness of two particular strangers. As you say, you and Paolo have less free time to maintain these pacakges, but that leaves a sizeable user base accepting a certain amount of risk should these packages become completely unsupported and the API were to change…as reflected in the recent .NET 8 updates with Dynamo 3.
I like the idea of combining both toolkit and camber. My only concern would be how will it affect old script that uses camber or toolkit will it still work as legacy package? Will the newly combined consolidated package allow old node to work as well? If yes then combining both package to new would be my vote.
My thought on this: we (the community, not Paolo or Zachari) build a one time transfer tool that remaps old nodes with the new ones in bulk - effectively allowing D4C3D managers to split there library between pre 20xx and 20xx and up. It might not work to get all ports correct, and some cases it may not be feasible but if we can help ease the pain of a migration (of required) then that is a good thing.
It’s likely that C3D will soon start to have to utilize a ‘graph and package library per C3D version’ the way Revit managers do (or perhaps likely should), but with the limited number of major packages in the C3D space we can likely mitigate the pain much better.
Making it open source means that everyone will have access to the source code of the nodes, you will see how things are made and the community could carry on the maintenance / extension of the nodes. This allows to mitigate the risks you were mentioning, at least in part. @jacob.small has pointed out something that I do believe will have to happen (a ‘b.C.’- ‘a.C.’ - where ‘C’ is the initial of the new package ) also due to the external factors like the migration to newer versions of .NET (which are out of control of those involved here).
This whole initiative is just because we care. For me it started almost 9 years ago, way before Dynamo for Civil 3D was even a thing. We were once customers at some point, we are still people that want to see the industry grow and succeed and have an impact. We know what it means to feel power-less, or empowered, by what we know or the technology we use and this motivates us deeply. That is the spirit of the Dynamo Community since day 1 and we adhere to those values. This is the way by which anyone who feels compelled to help and has the skills and the means to do it can now write another page of the story of this community. We probably could have done this before, let’s say that now planets are aligned
Sure thing. “Open source” means that code is publicly available and can be contributed to by anyone (per certain guidelines, of course). Camber is already open source, and the code is available on GitHub. The code for the Civil 3D Toolkit is currently not public. This doesn’t really have an impact on actually using either package in Dynamo. It just means that it opens the door for a more community-driven project
Yes! Aside from the Keep packages separate option in the poll, all the other options would result in a single package where all the nodes “understand” each other. Keep in mind that this would only be true for new versions moving forward. Existing versions that you currently use are not going to change.
Great question. Any work in this area is separate from my role at Autodesk. I developed Camber before I was an employee at Autodesk, so there is no affiliation. I have to wear two hats in that sense
This is an important topic that I’d love to talk about further, but I can’t do so publicly. If you’re willing to hop over to the Dynamo forum section on Infrastructure Futures, I’m happy to continue the conversation.
The toolkit, camber and arkance is truly the holy trinity of civil 3d productivity tools. I can’t express how much value I’ve created for my firm and the agencies we serve by utilizing them. By consolidating the packages more and improving their interoperability, it will make the workflow of graph development even better. The open source thing also sounds like a great idea. We’re all busy and like people have said. There’s a lot of people depending on the kindness of “two strangers”! Even if they’re some incredible people!
Thank you both your your efforts on these packages, and the willingness and energy to now combine them in some manner, and to have them both open source.
These are powerful nodes and I am excited to see which option is selected, and of course, how all of this is managed with the .net 8 updates.
Thanks for the feedback, everyone! It looks like the preferred approach is to combine nodes from Camber and Civil 3D Toolkit into a single open-source project and publish as a new package, so this is how we’ll proceed.
There are more details to work out, of course, but the obvious first step is to decide on a name for the new package
Any ideas? I’ll kick things off with some random ones
Seriously though I recommend not using Infra in the name as the last I checked Dynamo for Infraworks was still on the roadmap (and therefore keeping that name clear might prevent future headaches).
