Objects and geometry

When sending objects back and forth from/to eg Revit, is it so that you always sent geometry with the object? As in, an Object is always geometry with meta data?

Like for example when I would construct a stairs object to be sent from Speckle to Revit, can I only sent the stairs parameters like height, number of risers, etc so that Revit will generate the geometry based on that information? Or do I have to provide the geometry?

Hey @promontis welcome to the forum, feel free to Introduce yourself 🙆 if you’d like.

This is a very good question, and we should definitely clarify these bits in our docs as well, so thanks for asking.

I think the best way of explaining this is with an example of our main flows.

When sending from BIM software (eg Revit), Speckle attaches all geometry and metadata available.

When sending from non-BIM software (eg Rhino) Speckle gives you the possibility to “tag” geometric elements so that when received in BIM software native elements can be generated (eg walls, floors…).
This is currently done by attaching a so called “SpeckleSchema” that includes information on stuff like family, height etc.

See this conversation for more details on some proposed changes to this behavior:

Let us know if you have any more questions!

Ah thnx @teocomi!

I think I need to rephrase my question a bit…

When talking about the Objects Kit, I’ve read that the object model is split into two main parts:

  • Geometry: the basic building blocks such as points, lines, meshes, surfaces, etc
  • BuiltElements: higher level elements such as rooms, beams, ducts, openings, topography, etc

The question is more of how these two relate.

For example, looking at the convert for the RevitBeam class:

private RevitBeam BeamToSpeckle(DB.FamilyInstance revitBeam)
{
  var baseGeometry = LocationToSpeckle(revitBeam);
  var baseLine = baseGeometry as ICurve;
  if (baseLine == null)
  {
    throw new Exception("Only line based Beams are currently supported.");
  }

  var speckleBeam = new RevitBeam();
  speckleBeam.type = Doc.GetElement(revitBeam.GetTypeId()).Name;
  speckleBeam.baseLine = baseLine;
  speckleBeam.level = ConvertAndCacheLevel(revitBeam, BuiltInParameter.INSTANCE_REFERENCE_LEVEL_PARAM);
  speckleBeam["@displayMesh"] = GetElementMesh(revitBeam);

  GetAllRevitParamsAndIds(speckleBeam, revitBeam);

  return speckleBeam;
}

I can see a BuiltElement, namely the speckleBeam of type RevitBeam. It has a property displayMesh which is a mesh, right? So that’s geometry.

AFAIK, Revit generates the geometry based on the BuiltElement. Like they have an engine where you can input a BuiltElement (I think they call it a Family, but I’m new to this) and they generate the geometry.

As you said, Speckle can transfer both BuiltElement and Geometry to a stream. What would happen if I edit the BuiltElement data and not the Geometry, and send it back to Revit? Would Revit generate new geometry for it, or is this not how it work? And what happens when I do sent geometry (that could come from a different BIM editor) to Revit, and edit the BuiltElement data in Revit. It now has received geometry, and needs to update it… will it just override the geometry?

Also you guys have created a more stable Beam that is the base class for RevitBeam (which is awesome BTW and for more clean than IFC). What happens if I instantiate a new Beam and sent it to Revit, without any geometry attached?

4 Likes

Gotcha :slight_smile:

Yes, you’re perfectly right about the Geometry and BuiltElements types.
All BuiltElements we have defined so far have:

  • one or more data properties
  • one or more base geometries
  • one display mesh

Beam Example.

The data properties such as height, family name, units, parameters are just metadata on the element. Most of these contribute to the object creation/update but not all, it really depends on the specific software API method.

The base geometries are usually 1d/2d elements that define how that element should be created. Walls, beams etc have a baseLine, family instances have a basePoint, floors have outline and voids, DirectShapes have baseGeometries and so on.

The display mesh is a 3d mesh representing the object. It is used in the viewer, Unity/Unreal etc.

When converting BuiltElements back to native inside a BIM software like Revit, our converters use both the required base geometries and data properties to create/update the element:

This means that if you were to edit the baseLine of a beam prior to receiving it in Revit you would get the updated beam. Same would happen if you edited its units or parameters. Nothing instead would happen if you were to edit its displayMesh instead as that’s not used by the conversion.

In general, I would discourage editing geometries and parameters outside native authoring software as this could result in misalignment between the display mesh and other element parameters (eg the base line and mesh could not match, or the element height and mesh height). If you edit geometry or parameters inside or Revit instead, you always get fresh and “safe to use” BuiltElements when sending out.

We have created a specific class to help updating parameters only, the ParameterUpdater. Otherwise attaching a SpeckleSchema as GrasshopperBIM and RhinoBIM do, might be a better approach.

Hope this makes sense!
Did you have any specific workflow or use in mind? If you tell us a bit more we might be able to give you additional insights :slight_smile:

P.S.
It’s on our long list of TODOs to outline more clearly which properties of our Objects are required when creating these elements in Revit etc…

3 Likes

Ah thnx for the great follow-up!

You kinda lost me at…

We have created a specific class to help updating parameters only, the ParameterUpdater . Otherwise attaching a SpeckleSchema as GrasshopperBIM and RhinoBIM do, might be a better approach.

To what parameters are you referring? Like in the context of data properties, base geometries and display mesh.

Did you have any specific workflow or use in mind? If you tell us a bit more we might be able to give you additional insights :slight_smile:

I’m creating a web based BIM editor, without all the difficulties of BIM. The Object kit is wonderful for me because it defines a stable BIM structure for me to depend on. I first tried IFC, but that is way too complicated.

The editor will be creating streams using a superset of the Object kit. It will also generate geometry (so a display mesh) based on that superset.

I would like to sent the streams to Unity and Unreal, so the support for that is awesome!

I would also like to have a two-way sync for the superset and Revit, for which I probably need to create a custom family in Revit, and extend the plugins. On that notion: are you open to add a plugin feature to the Speckle converters? Like, I would like to extend a Speckle converter for the superset, but it would be nice if I don’t have to touch the Speckle converter itself. I’m thinking that a Speckle converter could scan assemblies and have a ‘pipeline’ of converters, so that I can add converters (or converter steps) to the already existing converter.

The last thing I would like to do is to generate the same geometry as Revit is generating, based on the Object kit (or supersets of it). So basically, when I sent the stream to Revit and look at the Revit-generated geometry, it should be the same as that of my own geometry generator. That would probably be the hardest thing to do.

2 Likes

Hehe sorry :sweat_smile: !
What you are doing sounds very interesting, we should definitely discuss this over a quick call in the next days, what you think? Maybe after Community Standup🌟 ?

In the meantime, some short replies.

The parameter updates we specifically designed to update Revit element parameters without having to send back the entire Revit element. See Excel | Speckle Docs.

Ugh, interesting! This is the first time this comes up, and we could explore solutions together.

Well this could be quite tricky for some Revit categories, eg furniture and equipment. Speckle doesn’t store any geometric information about these families except for base point and family & type name.