I spent some time testing out the latest Speckle - Unity connector. The receiver on Unity side works smooth and fast, with smaller projects (~250 objects / total children count), but with medium/big projects (over 11500 objects) it says Receiving and the little progress bar is stuck at about 10% progress for around 15 minutes. (after 15 mins I stopped the process)
Now my question is, what could we do about this, and is there any work around for this issue? Right now even on the Speckle.xyz server’s web viewer this medium project takes more then 5 minutes to load, but at least it loads.
One thing I recognized is that on the Speckle web viewer, the streaming is done gradually, meaning that it loads and shows objects one by one, while in the Unity it looks like a buffering time and then the models just pops up.
Ouch! 15 mins is clearly unacceptable . There’s a few things that could be going on, and first of all we should narrow it down and see if the problem is the download or the conversion.
Are you able to put some breakpoints around this line?
I’m not very experienced with unity, but I noticed some weird and unjustifiable performance issues when dealing with its API. For instance see these lines, I’m assuming you’re facing something similar and that it’s not really an issue with the streaming itself
If you could also share the stream with me I’d be happy to investigate further next week!
I tried to put some breakpoints around the line you suggested (line 148 at Receiver.cs) but I’m not able to reach that breakpoint which I put right before that line, in 15mins, so I guess it’s stuck at the beginning of the downloading probably?
I see the lines you are talking about, regarding the triangles, but I’m not sure how’s that speeding up any processes… It’s indeed interesting
We started looking into this and have some preliminary findings (thanks dim & cristi):
the model is actually huge ~800mb of data
it seems some geometry in the model is extremely heavy, in particular, some chairs having ~300k vertices each!
the Unity connector is much slower at receiving the model compared to other connectors (weird as they use the same code)
I’m still looking into (3), in the meantime, I’d suggest trying to replace/simplify those chairs or at least exclude them from the stream. It should make everything much faster!
@pablothedolphin are you still around these parts? If so would really like to bump heads regarding this slowness issue, I just tried again and exactly the same code takes 25min in unity and 3min in Rhino…
This slowness is actually a result of the huge overhead involved in creating new instances of objects in Unity. This issue exists in any game engine and is beyond just rendering. This issue is made worse by the fact that Unity’s runtime aims to run at 60fps. Writing async code that plays nice with a game engine’s framerate is the challenge we’re dealing with here.
The solution would be to create the received objects between each batch that’s been downloaded then call await Task.Yield (); to yield to the next frame. From there, you can tweak how many objects you want to request per batch to get the best result.
The slowness we’re experiencing happens before objects are converted and instantiated in Unity, it happens purely when data is being retrieved from the server.
swinging by to drop a random thought! @teocomi I’m wondering what the performance difference would be like when using the unity connector in a standalone build… maybe there is some sort of bottleneck during speckle downloads that is being created by unity’s call stack. I’ll do a quick test on this later today with the profiler
I checked the profile during a stream download during play + edit mode and it seems like the “editor-loop” is taking up a lot of space but it’s hard to read the profiler stats when we are calling re-paint a bunch of times on the stream manager. I’ll take a pass at breaking down the stream manager functionality, my guess is the editor functionality we have right now is causing a lot of lag.
@cristi has made some big performance improvements to (de)serilisation performance, I’ve just updated the Unity connector with these changes, so please checkout the main branch, you should see a significant speed boost!
I believe Cristi has measured anywhere from a 2-10x speed increase!
I’ve tested the latest build for couple of hours, but unfortunately none of my streams got streamed.
I tried to stream a smaller project (around 241 objects) but the outcome was this:
Receiving stuck at this point, without any errors:
Is it possible for you to invite me to a stream that’s failing?
Could you also tell me which program you are sending geometry from? and what version of that connector you are using.
I’ve done some testing my end, and I can only reproduce your issue with stream send from an old version of the Revit connector.
If this issue is reproduceable with the any latest versions of a connector then that’s concerning!