You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are looking to embark on an overhaul of the avatar systems in Ubiq. The goals are to (a) make it easier to utilise avatars of higher capability and visual quality, and (b) make it easier for users to "modify" avatars by applying their own scripts, etc.
Ubiq nominally allows this, and has support for RocketBox etc, but its not as easy for users to start with this as we'd like.
We are proposing a new system that works as follows. It would be good to get any feedback you might have on it!
Types
Like now, we aim to allow the user to swap out the avatar 'system' with their own very easily, since different users need different styles and capabilities which can't all be supported by one.
We recognise however that Avatars are more than just a set of Prefabs, especially when it comes to loading content at runtime. Therefore we want to support different 'types' of avatar. A 'type' being like a subsystem (scripts, prefabs, etc) that has resources that can be loaded by the inbuilt AvatarManager. A type of Avatar could be a Ready Player Me (RPM) avatar, or a RocketBox avatar.
Supporting a specific type will be enabled by importing 'samples'- the same framework introduced for XRI and WebXR.
That is, you'd start with the basic avatars, and then if you wanted to use RocketBox avatars, or RPM avatars, you'd bring in the RocketBox Avatars samples, or RPM samples, and so on.
We would support RocketBox and RPM to start with, in addition to our Basic avatars.
Templates
In the Editor, each type of Avatar would be represented by a single Prefab. Instances of this Prefab would morph to adopt the characteristics of the actual Avatar loaded. So for example, a user could attach say a Particle Emitter to the RPM Avatar Prefab and create their own variant. Whenever an RPM avatar was loaded, it would have the emitter in the correct place.
This is in contrast to say, a system that loaded an AssetBundle and created a new GameObject graph for a particular Avatar.
To make this intuitive as possible for new users, the expectation is that these Templates would appear at design time similarly to how they would at runtime. That is, they would have placeholder meshes, etc, to make them look like initialised avatars, even if those meshes may be replaced at runtime. The compatibility should be to the extent that a user should be able to instantiate a Prefab at design time, and assign this to the AvatarManager, and have (for the local user) use this actual instance when loading the customised avatar.
We may need some visual signals that these are templates, for example, the meshes are untextured, or show textures like a 'crash dummy', etc.
Ideally, things users could do to one type of avatar would be applicable to many. One approach would be to actually have all Avatar Templates derive from a single Base Prefab, though this may not turn out to be practical.
Basic Avatars
We will update the Basic Avatars. Since it will be easier for users to utilise different avatar systems, we will reduce the customisability of the Base Avatars, but increase their quality.
We will aim to have the Basic Avatars mimic the structure of RPM Templates, such that RPM specifically will be able to serve as a drop-in replacement.
This does make RPM the de-facto system for customised avatars for users (though still very much optional). Since RPM is designed for this use case, and is free, it seems quite reasonable, but we'd especially like to hear feedback regarding this.
We will commission a few avatars which approximate the style to make switching as seamless as possible.
The basic avatars however will from now on only serve as prototypes and will not show off advanced functionality - that is, the expectation is that they will be quickly replaced in most projects.
The reasoning is that customisable avatars is predominantly a content creation problem, which is expensive and better outsourced to other projects.
Full Body IK
Since more and more avatar systems are moving to full body representations, we will incorporate a full body IK system in the base avatar part of the package.
We are still not sure how this will work, but there are examples showing it can be done, so we will need to establish an open source version of one of these solutions.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi everyone,
We are looking to embark on an overhaul of the avatar systems in Ubiq. The goals are to (a) make it easier to utilise avatars of higher capability and visual quality, and (b) make it easier for users to "modify" avatars by applying their own scripts, etc.
Ubiq nominally allows this, and has support for RocketBox etc, but its not as easy for users to start with this as we'd like.
We are proposing a new system that works as follows. It would be good to get any feedback you might have on it!
Types
Like now, we aim to allow the user to swap out the avatar 'system' with their own very easily, since different users need different styles and capabilities which can't all be supported by one.
We recognise however that Avatars are more than just a set of Prefabs, especially when it comes to loading content at runtime. Therefore we want to support different 'types' of avatar. A 'type' being like a subsystem (scripts, prefabs, etc) that has resources that can be loaded by the inbuilt AvatarManager. A type of Avatar could be a Ready Player Me (RPM) avatar, or a RocketBox avatar.
Supporting a specific type will be enabled by importing 'samples'- the same framework introduced for XRI and WebXR.
That is, you'd start with the basic avatars, and then if you wanted to use RocketBox avatars, or RPM avatars, you'd bring in the RocketBox Avatars samples, or RPM samples, and so on.
We would support RocketBox and RPM to start with, in addition to our Basic avatars.
Templates
In the Editor, each type of Avatar would be represented by a single Prefab. Instances of this Prefab would morph to adopt the characteristics of the actual Avatar loaded. So for example, a user could attach say a Particle Emitter to the RPM Avatar Prefab and create their own variant. Whenever an RPM avatar was loaded, it would have the emitter in the correct place.
This is in contrast to say, a system that loaded an AssetBundle and created a new GameObject graph for a particular Avatar.
To make this intuitive as possible for new users, the expectation is that these Templates would appear at design time similarly to how they would at runtime. That is, they would have placeholder meshes, etc, to make them look like initialised avatars, even if those meshes may be replaced at runtime. The compatibility should be to the extent that a user should be able to instantiate a Prefab at design time, and assign this to the AvatarManager, and have (for the local user) use this actual instance when loading the customised avatar.
We may need some visual signals that these are templates, for example, the meshes are untextured, or show textures like a 'crash dummy', etc.
Ideally, things users could do to one type of avatar would be applicable to many. One approach would be to actually have all Avatar Templates derive from a single Base Prefab, though this may not turn out to be practical.
Basic Avatars
We will update the Basic Avatars. Since it will be easier for users to utilise different avatar systems, we will reduce the customisability of the Base Avatars, but increase their quality.
We will aim to have the Basic Avatars mimic the structure of RPM Templates, such that RPM specifically will be able to serve as a drop-in replacement.
This does make RPM the de-facto system for customised avatars for users (though still very much optional). Since RPM is designed for this use case, and is free, it seems quite reasonable, but we'd especially like to hear feedback regarding this.
We will commission a few avatars which approximate the style to make switching as seamless as possible.
The basic avatars however will from now on only serve as prototypes and will not show off advanced functionality - that is, the expectation is that they will be quickly replaced in most projects.
The reasoning is that customisable avatars is predominantly a content creation problem, which is expensive and better outsourced to other projects.
Full Body IK
Since more and more avatar systems are moving to full body representations, we will incorporate a full body IK system in the base avatar part of the package.
We are still not sure how this will work, but there are examples showing it can be done, so we will need to establish an open source version of one of these solutions.
Beta Was this translation helpful? Give feedback.
All reactions