-
-
Notifications
You must be signed in to change notification settings - Fork 5
GA API Plans
The document outlines the internal architecture of the raytiles library for version 1.0.0.
TBD: api should allow lat/long instead of tiles.
Instead of providing configurations to the streamer and the streamer initializing the renderer and manager, we will decouple the streamer from the renderer and manager, and they become an inputs.
In this way, we can provide different implementations of the renderer and manager, and we can also test the streamer without the need to initialize the renderer and manager.
Keep the lifecycle of the renderer and manager out of the streamer.
Note that the pool that belong to the manager need to be lazy initialized because it spawn threads.
graph TD
A(Renderer)
B(Manager)
C[Streamer]
A --> A1(Init renderer)
A1 --> C
B --> B1(Init manager)
B1 --> C
C --> D[Init pool]
In this option, the streamer is responsible for lifecycle of the renderer and manager.
graph TD
A(Renderer)
B(Manager)
C[Streamer]
A --> C
B --> C
C --> A1(Init renderer)
A1 --> B1(Init manager)
B1 --> D[Init pool]
sequenceDiagram
participant API
participant Frame
API ->> Streamer: Update shaders values
Frame ->> Streamer: Update
Streamer -->> Manager: Update tiles
Manager -->> Streamer: Tiles
Frame ->> Streamer: Draw
Streamer -->> Renderer: Render
The algorithm is running only when the camera moved more than a configured distance. It supposes to run in a separate thread (not yet implemented).
We always holds all the tiles 360 degrees around the camera, but we render only the tiles in furtsum of the camera.
The reasoning behind this is that we want to support extreme maneuvers of the camera that can flip its direction, and we want to have the tiles ready for rendering when this happens.
- Get camera position and direction
- Clear the set of desired tiles
- Calculate the max distance to render based on the camera height value
Raytiles