I loved three.js in the process and I’m also amazed by what’s possible within the browser. Also the advantage to reach a broad range of devices with a single codebase is amazing. Nevertheless, WebGL2 features are not broadly supported and there are limitations in what a (mobile) browser can handle. E.g., if the load on a browser tab on iOS gets too hight, it’s just being shut down.
The codebase was recently converted to TypeScript. And it is relatively big, albeit not huge. What are the best modern strategies to build a native app from a Three.js PWA? I fear that just putting it into a web view and adding native controls on top won’t solve memory constraints/sudden crashes?
The optimal solution would be the web-based codebase and a transpiler that creates native 3D/Metal/etc. code out of it. I know, that’s much to ask for.
You can absolutely just use your web app as a mobile app, 100%. Slow web performance is a good indicator that your overall solution hasn’t been optimized, so that’s where you need to go next.
Looking at your example it really struggles in chrome on my desktop machine.
So comparing what you have to say, 3D buildings in Google Maps, what’s the difference - without blaming javascript or the web, why is it slow and resource hungry. Can it be fixed and how/why? Not, let’s just port it to C++ because that’s faster! That’s optimism, not optimization.
You need to do it adapt to your constraints, so for instance memory usage isn’t going to go away for a fully native solution, so you need to use less memory, load simpler models, re-use model instances etc. If you load 17 MB of model data, you use (at least) 17MB of memory regardless of what tech is loading. If you are decompressing models after you load them then you’ll use much more memory.
Typescript is not going to make any difference to your memory footprint, it gets compiled/transpiled back to JS anyway.
Thank you, Christopher, for your feedback. You brought up valid points!
While this is not answering my initial question, I definitely agree that the app will benefit from further optimization.
Google Maps has no elevation data/3D terrain and Google Earth is based on point cloud data that can benefits differently from overall LoD algorithms – my app couldn’t do without major data source changes. But yeah: Both are obviously on another level in many regards.
Just to make this last sentence clear: You’re not suggesting that there’s a way of rendering compressed models without decompression, right? If not: how?
I also agree, a LoD approach on the building models (calculating lower LoD’s offline) is a very reasonable strategy and will probably come.
Just to be sure: My original post was not only about performance etc., but also about features. I can’t have 3D textures, e.g., in WebGL, only in WebGL 2. The bad debugging of overloaded browser tabs is also a bummer, etc. So it is not only about exploiting fewer hardware constraints on native platforms but also about feature utilization.