Cache world mesh + static VOB mesh to be calculated only once

[JaXt0r]

Background

Loading world.zen currently takes about two minutes (on a Quest2). Most of the time is consumed by calculating world mesh chunks and assigning the mesh (etc.) to the proper game objects.

Solution

We can store the created objects and its components in cache files. Either via plain YML/JSON/binary files or to something sophisticated like glT where we can Export/Import whole GOs+Components at runtime.

Tasks

• [ ] Build cache store mechanism
  • [x] ~Alter GameObject creation to not create Unity GameObjects, but store the neccessary data into lists and store them later (do not render data - save performance and unneccesary memory usage)~ --> Out-of-Scope: This would require a whole rewrite of VobManager and WorldCreator logic. Skipping for now.
  • [x] Add header information with version flag. i.e. if we change something on the data to cache, this will be checked and cache will be recreated automatically
  • [x] Explore options on how to save+retrieve async without frame impediments (e.g. save into multiple files, read a chunk of bytes per frame only, check if non-main thread is sufficient to not block main game loop) --> FIX: Task.Run() is saving and loading data in another thread. Fully async and non-blocking.
  • [x] Store duplicate meshes for VOBs as one Mesh only and reference it during loading
  • [x] Check if Binary read+write is better or JSON based (file storage size + file read times) --> FIX: We store via Unity's JsonSerialize and GZIP the data before storing. G1 all Worlds+static VOBs: ~70MB (similar to glTF solution size tested before)
  • [x] Explore compression of cache files. Measure how it impacts save+load performance and storage needs. --> FIX: GZIP applied to FileStream when saved. Shirnks files by factor 10. (whole G1 caching without it ~600MB with ~60MB)
  • [ ] Support SkinnedMeshRenderer for VOB Waterpipe in G1. (Add bones and bone weights.)
• [ ] Build cache retrieve mechanism
  • [x] Retrieve data in a non-blocking way (no frame drops on player movements itself) --> FIX: Tas.Run() as well
  • [ ] Vobs: VobCacheManager loads them without Prefab usage and no additional Components (i.e. only MeshFilter+MeshRenderer). We need to loop through them again and apply Prefab elements (most likely: Clone components from cached data into new objects)
  • [ ] Vobs: Load additional Vobs which are not from cache (e.g. ZoneMusic) and place them inside same Hierarchy. To be handled by VobManager
• [ ] Misc
  • [ ] Create proper Loading Manager to highlight status of loadings (ProgressBar fix)

Links

• BinaryFormatter vs JSON serialization: https://medium.com/nerd-for-tech/how-to-implement-serialization-and-deserialization-in-c-f783e7fc0901

[JaXt0r]

WARNING: I checked with glTF implementation, but it lacks features which we need to store and retrieve in parallel

1. It stores UV values as Vector2 only
2. It doesn't store Color32 data
3. It also doesn't store SkinnedMeshRenderer data. Therefore the water pipe is broken and can't be used
4. Not quite sure, but I also think meshes won't be reused but when restored from glT file, they leverage new vertices all the time.

Therefore I recommend we build the save+retrieve logic fine tuned to our needs on our own. We can still check their open source implementation for details: https://github.com/atteneder/glTFast

[JaXt0r]

Closing for now due to lack of performance gain and complexity increase on the named solution above. Alternatives and possible next steps are documented in here: https://github.com/Gothic-UnZENity-Project/Gothic-UnZENity/pull/146#issuecomment-2393713233

Feel free to create a new ticket with some proper solution based on the current investigations and dead ends. ;-)