I’ve spoken to some colleagues, and we try to keep the Internal Origin and Base point aligned, so exporting relative to the internal origin makes sense.
Here are some workflows we are thinking about:
Revit → GIS: If the stream contains the Survey point, the receiving connector should be able to directly place the model in the right spot.
Rhino → GIS: so it turns out you can geo-locate Rhino models! Who knew? This is similar to the Revit → GIS case.
Microstation / Civil3D → GIS: These ones are a bit tricky, because road and rail alignments are big enough to generate projection errors if we aren’t careful. The sending connectors would have to send the Coordinate Reference System (e.g. EPSG code), which would be easily understood by GIS applications.
Microstation / Civil3D ⟷ Revit: There would have to be some mediation between the two different mechanisms for georeferencing (CRS vs. Survey Point), but I suppose if we’ve sorted out the first three items, this wouldn’t be too hard.
One other concept to consider is Revit’s Shared Coordinates. My understanding is that Autodesk gave up on getting people to properly geo-locate their models and developed the Shared Coordinate system to allow manual determination of the transform between two specific files. Perhaps Speckle could do something similar: when importing a stream, allow users to set the insertion point, and then retain that information for future imports. It’s not as ideologically pure as properly geo-locating each stream, but it lines up nicely with what people know and expect today.
@daviddekoning your understanding about Autodesk is correct, though if you set-up your templates correctly, the information is almost always automatically positionned over correctly (except for IFC files), with no manual work.
This is the key. It’s the situations where someone (usually from a company outside yours) provides a file that isn’t set up right where shared coordinates provides a safety valve. I agree that most of the time, proper set up deals with the issue correctly.
So I tried to load in solids through the speckle alpha connector, and it works! (whoow). One. major. downside.
It is positioned in revit on absolute coordinates in relation to the project basepoint… So my solids appear now around 400k too far from the internal origin. This is why it is important to use Shared coordinates or shared sites to position to. Is there a workaround known?
@Dickels112
I am working on this currently! Drafting up an option in the new Desktop UI to allow users to select which project point they want to receive objects in relation to.
This is gonna be a big change as it depends on some Transform work, so it may take 1-2 sprints to iron out! You can track the issue here
@clrkng Thanks a lot! currently i am just incoorporating a geometry.translate respectively to the absolute coordinates of the internal origin. Works like a charm! One optimization that can be done is for uploading complex solids. Can we incoorporate some sort of analytic where it checks solids for ‘size’ (not geometric, but memory size) and notify the user when a solid will take a long time to upload? (and maybe also give them the option not tot down/upload said solid) now my upload will just hang untill i remove the stream from my connector.
Ah yes this can be its own thread actually, feel free to start one! Being able to filter which objects to receive per commit is something we’ve discussed before and I agree it would be super useful to have!
Help! I am trying to send 2022 Civil 3d pipe networks to Revit 2021. I set proxygraphics=<1> and used convertto3dsolids command to turn the pipes into 3d solids. When I use the ConnectorCivil3d (alpha) to push to the stream, it crashes Civil3d. I was successful last week but no luck with my files this week.
I’ve tried moving the origin to a location that is within the pipe boundary.
I’ve cleaned up the file to reduce the file size - eliminating text, linework, etc to isolate the 3dobjects.
Would it perform better if I tried to push masselements our of Civil3d?
Thanks in advance for your help.
Tebogo
I am new to Speckle so Im sure that im making a mistake somewhere.
We have come across a few crash issues with our new connector UI and plan on fixing those soon, if you try sending from the old connector UI does C3D still crash?
Also - if you’re converting your pipes to 3d solids first, they will be sent as meshes to Speckle and received as meshes in Revit just so you know. If you’re looking to keep them as pipe elements, you don’t need to convert them to solids
In any case, it would be great if you could send me the C3D file with the pipes so I can debug and see what’s happening with the crash!
There isn’t a max number of objects iirc, but pinging @cristi for the current limit on DB object sizes! I think it was 10MB? Keep in mind this limit isn’t determined by your file’s size, every time you send to Speckle, the connector will serialize all of your selected objects and the size of that “send” is determined by how many and how complex the objects are.
Hello @Tebogo_inertia , the file was super helpful, I managed to pinpoint a few issues actually! Really appreciate you sending it over. The fix has been merged and will be available with our next release, this is the test stream with the elements from one of your files:
There were hundreds of invisible null solids in that file, which may have been a result of your manual pipe to solid conversion? They aren’t selectable on screen but will be selected with SelectAll if you’re using that command to send via our connector. They should be skipped now, but sometimes the connector will hang (not crash) if they are selected.
@clrkng This looks like a great add-in with lots of potential! I have been testing getting C3D pipe networks into Revit, but I am only able to adjust the coordinates on the Revit side when sending or receiving: (within the Advanced Settings from the connector add-in)
Does this setting option need to be available on the Civil 3D add-in as well? I do not see the same setting options when sending a commit from C3D. (I believe this is why I have not been able to get things to show in the correct location in Revit.)
So far, reference point options for sending and receiving have not been implemented for Civil3D yet, but that has been in our backlog for awhile!
I’ll look into adding survey point options for Civil3D when I get a chance, but also keep in mind that Revit has a limit on distance from internal origin which may prevent some civil-scale objects from being generated regardless of the transform applied to them.
I’ll let you know when this has been added to C3D and would be happy to get feedback from you after
I think adding the option to edit the reference point of the original software in another software is introducing a lot more complexity… is it not better to introduce the georeference on the stream as a general reference, where in the webUI we can edit it if necessary? in this way you can guarantee that people do not mess with references every time things are sent
Ah to clarify, the Reference Point Advanced Setting sends or receives your objects relative to the selected project point - it doesn’t change the project point in your document.
We’re adding some new Organization classes soon to include settings, so you’ll be able to see which Reference Point was used in your commit!
Love this!
From civil engineering standpoint, the ability to maintain 1 single source of truth regarding the reference points is fundamental and always a great cause of catastrophe when people change it. being able to see what is used is a great added value, as well as enforcing it throughout the project.
Hi @yun_sung , could you share the exact version of civil 3d you have installed (including the language pack)? You can post to this thread instead so we can continue to track install issues
