Serving GLB files - Technoculture/VVplus GitHub Wiki
- 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 thevvplus.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. Turns outbrotli
as it provides up to 10x compression factor, which might lead to very snappy load times despite bigglb
assetsbrotli
for compression ofgltf/glb
or other mesh formats has associated issues. Perhaps it may be better to useglb
files along withgzip
compression. [TODO]
- Rationale: It allows our backend data team to simply upload
-
glb
: Useglb
files instead ofgltf
files-
Rationale:
gltf
files are json files, whereasglb
(bianry) files are binary files, this meansglb
files tend to be smaller in size
-
Rationale:
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 toglb
assets or bulkywebgl
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 |