Basic client-side avatar system

[seekr]

Name: Basic client-side avatar system

Purpose: Provide a basic, customizable visual representation of users in metaverse.

Description Multiple concurrent users within DCL will need a visual representation for social interactions: avatars. An avatar will allow other user to know where is the viewpoint of other users and a custom avatar will allow an easier identification of the another avatar. Interactions and communications between users can now be linked positionally to each avatar.

These basic client-side avatars can be enhanced with custom complex avatars which will be linked to a tile asset (tile-side avatar).

The proposed system is to allow each DCL client to store a basic 16 vertex prism which shape and color is defined by 2 configuration variables. These 2 variables will be sent and propagate P2P to other online clients.

Color is sent first, then the shape coordinates. This allows for progressive enhancement of avatar loading: when a client sees a new user it will first load the color onto the default prism then load the shape as soon as data is received. Any other assets associated with tile-side avatars will be loaded afterwards.

Complex avatars are client-side avatars with attachments models, textures and scripts. These attachments are tile-sided (hosted and linked to a tile-ID). The client-side avatar can be shrunk within the confines of these models.

Summary Client-side avatars are the most basic representation of a user and relies on P2P communication between clients to propagate the avatar position, its color and its shape. Any other further avatar attachments have to have been published to an LAND tile and be downloaded afterwards from network/IPFS.

"mario" in decentraland.slack.com

[pookage]

I very much like the idea of progressive loading - something that should maybe be encouraged as a best-practice for all user models tbh. I'm not sure how much A-Frame automates LODs, but if it doesn't then I'll add it to my to-do list!

How are you planning on ensuring that the basic avatars conform to this standard? Would there be a default 'generator' somewhere that made the distinction between itself and other user-generated avatars (thus not contributing to your LAND upload total)?

[Alonzo-Coeus]

This is a very cool idea, love the abstraction of a human figure. You could use ipfs for complex avatars, I will have a go at implementing this for #40

[seekr]

@pookage quick question, what's LOD?

About your questions, the way I see, the basic avatars standard are confirmed by client itself: Only configuration settings for basic avatars are transmitted. Meaning that client locally loads a prism in place of coordinates of another user, then loads the color setting that's received via P2P and then loads the shape. This way the client dictates what the basic avatars are.

If I use a non-standard client that includes non standard basic-avatar model (say, a sphere) only I can see that spheres in place of other users and configuration settings won't likely work on my models. In this scenario my experiece will be non-standard but everybody else experience will be standard if they're using standard client.

The configuration (color picking,modelling) of this basic prism avatar is enabled at client level as well. If you delete or add vertices to the basic prism (which won't be possible using in-client edit tool) the resulting basic-avatr model becomes non-standard and those settings either won't be transmitted or will be blocked by other standard-clients.

Since models are stored by the client, it won't contribute towards LAND.

[seekr]

@alonzo-coeus that's how I see complex avatars working, they are attachments loaded ontop of basic avatars.

[diogofgr]

@seekr LOD is Level Of Detail