entities are synced from and displayed in.
NOTE: Syncing entities work at the granularity regions which are
multi-chunk squares but the display of entities in voxygen is limited in
a circle with the radiues of the supplied distance.
Additional details and changes:
* Added `ViewDistances` struct in `common` that contains separate
terrain and entity view distances (the entity view distance will be
clamped by the terrain view distance in uses of this).
* View distance requests from the client to the server now use this
type.
* When requesting the character or spectate state the client now passes
its desired view distances. This is exposed as a new parameter on
`Client::request_character`/`Client::request_spectate`. And the client
no longer needs to send a view distance request after entering these
states. This also allows us to avoid needing to initialize `Presence`
with a default view distance value on the server.
* Removed `DerefFlaggedStorage` from `Presence` and `RegionSubscription` since the
change tracking isn't used for these components.
* Add sliders in voxygen graphics and network tabs for this new setting.
Show the clamped value as well as the selected value next to the
slider.
* Rename existing "Entities View Distance" slider (which AFAIK controls
the distance at which different LOD levels apply to figures) to
"Entities Detail Distance" so we can use the former name for this new
slider.
distance changes (until the player crossed a chunk boundary and
triggered the normal update).
This introduces a `ViewDistance` struct that provides an abstraction
around limiting the rate the view distance can be cycled up and down.
This helps avoid unnecessary sending, deleting, and then resending of
synced things like entities (the client will still delete its terrain
locally and re-request it though).
The second part of this fix is storing the last view distance in the
`RegionSubscription` struct and then updating region subscriptions if
this doesn't match the current view distance in the `Presence`
component.
Set CHUNK_SITE to 10 which results in a mean of 13ms per Slowjob. Its good if it stays under 30ms so it has less influence on ticks.
Some performance values measured with a AMD Ryzen 1700X:
- voxygen and server and swarm (25 clients, 10 vd) on one machine.
- total runtime was 240s
- CHUNK_GENERATOR total time is 486s with a mean of 40ms
- CHUNK_SERIALIZER total time is 18.19s with a mean of 13ms, so in total its a order of magnitude lower
Trancy confirms this, the Serialize backlog is usually handled within 1-2 ticks.
- terrain::sys total time 1.2s, mean 188us
- msg::terrain::sys total time 812ms, mean 125us
- terrain::sync total time 12ms, mean 1,85us
- chunk_serialize::sys total time 69ms, mean 10us
- chunk_send::sys total time 50ms, mean 7us
so all in all total time for serializsation is 20.33 of which 89% are spend outside of the ECS
- Add metrics for which branch of the compression heuristic was taken.
- Reduce the threshold for the heuristic.
- Deduplicate code for dealing with lazy messages.
- Make jpeg dependency only scoped to the compression benchmark.
- Remove commented code.
lagging a bit behind on terrain. Which is fine. Block Places and Block Pickup are not handled in this stream, as they go through the standart route of event handling.
