Custom 3D objects, native inside Civil 3D
Bespoke stormwater objects Civil 3D can't model natively, built computationally and delivered back as native 3D solids.
The problem
A civil team's digital engineering requirements called for LOD 300 models of things Civil 3D does not natively support: custom risers and flushing points, an L-pipe with a concrete surround and a cap, across an entire stormwater network. Hundreds of them. The usual answer is to leave Civil 3D for another 3D package and retrain the team on it, or to approximate the objects, or to leave them out. At that scale, none of those is a good option.
What I built
I took their stormwater network out into Rhino and built the risers computationally in Grasshopper, pipe, concrete surround, cap and all, positioned from the project’s own data. Then a Dynamo step brings the finished objects back into Civil 3D. The team points at a folder, hits run, and the objects populate.
Civil 3D stays the centre of the work. The computational modelling is a part they hand over, and it comes back in.
What makes this work
The objects land as native, editable 3D solids, not proxies, sitting in the model alongside the corridors, surfaces and pipe networks, so the team can manipulate them like anything else. They get the objects their requirements demand without ever leaving Civil 3D or learning a new tool, and because it is a script, hundreds regenerate on a rerun when something changes.
What changed
The team met a requirement Civil 3D could not, at the scale of a whole network, without switching tools or retraining anyone. When the design changes, the objects regenerate rather than being rebuilt by hand.
Notes on maintainability
The objects are ordinary 3D solids once they land, so the team can still manipulate them like anything else in the model.