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.
Hello @Tebogo_inertia !
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!
Thank you for the speedy reply. the file is too large to copy here so I will send you a dropbox link. Can you provide an email?
Also, does Speckle only handle 3d objects or can it send linework?
Is there a maximum amount of objects or file size?
Just messaged you my email!
You can find a (somewhat) up to date version of all supported elements on our docs page here: Supported Elements | Speckle Docs
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.
Hi Claire - any luck with the files I sent you?
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:
One main thing to note:
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.)
Hi @kjgerke , welcome to the community!
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
You can follow along with the status here: feat(acadcivil/bentley): add reference point setting options · Issue #1021 · specklesystems/speckle-sharp · GitHub
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.
hello there, i cant get speckle to show up in civil 3d 2021 , after installing + restarting the PC using the latest build.
I have tried looking in the add-in tab and typing it into the search box
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
There is a suggestion, not mine, further up this thread that Speckle might be usable as a coordinate system hub. To me this is an attractive prospect, that potentially does away with a lot of the issues of the user setting it up wrong, or not at all.
Is there any scope that instead of speckle trying to rectify one apps setup against another, it might be better to offer to turn the problem inside out and have the user pull coordinate setup, with appropriate context complexities, which are lower for building and higher for infra into whatever authoring software they are using.
Hey @rklaschka good to see you.
Could you expand on what you mean by “Coordinate Setup”, I can instantly think of many things it could mean.
You’ll find there are numerous other discussions/streams of consciousness here in the community about coordinates as Speckle supports software with assorted capabilities and across our users with Macro to Micro endeavours. Our recent work in the GIS space has been to attach custom CRS on send/receive, And also with Revit to optionally use similarly defined coordinates as the reference for spatial remapping. Rather than Speckle fixing/rectifying anything.
Certainly, it is something I have wrestled with in my embryonic third-party Navisworks Connector (still nearing alpha) - It is a world of no right answers.
“It is a world of no right answers.” - yes I know your pain there. And apologies, if as a newbie I am not up to speed, I have searched a bit for similar topics.
It may be that I have a measured survey related bias here, and I’ll note that I have no experience of Rhino or Civil3D and how they work, but better experience of Revit, AutoCAD and Microstation. In practical terms I am talking about the near project start process of deciding and documenting the reference points for applications that need modelling to be in a local high accuracy coordinate system which references a global one.
I think its much simpler is a building context, because generally scale factor and projection errors can be ignored in a way that it simply can’t for big linear infra.
My suggestion is that if the knowledge of each applications behvious sits inside speckle then in platform may be a better place to administer the management and distribution to outside the applications themselves. The reason I speculate about this is that people often know the application they are using well, but not
In the same way that speckle has a wall in its object model that references applications walls, a location reference, which could be characterised as a survey station could be a starting point and prompt with what the extent of say Revit or Rhinos solids modelling area.
ps. don’t get me started on feature coded data from survey packages. So much valuable information in them that gets flattened and lost in DWGs!
This makes sense. Implementation of something like this, or addressing it, is an ongoing discussion and something that can in theory be supported - adding your context is helpful. Thanks.
I know you very well, but please feel free to introduce yourself. Having a broad range of domain experience is spectacularly useful to the Community and us.
Hello,
It would be very helpful to have the option to disable the prefix “stream[ branch @ commit id ]” being added to Layer Names and Block Names when receiving to Civil3D. Many clients have strict naming conventions, and while the layers and blocks can be renamed. Currently each layer and block would have to be renamed after each commit.
Another behaviour, that for me doesn’t match with for typical drawing productions, is objects (lines, curves, meshes, etc) are being received with their properties like Color and Linetype set to specific values (e.g. colour 0,0,0 or Continuous) inherited from their layers as opposed to being set to “ByLayer” as they were in originating software (Rhino in my case).
Hiya @KateM , thanks for the feedback!
With the latest release 2.11, the prefix shouldn’t be added for layer or block names when receiving in update mode - I can see that this could be useful option for create mode as well though, so we can consider adding the option as a setting.
Another behaviour, that for me doesn’t match with for typical drawing productions, is objects (lines, curves, meshes, etc) are being received with their properties like Color and Linetype set to specific values (e.g. colour 0,0,0 or Continuous) inherited from their layers as opposed to being set to “ByLayer” as they were in originating software (Rhino in my case).
This behavior will definitely be implemented when we add better Layer
support and start sending layers with materials and display styles attached - we’ll make sure to update object display inheritance when we get around to that