When the avatar data is retrieved from comms it is not rendered straight away
All data retrieved from the underlying transport is replicated among all currently running scenes in the renderer
It's a local one-way propagation
It is needed for optimization purposes so a scene can operate with Avatars as entities directly without a need to translate a user address to an entity (this is the difference between SDK6 and SDK7)
Effectively it's needed for efficient in-time access to the avatars' positions
There are two types of AvatarShapes:
A real user
for real users, a fixed range of entity ids is reserved (e.g. 128-512) (keep in mind that Entity is versioned so the range of entities is much wider)
The JS scene itself is fully agnostic to the given range as it queries components
the AvatarShape of the user can be altered by the scene
In this case, a simple prioritization mechanism should be applied: custom scenes have more priority than the global one (from comms)
The reference to the altered Avatar is provided by the same id, but entities are different as they live in different scenes (different ECS worlds)
We must introduce a cross-world mechanism that selects a custom AvatarShape over the global one
Once there is no such custom entity anymore a global one must be used
NPC
unlike real players, NPCs are not deduplicated
AvatarShapes outside the fixed range of real users are always renderer individually (for example we have entity #700 from scene A and entity #700 from scene B, both of them have the same id, but it's outside of [128;512] so these entities are treated like different objects)
m3taphysics
commented
5 months ago
The approach itself is not formalized yet and is partly based on https://github.com/decentraland/hammurabi/pull/29
AvatarShapes:Entityis versioned so the range of entities is much wider)AvatarShapeof the user can be altered by the sceneAvataris provided by the same id, but entities are different as they live in different scenes (different ECS worlds)AvatarShapeover the global oneAvatarShapesoutside the fixed range of real users are always renderer individually (for example we have entity #700 from scene A and entity #700 from scene B, both of them have the same id, but it's outside of [128;512] so these entities are treated like different objects)