ARVRToolkit
ARVRToolkit copied to clipboard
wallabyway
The loading performance is low comparing to WebGL client
We found that the time cost of loading a model in Unity (dynamic or static) is much more slower than loading in WebGL client. e.g. For a 2M model, the loading costs about 7 minutes (while in WebGL it's in seconds), which is a bit unacceptable. What is the reason of such difference? What kind of optimization can be done in the model to make it faster? Is it possible to make it faster?
The slowness is due to 1 http request per mesh file.
This will change when we add zip containing many mesh files. Look for the change to this code here: https://github.com/wallabyway/ARVRToolkit/blob/c31c535bd85060ed21011bd6cf62ebd0a3d83760/unity-src/ARVRToolkit/Assets/Forge/ARKit/MeshRequest.cs#L54-L83
Thanks a lot for the hint. What do you mean by 'adding zip containing many mesh files'? The model file is in IFC format. Does that mean we somehow compress the IFC file before uploading to Forge?
(The goal is the achieve same performance as loading from WebGL client. Is that possible?)
Zipping files means compression. No correlation with IFC. Best to look at forge website to understand cloud translation and how this fits in with IFC file types.
Thanks for the answer, but one question, if I understood correctly, by term 'translation', that means the conversion to SVF format from IFC format (is that right?). Why is the performance so different when loading the same model with WebGL client? It is the same model and it had the same conversion. You mentioned that the reason why it is slow is that it sends '1 http request per mesh file'(with AR/VR toolkit), then what is the difference in WebGL client?
Correct, translation is the conversion from a file format to SVF. The difference is that the Forge viewer pipeline is optimized, resources are being zipped and streamed to the client web page, then unzipped and aggregated by the JS code vs the toolkit is still in beta, so loading meshes requires one http call per mesh, hence greatly increasing the loading time for models containing large number of components.
@leefsmp Huge Thanks for the hint above! Can I confirm in detail: is it so that the zipping happens in Forge cloud (already), which means it is available for all the clients including WebGL client and other clients including AR/VR toolkit. The only issue now is that the current beta version of AR/VR toolkit doesn't support to retrieve the zipped one(stream it) and unzip it in client side. Is that what happened?
If that is true, at this stage, is there any recommended method to optimized the loading performance? Such as that would it be better to load IFCZIP instead of IFC? Please comments. Thanks.
Another question is that is it in the plan to optimize it to the same level of Forge viewer(WebGL)? We need to know this because we are planning to implement other alternative solution to optimized the loading performance, such as loading Unity prefabs from our own server instead of Forge cloud.
Please comments, Thanks.
The zip has to be created on the server, so in that case the AR Toolkit service, this is what this issue is about. It will be implemented soon but not yet available. At this point there is no optimization you can do on your side to speed up loading time, uploading a zip will not change anything when the translated meshes are being downloaded by the client. You need to understand that the viewer service and the AR toolkit are two different services, the toolkit is using the SVF data initially produced by the viewing service but generates its own set of data.
Thank you @leefsmp !
I draw my understanding (from your comments) in the picture as attached. Please confirm if it's correct or not.
yes it's close to the reality, the svf is actually a set of zipped resources, then it's processed by the AR toolkit to create a new set of unzipped resources (which will be zipped later) and served by the AR service. You can find a Forge diagram there, it does NOT include the AR Toolkit. Simpler diagrams are available on the AR Toolkit documentation website.
Thank you @leefsmp for the explanation and the diagrams!
As you mentioned, SVF is already a set of zipped resources, do I understood correctly that the AR toolki sends request to unzip it in the server side, and the unzipped content is served by AR service, then AR toolkit retrieve the unzipped content. Why does it have to unzip it?
Actually, downloading the SVF file doesn't require a lot time(just a few seconds), theoretically it's possible to download the SVF file and parse it in the client side by AR toolkit unity plugin. Why does it need to send request for every mesh? (just curious for the reason of the design, no complain).
Besides, may I ask the rough schedule of the new version of AR toolkit which supports zipping/streaming? We just need the very rough information(1 year? half year?, it doen t have to be accurate) to plan our project. For example, we need to consider if it make sense for us to work on alternative solution, such as setting up our own server for downloading models (which are Unity prefabs).
Please comments, Thanks.