The players received by comms are rendered and also their data is sent to the scenes in a bunch of components:
avatar_customization
avatar_emote_command
avatar_equipped_data
player_identity_data
transform
The current implementation in the three clients send to all the scenes the player-updates before scene.onUpdate is called.
In the case of Transform, this can update up to 10 times per seconds per player. In the reference client the limitation of players are 100.
With multiple scenes running, and many players moving, this could introduce an unnecessary bandwidth.
113 1x1 scenes around you with Scene-Radius 5 => 7,684,000 bytes/seconds or 113,000 CRDT put messages generated
Take into consideration that it's not a memcpy, every CRDT message must be computed (increment timestamp, serialize message, etc)
Proposal
A. Expose a flag somewhere where the scene can subscribe to these updates (Transform), or set its frequency
B. Send the updates from the Avatars that are only inside the scene (for Parcel scenes)
C. A and B
The players received by
comms
are rendered and also their data is sent to the scenes in a bunch of components:The current implementation in the three clients send to all the scenes the player-updates before
scene.onUpdate
is called.In the case of Transform, this can update up to 10 times per seconds per player. In the reference client the limitation of players are 100. With multiple scenes running, and many players moving, this could introduce an unnecessary bandwidth.
Some numbers to the limit
Take into consideration that it's not a
memcpy
, every CRDT message must be computed (increment timestamp, serialize message, etc)Proposal
A. Expose a flag somewhere where the scene can subscribe to these updates (Transform), or set its frequency B. Send the updates from the Avatars that are only inside the scene (for Parcel scenes) C. A and B