@EtagiBI typically the RAM available to your CPU is a relatively small aspect of a WebGL scene’s performance. Mostly you’ll use that memory while loading the model, and yes — glTF is designed to be very efficient to load. The mesh data is already in a binary buffer that can be uploaded directly to the GPU without copying it anywhere. The implementation of THREE.GLTFLoader is not entirely “in place”, but should still be pretty good. Compare that to text-based formats like OBJ, where every character in the file needs to be parsed and converted to an array.
Beyond memory usage, a few other things to keep in mind:
- Draw calls are costly. With any format you use, try to merge meshes and materials before export.
- Mesh compression (see glTF’s Draco extension) can reduce the download size of your model.
- Quantized attributes can reduce both download size and GPU memory usage. See https://cesium.com/blog/2016/08/08/cesium-web3d-quantized-attributes/ (although that post is a bit out of date).
- Texture compression can dramatically reduce the amount of GPU memory needed for textures, and frames dropped when uploading them. A glTF extension for cross-platform compressed textures is in progress but incomplete.
- More advanced techniques (LODs, impostors, …) can be used regardless of your file format.
glTF is not the only format designed with performance optimizations, but IMO it is the first to get really widespread support. An advantage of this is that there are beginning to be more tools, like Compressonator and glTF-Pipeline, providing convenient ways to optimize a model. Other common formats like OBJ, FBX, and COLLADA are designed for interchange between tools and do not focus on performance much. The new USDZ format may also perform well, but (1) details are limited at this point, and (2) it’s dependent on a very large client library, so not currently a good choice for use with WebGL.