• CDN: Use a content delivery network for edge caching of the files
  • Rationale: We have very few files, a few of these asset files are likely to be used in every render (structure, plot assets, etc.). This means caching some of these frequently used files will benefit performance - especially given most of our requests are likely to originate from particular geographical areas (North India).
  • CDN also allows us to serve requests using HTTP/2 and HTTP/3 (Speed)
  • CDN also allows us to serve files with a compression header so that compressed files are transferred over the internet and decompressed on the user's browser. Given the glb assets tend to be big, this seems like a reasonable addition. [TODO]
• DNS: Use of a subdomain (assets) on the vvplus.cc domain
  • Rationale: This is just so that changes to the underlying server architecture do not need to be updated to the codebase again and again
• S3: It's an object storage, readily available AWS service
• Lambda: To compress files uploaded onto the S3 bucket
  • Rationale: It allows our backend data team to simply upload glb files instead of worrying about the compression system being used (gzip, brotli, etc)
  • Ideally, we will use brotli as it provides up to 10x compression factor, which might lead to very snappy load times despite big glb assets. Turns out brotli for compression of gltf/glb or other mesh formats has associated issues. Perhaps it may be better to use glb files along with gzip compression. [TODO]
• glb: Use glb files instead of gltf files
  • Rationale: gltf files are json files, whereas glb(bianry) files are binary files, this means glb files tend to be smaller in size

While this approach is more so based on some common practices not related to glb files in particular, here is a reference blog article that indicated that the method is relevant to glb assets or bulky webgl sites in general

file	gltf	glb	gzip glb	Compression Factor
plot	61.7 KB	47.4 KB	43 KB	69.7%
groundfloor	560.4 KB	435.1 KB	60 KB	10.7%
firstfloor	554.2 KB	429.5 KB	61 KB	11.0%
secondfloor	554.2 KB	429.5 KB	60 KB	10.8%
roof	79.1 KB	60.3 KB	53 KB	67.0%

🚨 Faced errors, issues using gzipped files with babylon's built in importers.

Found an issue discussion on BabylonJS forum regarding the slow rendering of huge .glb files and how it can be fixed. This link leads to the forum. The major takeaway from this discussion was the advantage of using compression tools specifically built for .glb files such as Draco,gltfpack or Rapid Compact.

• The number of triangles and texture sizes might slow down the loading of files by a long shot. Minimising this number will help a lot.
• Secondly, gzip only works on text files I think, but multiple layers of compression tend to not improve things much unless they achieve their results a different way. This leads to problem of non-applicability of general purpose compression engines for mesh files.

• Draco
• Gltf-pipeline

  Draco Compression

  gltf-pipeline -d -i firstfloor.gltf -o ff.glb

  -d is to choose draco compression

file	gltf	draco compressed glb
firstfloor	556 KB	84 KB
structure	3.3 MB	340 KB

• MeshOptimizer -> gltfpack CLI
• gltf-Transfrom -> CLI