From be60f00a47dc0f2b1c828b590d9e2326784a5a1a Mon Sep 17 00:00:00 2001 From: Matt Young Date: Wed, 30 Aug 2023 22:39:01 +1000 Subject: [PATCH] Update docs --- docs/atlas_optimisation.md | 34 ++++++++++++++++++++++++++++++++++ docs/atlas_tile_design.md | 13 ++++++++----- 2 files changed, 42 insertions(+), 5 deletions(-) create mode 100644 docs/atlas_optimisation.md diff --git a/docs/atlas_optimisation.md b/docs/atlas_optimisation.md new file mode 100644 index 0000000..4ae9c4e --- /dev/null +++ b/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) diff --git a/docs/atlas_tile_design.md b/docs/atlas_tile_design.md index 0567d8e..d71e58a 100644 --- a/docs/atlas_tile_design.md +++ b/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.