A "wrapper kit" and some requests

Hi there,

I’m currently in the process of migrating an application build on Speckle V1 to V2 and all is going well I’ve already seen large performance increases when sending/receiving objects, great work!

Just like in version 1 I am still able to create a custom kit with minimal effort by using the Speckle V2 Objects Kit and specifically the Revit converter by wrapping it in my own Revit converter class. This allows me to reuse the conversion code you guys have created for most of the Objects in Revit but also add some custom objects that I need for my very specific application for instance a Door:

public class Door: Objects.BuiltElements.Revit.FamilyInstance
    public Room From { get; set; }

    public Room To { get; set; }
 … and more specific properties not available on FamilyInstance

And inside my custom converter I’m using the Speckle Revit converter to do the heavy lifting:

    public Door ConvertToDoor(DB.FamilyInstance revitFamilyInstance)
        var familyInstance = _revitConverter.FamilyInstanceToSpeckle(revitFamilyInstance);
       var door = AutoMapper.Map<Door>(familyInstance);
        door.To = GetToRoom(revitFamilyInstance);
        door.From = GetFromRoom(revitFamilyInstance);

I thought I’d share this approach with the community as it is enabling me to work around almost any issue I have with the implementation details of the Speckle Revit converter.

I do have some requests/minor issues that I ran into and was hoping that you could help me.

  • when exporting parameters from Revit, parameters with no value are not exported. But for my application that is a problem. This way there is no way to tell the difference between an empty value and the parameter not existing in Revit at all. I would like to throw an error telling the user he should add the parameter to the object in Revit so that my application can set its’ value and I don’t want to automatically create the Revit Parameter for the user. The application allows the user to configure the parameter names they are using in their specific Revit project.

  • the conversion code for a Speckle Room to Revit is not yet finished, which is completely understandable, but I need it :blush: (recreating an existing Room in Revit is causing warnings in Revit about regions not being set).

  • depending on if you think the wrapper kit is a good idea, it would be really helpful for me and maybe others if you could make the following methods public or move them to a separate utility class: GetAllRevitParamsAndIds ScaleToNative, ScaleToSpeckle so I can use them for my custom objects and I don’t have to copy the code over to my own library.



Hi Fredi!

Nice, would love to see that app featured in our Showcase - Speckle Community category at some point :star_struck:!

Wrapping or better extending our Objects Kit is definitely the best way to go if you want to add custom intelligence to our classes.
Here below some answers to your points.

  • parameters: yes, currently null parameters are being skipped (or better, null values are not getting serialized at all). Despite we think relying on nulls is a bad programming practice, we understand there are scenarios in which they are needed (like the one described by you). So we’re currently looking at adding support for them! Cc @dimitrie
  • rooms: when you send rooms to Revit, we don’t currently create any boundaries, so they’ll come in as unplaced rooms, which should work for schedules at least. Would you want the connector to create room bonding lines too? My fear is that it could, at times, bring in a lot of unnecessary geometry…
  • SDK methods: we can certainly do so, tracked it here

Out of curiosity, are you using our SDK by importing it via NuGet, submodule, fork, or any other ways?

Hi Matteo,

thanks for your quick reply.
I’ll have a look at the Showcase category later on (it might take a few weeks before I have time).

  • parameters: I see what you mean in light of the bigger picture. It’s only a minor issue/nice to have for my application. Using the extended Objects Kit I can probably add the empty Parameter for my use case. I think empty parameters where handled the same way in Speckle v1.
  • rooms: No for my application I would only want to update a few Parameters when sending Rooms to Revit (without Speckle recreating the rooms or updating the boundaries)
  • SDK methods: that’s great I really appreciate it.

Add the moment I’m referencing the visual studio projects Core, Objects and ConverterRevit(2020, etc.) cloned from Git to build troubleshoot and debug the Custom Kit directly, but later own when all is working I will use the nuget packages you guys made :+1: so things will integrate nicely in the automated builds I’m using.

I ran into another issue today with Parameters when testing it on a Revit Central Model. In this model there are some Revit FamilyInstances (doors) that are using the same Builtin Parameters: ELEM_PARTITION_PARAM and EDITED_BY in both it’s typed and instance Parameters causing Speckle to throwing a “An item with the same key has already been added.” inside the GetAllRevitParamsAndIds. I think it has something to do with Worksharing in Revit and it is possible I’m doing something wrong, if I know more I will let you know. But if you could built in a safety check when adding the params (typeParams.Where(x => !instParams.ContainsKey(x.Key)) that would be great and enough of a solution for me.


1 Like

Hey Ferdi,

I’ve made those methods public and added a safety check to prevent parameters with the same key to be added. If there’s an instance AND type parameter with the same name/guid, the instance one will prevail. Everythin is in main and will make it to our NuGets at our next release!

Regarding Rooms, can you briefly walk me through your update process? How where they originally crated and how are you sending the updates? This way I can make sure we get that to work!

Thanks for the feedback!

Thank you!,

I’m using the Speckle Revit Converter inside my wrapped converter (just like the fallback below) to convert the Room to a Speckle Room but right now I intercept/redirect the RoomToNative method inside my wrapped converter using the following code

    public object ConvertToNative(Base @object)
        if (@object is Room room)
            return RoomToNative(room); // Custom method see implementation in next code fragement

        .. other redirects...

        return _revitConverter.ConvertToNative(@object); // fallback to Speckle Revit Converter for all other objects my kit doesn't support

to make sure that existing rooms get the changes in the name, number and parameters I applied to them in my application I use the following RoomToNative method:

    public List<ApplicationPlaceholderObject> RoomToNative(Room room)
        var revitRoom = _revitConverter.GetExistingElementByApplicationId(room.applicationId) as DBA.Room;
        if(revitRoom == null)
            return _revitConverter.RoomToNative(room); // create it using the Speckle Revit Converter

        _revitConverter.SetInstanceParameters(revitRoom, room);

        revitRoom.Name = room.name;
        revitRoom.Number = room.number;

        var placeholders = new List<ApplicationPlaceholderObject>()
            new ApplicationPlaceholderObject
                applicationId = revitRoom.UniqueId,
                ApplicationGeneratedId = revitRoom.UniqueId,
                NativeObject = revitRoom

        return placeholders;

in my application the revitRoom above will never be null because I only update existing rooms.


we are implementing spaces and SpaceSeparationLines at the moment (PR coming soon!), and have taken the same approach: updating rather than deleting and re-creating objects.

Deleting and re-creating wreaks havoc with any drawings that have already been created and tagged.

Thanks for the clarification @fmeijer , I’ve just pushed a small fix that does update rooms!
@daviddekoning we’re tackling parts of Feat Revit: Additional conversions · Issue #394 · specklesystems/speckle-sharp · GitHub this sprint, let us know if any coordination is needed before your PR :slight_smile:

Ah, nice @teocomi! @jenessa.man has done most of the work on Spaces already, so if you guys want to hold off on that one, we could save you the work.

Ok, thanks! Will hold off from spaces :slight_smile: