Connectors 3.5 Release - June Changelog

Hey @Community !
We’ve hit another milestone release 3.5.0 for connectors :scream:
Here’s the full rundown of everything that’s changed since the end of May.

June Changelog

General

More of a reminder, but please refer to our documentation if you have any FAQs or troubleshooting issues for any connectors. This is a living document, and will be updated with new information or questions as they pop up in the forum.

Revit

  • Level properties (including parameters) are now published with every model. View them in your browser in Dev mode on the scene explorer:

  • You can now properly load a model according to Project Base point and Survey point with our new load setting. Use this for reference point coordination when loading models from IFC, Civil 3D, Navisworks, and more!

SketchUp

  • Revit Levels are now created as Section Planes when you load a Revit model in SketchUp.

Rhino

  • The Speckle toolbar now loads correctly in Rhino 7

Grasshopper (beta)

  • Grasshopper is now in Beta, and comes with a bunch of highly requested features including creating properties by key and value, and blocks support! Read about all the new features here.

blocks

Blender

  • Blender is officially stable! If you missed the announcement, check it out here

Archicad

  • Composite elements are now published with all of their composite parts and properties!

Navisworks

  • You can now publish models according to a saved view, using the new Saved Views Filter. Only visible objects in the selected view will be published.

Civil 3D

  • Solids and blocks are no longer missing their property sets when published
7 Likes

Hi @clrkng, with regards to the latest Civil 3D connector, does it published the solids as solids and re-import as solids or still polymesh entities?

Hi @Jerome ! Civil 3D solids are still published as meshes currently.

Hi @clrkng,

With the new v3 connectors (Revit 3.5 and Archicad 3.0.2), it seems like you’ve dropped the concept of supporting native (smart) elements, as was the case with the v2 connectors.
Is that correct?
Are objects from both Revit and Archicad now published only as meshes?

Thanks,
Matthias

Yes, our current connectors do not support native element creation at this point. We’re planning on enabling family assignments to generic models loaded in Revit, and perhaps an instance-mapping workflow from blocks to existing Revit families, but do not have any plans to create fully native elements yet.

This really feels like taking steps backward. This is not different them Importing IFC file inside of Revit like we used to do 8 years ago. The BIM objects in the speckle 2 where greatfor sending data from your parametric model to you BIM or Structural analysis model for documentation in the form of native elements which you could later change manually if needed in the design process. You need to change them manually because you don’t want to go back to you parametric model for each tiny change.

Hi Joël - re your constructive point around parametric model to revit workflow. This is definitively one that shows up a lot, so it is a candidate for bringing it back.

Can you tell us a bit more about how you’re using that v2 workflow? Specifically, what we’re interested in is:

  • frequency (daily, weekely, early design project stages then not, etc)
  • multiplayer (you generate the model, and some else receives it) or singleplayer (you on your own computer, rhino and revit open)
  • what pain point does that workflow in speckle solve vs. for example RiR?

Dim

  • frequency Twice a week per project in the firm
  • multiplayer Multiplayer between multiple people (mostly Bim Modeller and Parametric engineer, but also Structural Engineers or Design leads)
  • what pain point does that workflow in speckle solve vs. for example RiR? RIR has a live link with Revit, slowing it down, also there is no way to seperate / update your model in different parts.

I’ll give a bit of detail on how we as a design discipline work for a bigger project we are currently doing.

We are tasked with designing 20+ structures around a highway intersection. the structures vary from retaining walls align alignments, sheet pile walls, foundations for the highway etc.
Designing them means:

  • They have to fit within the space (no clashes) and fit together with other disciplines (we are 1 of 14)
  • They are feasible in term of building them, we are closely working with the team who will build it and they give us the boundary conditions
  • Parts within the design need to fit perfectly onto each other within the structure

Our team has 2 parametric engineers responsible for the parametric models and 2 BIM modellers responsible for the BIM models and documentation for each structure (over 20 of them) and each structure consists of different parts (10+)
With the parametric model we collaborate with the design lead, lead structural engineer, contractor responsible for this structure and we make live changes to the models in design meetings (once a week). We work on 2 structures at ones, so 2 meetings a week per parametric engineer.

We send the data from the parametric model in seperate models. Each different part within the structure is a seperate model.

SO. why do we work this way and how Speckle 2 worked for us and Speckle 3 will not:

When working on 4 structures simultaneously at all times and a structure if broken down in aprox 10 seperate models and at the end of each week we update the models from Grasshopper which have big changes. Some changes have effect on all 40 models, but some only impact only 1 or 2 parts. We break the structures down in parts so we can update specific parts in Revit as we feel the need to implement the changes. We don’t want to update the whole model when only 1 part has changes. That will take a long time.

We do not use Rhino inside to make these parametric models because Rhino inside has a direct connection to Revit which is not directly used when you are still fitting the design, Revit only slows you down. Speckle if the “storage” which makes this process really fast. We can make live changes in meetings whithout the whole BIM model updating every time…

Speckle 2 gives use the ability to use Revit native objects. The 2 BIM modellers are building parametric Families for the model and instruct the Parametric engineers how they want to receive the data in the families. Making this families parametric means they can make minor changes by hand in a later stage if need be. Also we can make different Category families for different parts. Nobody is going to model a Column or a Beam as a Generic Model. You model them as Beams and Columns and you are able to read data on these objects.

This last point is really important because our philosophy is that everything you send using speckle should end up as much native as possible, so that if the parametric model dies or Speckle stops or we get less tech savy engineers or any other reason we need to be able to make changes by hand. At some point in the project (Right before producing Final design documentation) we stop using the parametric model unless we have major changes and we switch to RIR scripts for bulk editing. Also when we send an update of a part we want to Update the elements in Revit instead of deleting the old and creating new. Otherwise we lose manually added data and annotations on drawings or documents. This was something speckle always tried to do.

We do not use Speckle for Viewing / Clashing / Reviewing models, because there are already platforms which do this in a better ways like ACC or Trimble Connect or Revizto. We use Speckle to Exchange Design data between Software applications and it enables us to use the best tool for the job instead of working with the same tool for everything because softwares cannot change native data.

Sorry for the long post, but I hope this gives you a good view of how Speckle 2 improved our jobs and Speckle 3 will not.

FYI @Wes

6 Likes

Wow - thanks for the super detailed reply - i was not expecting so much, we’re really grateful! I’m not sorry at all for your long post :slight_smile:

When embarking on 3.x we’ve put 2.x side-by-side compat as a prime requirement, so first off: you can keep doing what you’re doing with 2.x.

We’ve also on purpose restricted the scope of 3.x, so that we can (re)validate high cost (to us, in maintenance/dev effort and low frequency/low user count) workflows from 2.x with a fresh eye; the “speckle 3 will not help” is not true, we’re just revalidating from first principles and will build back core functionality that makes the cut.

We’ve got that fresh perspective from you just now (people in AEC share less than we’d want to). I think you’ve just given us the perfect requirements spec for the Grasshopper → Revit workflow. I really appreciate how you’ve highlighted to us the vs. RiR benefits - we can loose track often of the detailed picture.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.