Building with integrated meshes

[GuyHeathcote]

Hi,

This is question that I'd like to know the answer to, but am not currently in the position to try out in practice.  In my experiments with the Unity SDK so far, I've been using an integrated mesh that was created within our organisation.  Unfortunately, it's a huge file (>160 Gb) that's too big to fit into my laptop's remaining storage right now.  As such, I've been been accessing it directly from a common (internal) network drive.  That's worked fine (albeit somewhat slowly, which isn't really a surprise to me), behaving exactly as I'd expect it to.

However, what I can't try right now (obviously...) is building this into an output application.  Thus, I'm now wondering if this is something that's actually workable?  I'm assuming, if I was on a different machine (or had a smaller mesh) that I'd actually first need to import the mesh into my Unity assets, then reference it, from there within the code/UI?  And then, at build time, the mesh would be included, in its entirety, within the build?  Is that how it would work?  If that was the case, is there a practical limit on how big that mesh could be?

I'm used to dealing with regular Unity assets, but have never ever considered packaging something of that size into a build before, so am feeling somewhat cautious about suggesting, to anyone else, that this is something that could be done.  Any thoughts?  

I understand that, as an alternative, the mesh could be hosted externally and referenced from there.  However, this might not be an acceptable option for some organisations.

Regards

Guy Heathcote

[Matt_Nelson · Accepted solution]

I would recommend either of these things.
1. Host the .slpk as a SceneServer on ArcGIS Enterprise or ArcGIS Online. 

2. Look into a solution where you build the application share it but a part of the application will actually go out and download the file and update the file path for the scene layer locally.

I don't think you will have much luck shipping that asset in a build.

[GuyHeathcote]

Thank you, Matt.  I can see that serving it would generally be the most obvious and efficient option.  However, as there are reasons why this might not be appropriate for some users, I was interested to know if there were other options.  It does seem that your second suggestion might be OK for such users...I'll suggest that to them, rather than think about an all-in-one build.  Many thanks.

[Matt_Nelson]

The only downside to serving the data online is that users with high latency or poor internet connections will have a bad experience when running the application.

However, those same users find it annoying to download 100+GB of data to their machine if their internet doesn't work well.