Reloading Assemblies takes too long

Objective: Development, using Speckle for receiving models in Unity.

Issue: Constant Editor freezes.

Details: Saving changes in scripts, adding new objects, changing prefabs, triggers a assembly reload in unity starting a process that takes anything from 5 minutes to sometimes 15 minutes to end. The same problem does not exist in other unity project (of the same editor version). The Project I am using now is a clone of the Speckle playground pulled from speckle - unity github, and the changes I currently made are,

  1. Adding the FBX Exporter plugin from Unity Package Manager’s Plugin Registry.
  2. Pull model from speckle stream in the Unity Editor itself.
  3. Write a script to traverse objects in the model and store the data from dictionary to a separate dictionary and then write all that data to one json file.

Also to mention, the cpu and memory usage sky rockets during this. The machine is a lenovo ideapad gaming laptop with an i5 - 10300H and 16 gb 2933 mhz Ram. Which I hope should be sufficient?

After I export the model to fbx, move it to a different project (same editor version but without speckle) and then continue development there, this issue does not occur. (Domain reloads are over within a few seconds, in comparison barely noticeable)

However then I lose the speckle properties data, and this feels sufficient only as a temp workaround. In the long run the project would use speckle to send the model data back with changes made during runtime.

This is the message it is showing after around 8 minutes of waiting.
It starts with the “Reloading Assemblies” Message, proceeds later to "Waiting for Unity to finish executing.

Speckle stream: Speckle

Hi @TanmayKc, We are aware of slow downs experienced when reloading scenes with lots of Speckle objects.

After some investigation, we have identified the cause of these re-load slow downs. When receiving Speckle Objects, we attach non-converted properties to each game object under the SpeckleProperties component.
When receiving lots of objects, or objects that are particularly heavy with additional properties (as is common with Revit objects) This adds up to a lot of data to hold in memory, and to serialize/deserailzie to/from disk.

We have a couple performance improvements in the works for next release (2.16) that speeds up our deserializer a fair bit.

But we are still exploring some other options on the Unity side to more efficiently store these properties.

If you don’t need to access these custom properties, and just want the geometry, then I’ve exposed a toggle to disable attaching of properties.
You should see significant speed improvements this way, as this avoids having to serialize any SpeckleProperties.

We would welcome feedback and any suggestions on ways we could make our connector better.


Thanks @Jedd

Yes, we have a lot of objects with a lot of properties and that part won’t be in our control.
But we would really need to use certain properties, if not all of them. So far as a work around, I used a script to save all data relevant to us, in a Json file and used that file during runtime, in a different project, to continue development without the (in-editor) reload slow downs.

It would be really useful if we had a way to send a request to the speckle stream to get only the properties we need. Eg: If we had a specific wall and knew it’s object id, and previously chose not to attach speckle properties, we can do something like SpeckleReceiver.GetPropertiesFor(ObjectId, commitId).
Is there already a way to do something like this?

This is possible using our SDK in a number of ways.

I have added an example here:
that uses a co-routine function to receive the object by id and handle the properties by attaching a SpeckleProperties component.

You’ll likely need to adapt it to meet your needs, but hopefully demonstrates how you can grab properties “on-the-fly”

To use it, you’ll also want to update to the latest version (2.15.3), since I’ve made a couple functions public that were previously private that should help when manually attaching properties.

Any questions feel free to ask!

1 Like

Hi @Jedd, How can I find the id that you mentioned??

Hmmm, how would you like to be able to access it?

I have a feeling there isn’t a nice way currently to simply grab the id of the object after it’s been received.

I’m thinking we might need to re-scope some of the ways we attach properties on the converted Unity objects. So input any input is highly appreciated.

We will be pulling data using Unity and Python connectors. We are using Python to perform some calculations and Unity for visualizing the 3D models. Based on the calculations obtained from Python the specific 3D objects will be manipulated and displayed in Unity.

To perform these operations programmatically we need some id that is unique and available in both Python and Unity. We noticed that the RevitInstance id (as seen in the speckle web viewer, image below) is unique and available via the Python connector, but that same id is not available in the Unity connector.


It 100% should be. Perhaps it relates to how the object tree is being traversed?

@Jedd is the best person to give insight to me on this. Is traversal doing something different for instances in unity? If it is using dotnet sdk then I’m unclear why it would be.

There are some Unity connector specific things that make it quite difficult to get the Id of objects after they have been converted to native Unity ones.

Of course Operations.Recieve gives the ids. but there is then no nice way to map that back to the converted objects.

From what we’ve discussed. It sounds like, re-writing the way the SpeckleProperties component works, to make it easy to grab the Id of the object that was previously received would allow @TanmayKc to have full access to the custom properties, and have far less costly data to serialise to each object.

I’ll scope out an issue for this.

1 Like