Update docs

docs/atlas_optimisation.md

@@ -0,0 +1,34 @@
+# Atlas optimisation ideas
+- Matt Young
+
+## Introduction
+This document contains optimisation ideas for the Atlas renderer.
+
+## Currently implemented
+- Distance culling
+- Frustum culling using model AABBs
+- Two tier (low poly, high poly) LoD system
+
+## Model caching in `AtlasVehicle`
+- Putting **all** renderables between `cache.begin()` & `cache.end()` in `AtlasSceneManager` is **too slow**
+- Each `AtlasVehicle` should maintain two caches for the high and low LoDs which are baked on creation
+- Make sure we use `TightMeshPool`
+- In `AtlasVehicle#getRenderable`, we return the instance of the cache instead of the model
+
+## Ground plane optimisation
+- Problem: Each tile may either be a mesh or a model (probably model?)
+- Solution: Ground is batched into a `ModelCache`, this cache is only invalidated if the visibility changes
+  - HUGE: We _should_ be able to update the `AtlasVehicle` and ground plane model cache asynchronously!!
+  - Beware of threading overhead
+- Consider drawing _beyond_ camera bounds to reduce frequency of ModelCache updates
+
+## Quadtree model caching
+- Imagine we apply `ModelCache` to the entire scene
+- If a vehicle moves, we have to invalidate the cache
+- Worst case scenario: only _one_ vehicle moves, we have to invalidate the entire cache and rebuild
+it regardless
+- **Idea:** Divide cache into a quadtree, only invalidate and rebuild regions in which the vehicle
+moved
+- Quadtree depth based on tradeoff between reducing draw calls (shallower quadtree) and reducing
+cache invalidations (deeper quadtree)
+- Quadtree subdivision could be based on vehicle velocity (likelihood to move)

docs/atlas_tile_design.md

@@ -11,7 +11,14 @@ will attempt to automatically start the tile server. It will then verify the til
 If the tile server crashes, Atlas should throw an error dialogue and probably quit the game.
 
 ## Constructing the grid
-TODO
+- Imagine the ground is an infinite plane
+- We can determine the area of this plane that is visible on screen
+- Using the camera frustum, we can cast rays through the four corners and see where they intersect
+the ground plane
+- This will define the visible view rectangle on the ground
+- At certain low view angles, this would create extremely long regions of the map to be rendered,
+but we can fix this by still doing distance thresholding
+  - Either truncate the rectangle or cap ray length
 
 ## Fetching and caching tiles
 Once the grid is constructed, Atlas will fetch tiles from the tile server using HTTP. To avoid blocking the
@@ -34,10 +41,6 @@ Otherwise, we will re-download it from the tile server.
 The cache will either use Guava's CacheBuilder or Caffeine: https://github.com/ben-manes/caffeine (probably
 Caffeine due to its support of async loading, which makes sense for HTTP)
 
-TODO: tile server should save generated PNGs to a permanent docker volume
-
-TODO we should ideally pre-generate various zoom levels as well
-
 ## Scene optimisation
 Tiles whose centroid is a configurable distance away from the camera will not be added to the render list.