Normcore Meta Avatars Setup Issues
I was following the Meta Avatars Setup described onthe webpage. I do have an app ID, data checkup was successful, I have a test user, etc. and entitlement check was successful.
However, I still get several error that I have never gotten before and the avatar is blue (see error logs in attached file).
109 Replies
Hi @Robi🐋. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I'm sorry to hear that you're experiencing issues with the Meta Avatars setup. Unfortunately, without the specific error logs, it's difficult to provide a precise solution. However, I can provide some general troubleshooting steps based on the information provided in the Normcore documentation.
1. Check your setup: Ensure that you've correctly followed all the steps in the Meta Avatars Setup guide (https://normcore.io/documentation/guides/meta/meta-avatars-setup). This includes importing the "Meta Avatars" sample, adding the "AvatarSDKManagerMeta" prefab to the scene, and adding your App Key to the Realtime component.
2. Check your entitlements: If your app quits immediately on launch, it could be due to the entitlement check failing. Make sure the Meta account used by your Quest has been added to the release channel for your Oculus App ID as described in the Meta Platform Prerequisites guide (https://normcore.io/documentation/guides/meta/meta-platform-prerequisites).
3. Check your Unity project setup: Ensure that you've correctly set up your Unity project as described in the Meta Platform Prerequisites guide (https://normcore.io/documentation/guides/meta/meta-platform-prerequisites#set-up-your-unity-project). This includes installing the necessary Meta SDKs from the Asset Store and configuring your App ID.
4. Check your avatar prefab: If you're using a custom avatar prefab, ensure that it's correctly set up as described in the Meta Avatars Customization guide (https://normcore.io/documentation/guides/meta/meta-avatars-customization).
If you're still encountering issues after checking these points, I recommend reaching out to the Normcore community on their Discord (https://normcore.io/documentation/essentials/common-questions#does-normcore-support-x-y-z) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@447417712772120576> kapa.ai is still learning and improving, please let us know how it did by reacting below
this is my hierarchy

Which avatar SDK are you using? Meta /just/ released a new one last week and we haven’t added support yet
Yeah, I'm still using the previous version
Hey, does this happen in build or in the editor (Play mode)?
Something to watch out for is that Rift/Quest are completely separate apps in Meta's backend

For the editor you'd need to fill in the Rift ID
for the editor you can also use the test user credentials or avatar sample assets. i think it must be something else. is there any version you guys would recommend where you are sure it works?
I tested it yesterday to make sure it still works, all good in our test project
I'll gather the info
My dependencies were:
On Unity 2021.3.37f1
@Normcore Assistant using the AvatarSDKManagerMeta the meta avatars some times disappear and reappear how can I prevent that from happening?
Let me check the knowledge base for you. One moment! :books:
----------------------
The issue of avatars disappearing and reappearing could be related to a few factors. Here are some potential solutions based on the information provided in the Normcore documentation:
1. Check your RealtimeAvatar component: Ensure that the RealtimeAvatar component is correctly set up on the root of your avatar prefab. This component is responsible for synchronizing the head and hands positions and active states. If it's not set up correctly, it could cause issues with your avatars. You can find more information about this in the RealtimeAvatar documentation (https://normcore.io/documentation/realtime/xr/avatars#realtimeavatar).
2. Check your network connection: If your network connection is unstable, it could cause your avatars to disappear and reappear. Normcore's networking is designed to be robust, but it's still dependent on the quality of your internet connection.
3. Check your avatar instantiation: Ensure that your avatars are being correctly instantiated at runtime. If they're not in a Resources folder, they might not be instantiated correctly, which could cause them to disappear. More information about this can be found in the Meta Avatars Customization guide (https://normcore.io/documentation/guides/meta/meta-avatars-customization).
4. Check your RealtimeView settings: If the root RealtimeView is not set to
destroyWhenOwnerLeaves
by default, or if you clear the owner of the avatar itself, then it will not be cleaned up properly by the server. This could potentially cause your avatars to disappear and reappear. More information about this can be found in the Common Questions section of the Realtime documentation (https://normcore.io/documentation/realtime/common-questions#xr).
If you're still encountering issues after checking these points, I recommend reaching out to the Normcore community on their Discord (https://normcore.io/documentation/essentials/common-questions#does-normcore-support-x-y-z) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@1124402583155511357> kapa.ai is still learning and improving, please let us know how it did by reacting below
Try this for the appearing/disappearing issue:

@Normcore Assistant Asset Packages/com.normalvr.normcore/Normal.Realtime/2019/Standalone/Normal.Realtime.sln has no meta file, but it's in an immutable folder
Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message you're seeing typically occurs when Unity is unable to find a
.meta
file for an asset. .meta
files are used by Unity to store import settings and other information about assets.
In your case, the asset in question is Normal.Realtime.sln
, which is part of the Normcore package. This file is located in an immutable folder, meaning it's part of a package and should not be modified.
Here are a few steps you can take to resolve this issue:
1. Reimport the Normcore package: This can be done by going to the Unity Package Manager, finding the Normcore package, and clicking the "Reimport" button. This should force Unity to regenerate the .meta
file for the Normal.Realtime.sln
asset.
2. Delete and reinstall the Normcore package: If reimporting doesn't work, you can try deleting the Normcore package and then reinstalling it. This can be done from the Unity Package Manager. Be sure to back up any important data before doing this, as deleting the package will remove all of its contents.
3. Check your Unity version: Ensure that you're using a version of Unity that is compatible with the version of the Normcore package you're using. You can check the Normcore documentation (https://normcore.io/documentation/essentials/getting-started) for information on which versions of Unity are supported.
If none of these steps resolve your issue, I recommend reaching out to the Normcore community on their Discord (https://normcore.io/documentation/essentials/common-questions#does-normcore-support-x-y-z) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@1124402583155511357> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
I've experienced that while still using the older Avatar SDK, I still got issues like these after my Quest system has had its latest update (the one using the new avatar system). Does your device also happen to already use the new avatars?
@kapa.ai how can i allow users to block other users in my Oculus Quest 2 project via Normcore
Let me check the knowledge base for you again. One moment! :books:
----------------------
To implement a user blocking feature in your Oculus Quest 2 project using Normcore, you'll need to create a custom solution as Normcore doesn't provide a built-in blocking system. However, you can leverage Normcore's ownership and networking features to achieve this functionality. Here's a high-level approach you could consider:
1. Create a custom component to manage user blocking:
You'll need to create a custom RealtimeComponent that stores a list of blocked user IDs for each player. This component should be attached to each player's avatar or a dedicated manager object.
2. Use Normcore's ownership system:
Utilize Normcore's ownership system (https://normcore.io/documentation/room/ownership-and-lifetime-flags#ownership) to ensure that only the local player can modify their own block list. This prevents other players from maliciously altering someone else's block list.
3. Implement blocking logic:
When a player blocks another user, add the blocked user's ID to the custom component's block list. You can use Normcore's networking features to synchronize this information across all clients.
4. Handle blocked users:
In your game logic, check the block list before allowing interactions between players. For example, you might disable voice chat, hide avatars, or prevent other interactions between blocked users.
5. Persist block lists:
Consider using Normcore's datastore (https://normcore.io/documentation/architecture/client#datastore) to persist block lists between sessions, so players don't have to reblock users every time they join.
Here's a basic example of how you might structure your custom blocking component:
Remember to implement appropriate UI for users to block/unblock others, and integrate this system with your existing player management and interaction systems.
For more information on creating custom RealtimeComponents and working with Normcore's networking features, refer to the Normcore documentation (https://normcore.io/documentation/).
If you need further assistance or have more specific questions about implementing this feature, consider reaching out to the Normcore community on their Discord (https://normcore.io/discord) or forum (https://forum.normcore.io/).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@1124402583155511357> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant using Normcores AvatarSDKManagerMeta my meta avatar is instaniating with no head
Let me check the knowledge base for you again. One moment! :books:
----------------------
I'm sorry to hear that you're experiencing issues with your Meta Avatar instantiating without a head when using Normcore's AvatarSDKManagerMeta. This is an unusual problem, but let's try to troubleshoot it based on the information available in the Normcore documentation.
1. First, ensure that you've correctly set up the Meta Avatars as described in the Meta Avatars Setup guide (https://normcore.io/documentation/guides/meta/meta-avatars-setup). This includes importing the "Meta Avatars" sample, adding the "AvatarSDKManagerMeta" prefab to the scene, and adding your App Key to the Realtime component.
2. Check that you're using the correct prefab. The guide mentions using the "Realtime + Meta Avatar Player" prefab. Make sure this prefab is correctly placed in your scene and that it hasn't been modified unintentionally.
3. Verify that the MetaAvatar component is properly set up on your avatar prefab. As mentioned in the Meta Avatars Customization guide (https://normcore.io/documentation/guides/meta/meta-avatars-customization), the MetaAvatar component should be on the root Game Object of your avatar prefab. It includes a button to "Set Up Meta Avatar" which configures all necessary components.
4. Ensure that the Local Avatar and Remote Avatar prefabs are correctly referenced in the MetaAvatar component. These prefabs are provided as part of the Normcore Meta XR package.
5. Check that your avatar prefab is in a Resources folder so it can be instantiated at runtime, as mentioned in the customization guide.
6. Make sure that the RealtimeAvatarManager component has the correct reference to your Local Avatar Prefab.
If you've verified all these points and are still experiencing the issue, it might be a problem with the Meta Avatar SDK itself or how it's interacting with Normcore. In this case, I recommend reaching out to the Normcore community on their Discord (https://normcore.io/discord) for more specific assistance. They may have encountered similar issues and can provide more targeted troubleshooting steps.
Remember, when dealing with avatar systems, especially those that integrate multiple SDKs like Normcore and Meta's Avatar SDK, issues can sometimes be complex and require detailed investigation. Don't hesitate to seek direct support from the Normcore team if you continue to face difficulties.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@1124402583155511357> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@maxweisel I need some help here please. Using Normcore Meta XR (AvatarSDKManagerMeta - Realtime + Meta Avatar Player) Turns out my Meta avatar is trying to load as I see my hands (skin tone) and top that I have on my avatar, however the head is not visible. I followed all the instruction to a T and have also sucsessfully done this in a nother project. Not quite sure what I might have missed and it's racking my brain. I'ts like when you use the Meta Avatar SDK and forget to change the 'First Person' if you know what I mean. Maybe I need new glasses or I'm seriously loosing it. Please help. And for the recored, yes I have avatars set up in my meta hub, I have the entitlement check in my scene. Like i said, the avatar is not that standard blue when you're not set up right, I have my hands and outfit, just not my head. Thanks!
Hey, do you know if the avatar being loaded is v1.0 or v2.0 type of avatar? We're currently working on adding support for the v2.0 avatars that Meta released recently. It's expected that they might not load/render properly at the moment.
I'm using the Meta Avatar Player located in Normcore Meta XR>1.0.0>MetaAvatars>Meta Avatar Player>Resources:
As for the Meta Avatars SDK I did not install the recent update with 'Full Bodies' if that is what you are asking. So in short, I'm saying v1.0
Honestly not sure. I assume you already checked all the render flags on the avatar component and stuff like that. Fwiw we're trying to ship Avatars 2.0 as soon as possible and I'm hoping the upgrade resolves this issue. Unless there's anything keeping you on 1.0 aside from us?
Going forward I'm also considering shipping an entire sample project, so there's always a working project users can reference. Meta Avatars SDK has a lot of ever-changing dependencies and configurations, it'll be good to have a reference project where all of it works out of the box.
Hey, the issue is my mirror so I had a few folks join me and we do in fact have heads lol, so I changed the local and remote to third person, now I see my head in the mirror however we all see each other in T pose with our backs to each other. Can you help with that?
Let me check the knowledge base for you again. One moment! :books:
----------------------
This issue with remote Meta avatars appearing in T-pose is a common problem that can occur when using Meta avatars with Normcore. Here are some steps you can take to try and resolve this issue:
1. Check your avatar setup: Ensure that you've correctly set up the Meta Avatars as described in the Meta Avatars Setup guide (https://normcore.io/documentation/guides/meta/meta-avatars-setup). Make sure you've added the "AvatarSDKManagerMeta" prefab to the scene and that your "Realtime + Meta Avatar Player" prefab is correctly configured.
2. Verify the MetaAvatar component: As mentioned in the Meta Avatars Customization guide (https://normcore.io/documentation/guides/meta/meta-avatars-customization), ensure that the MetaAvatar component is properly set up on your avatar prefab. It should be on the root Game Object of your avatar prefab, and you should have used the "Set Up Meta Avatar" button to configure all necessary components.
3. Check RealtimeTransform components: Make sure that you have RealtimeTransform components on both the root of your avatar prefab and on the individual body parts that need to be synchronized (like head and hands). These components are crucial for properly synchronizing the avatar's movements across the network.
4. Verify avatar instantiation: Ensure that your avatar prefab is being instantiated correctly at runtime. It should be in a Resources folder so that it can be instantiated properly.
5. Check for animation conflicts: If you have any custom animations on your avatar, make sure they're not conflicting with the Meta Avatar's built-in animations.
6. Update Normcore and Meta XR packages: Ensure that you're using the latest versions of both the Normcore and Meta XR packages. Sometimes, issues like this can be resolved by updating to the latest versions.
If you've checked all these points and are still experiencing issues, it might be worth reaching out to the Normcore community on their Discord (https://normcore.io/documentation/essentials/common-questions#does-normcore-support-x-y-z) for more specific assistance. They may have encountered similar issues and can provide more targeted troubleshooting steps.
Remember, integrating multiple SDKs like Normcore and Meta's Avatar SDK can sometimes lead to complex issues. Don't hesitate to seek direct support from the Normcore team if you continue to face difficulties.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@1124402583155511357> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
Hi. I checked and have the same dependencies as above and I'm also having the same problem as @marvinrando where others see avatars blue and in T pose. Any help please?
Hey, we're currently working on the 2.0 update which will fix this issue.
Just to be clear, is the current implementation here no longer functional: https://normcore.io/documentation/guides/meta/meta-avatars-setup#install-the-normcore-meta-xr-package
Meta Avatars Setup | Normcore Documenation
Normal and Meta have worked together to provide rich prebuilt avatars that work with Normcore out of the box. This guide will demonstrate how to use the built-in MetaAvatar component to set up networked meta avatars with voice chat in a few minutes.
Just to be clear, Meta seems to have forced those v2 avatars on us and there is no way to revert. So now my project will have to do without Meta avatars until the 2.0 update? I mean it is what it is. Any ETA though?
Hey,
This is a preview version of the Meta Avatars integration update that we're working on.
While it's not 100% ready, it's good enough to unblock those who are eager to test the new avatars. We're also open to user feedback on it.
The user guide (https://normcore.io/documentation/guides/meta/meta-platform-prerequisites) is still mostly accurate. The only differences are:
* Our package now depends on a sample from the Meta Avatars SDK package (for leg animation scripts and animations among other things). We automatically prompt to import the sample.
* We're using the AvatarSdkManagerStyle2Meta prefab that comes from the sample instead of the AvatarSDKManagerMeta that we used to bundle. You may need to re-create the manager in your scenes (using the "MetaAvatarsSDK/Normcore/Create AvatarSDKManager" menu).
* The avatar prefabs that we bundle depend on the Meta sample scripts directly instead of the scripts we used to bundle. This change will only affect projects with custom avatar prefabs. Otherwise it's an invisible change.
We'll update the user guide closer to the official release.
Meta Platform Prerequisites | Normcore Documenation
If you've landed on this page, you're most likely using a feature such as Meta Avatars that relies on the Meta / Oculus platform to be configured correctly first. This guide serves as a quick overview on how to set up your project quickly and avoid common pitfalls.
@marvinrando @chickylittle
@waterwarp (🇳🇱) @Robi🐋
@Malintis
The issue I am facing remains. The remote avatars are in T-pose. Any help with this will be great.


That's awesome Mark. I'll test it tomorrow.
removed the old normcore meta avatar package, placed what's in the zip in the project/packages folder, but the project returns this critical error:
Packages\com.normalvr.normcore.meta.xr\Normal.Meta.XR.Editor\Avatar\SampleAutoInstaller.cs(71,43): error CS0117: 'PackageInfo' does not contain a definition for 'FindForPackageName'
In the script, this happens when using Unity 2022.3 or newer, which I'm using. It's weird because FindForPackageName should indeed be known in 2022.3. Removing the if statement and using the approach meant for older version works and removes the error:
This is where I end up stuck. What could cause this? Seems at first glance like a missing texture but the default model color is set to blue rather than black. Also, very sporadically I see the proper textures flickering in. This does not happen with the previous version of the package.

Fixed by replacing the Style2Meta avatar shader with the "Meta" one.

and one minor bug.. with a static player (in my case with inactive player controllers), the avatar will still snap rotate when moving the left Touch thumbstick 🙂
you mean the left stick acts like the right stick? probably a input action settings issue
I think the default actions take inputs from all joysticks
oh no I mean I have no active playercontrollers so rotation (or walking) shouldn't be possible in this scene. The player doesn't rotate when using the thumbstick, but the avatar does (not in the old package)
Hey waterwarp, thanks for testing it out. Glad you were able to get up and running!
I'll fix the FindForPackageName issue
The snap turn is coming from
MecanimLegsAnimationController.cs
: you can comment out the UpdateInput
function to remove the snap turn. This is a file distributed with the Meta sample.
Solving the snap turn issue somehow is the last thing on our plate for this update. It gets tricky because this file is coming from Meta's package, not ours.
(We don't want users to have to patch the file)Ah I see. Avatars with legs is an awesome update by Meta but they are still pretty finicky to work with
This is also on Meta's side. The style 2 shaders seem URP only and I'm using built in pipeline. A durable fix that doesn't require tweaking around in package files is making a copy of the two "metastyleshader2configuration" files in the asset folder, set both their shaders to Avatar/Meta, and use those configs in the avatar shader manager component.
Ah ok you mean to preserve backwards-compatibility? So that the "old" prefab is updated automatically when our package is updated?
Still working on the update, but here's a new version. It fixes the issue of the unwanted snap turn. The user guide is still accurate (even if it shows v1.0 avatars).
Zip: https://drive.google.com/file/d/1-OVR9twbbZvGWwTWDXWLq2-K5U8l9sde/view?usp=drive_link
User guide: https://normcore.io/documentation/guides/meta/meta-platform-prerequisites
Thanks! I was just about to work on that bug myself since it was originally not considered priority.
No I'm using the old Avatar shaders because the type 2 ones seem to be only compatible with URP. Weirdly enough, the avatars 2.0 look completely fine
I'm only stuck with remote avatars being invisible. What I know/tried so far:
- All LODs of the remote avatar clone are inactive by default. Forcing LOD0 to be active during play mode doesn't do anything
- It doesn't matter if the remote avatar is in sight of the local player or not, so I assume it's not occlusion related
- The mesh renderer of LOD0 is active and the materials seem to contain that avatar's appearance
- Remote avatar is on the same (default) layer as the local one
- Remove avatar is also invisible to any other camera I put in the scene
- Other custom made objects carried by the remote player are visible and properly tracked (such as that little white box hovering above his head)
- Temporarily converted the project to URP and can confirm that Avatar 2 shaders work properly, but the remote avatar is still invisible
Really at a loss at the moment all settings look perfect

That's odd, I'll try to repro Monday. Which Unity version is the project using?
Thanks for checking it out, I'm using 2022.3.30
please mention me when you get this, as you know that is my issue also
Will do
Can you please tell me how you changed this. I'm in AvatarSDKManagerMeta and i see the field for 'Shader Manager' but can't change it to "Avatar-Meta" or maybe I'm doing it all wrong. Please help, thanks
Yes I notice I skipped a few steps in my descrption, but I see in your screenshots that your avatars show up fine but you have a forced T-Pose issue? Nonetheless, here's what I did
1) Created Normcore's AvatarSDKManager by menu MetaAvatarsSDK > Normcore > Create AvatarSDKManager (as per normal instructions)
2) Unpacked the prefab in my hierarchy, then made it my own prefab in the asset folder
3) Expand, select Style-2-Avatar-Meta (see screenshot)
4) You'll notice the component OvrAvatarShaderManagerSingle points to two config files MetaStyle2ShaderConfiguration and MetaStyle2ShaderConfigurationVertex
5) Make a copy of those config files and put them in your assets folder (I added Evrience to the name to keep them seperated from the original)
6) Select each of those config files, and change the shader from the default Style-2-Avatar-Meta to the old Avatar-Meta. That old shader was located in the same package folder as the new one (Meta Avatars SDK\Scripts\Common\Shaders\Recommended)

Don't know if you worked out your other problems, but not seeing the avatar's head of the local player is normal (no pun intended), as that's the head you're looking from and rendering the head's mesh would interfere with the player's sight (which is why that first person/third person separation is made).
As for your T-Pose problem, have you properly set up the Reatime Avatar Manager with the proper Transform parts of the local player? It's one of the basic steps of setting it all up but one I often forget about.

I do appreciate it big time! Honestly not sure if the T-pose issue is corrected yet as I spoke with Mark and screen shared then updated Normcore next thing I know is that we are not able to see each other in the scene yet we hear each other so I have not been able to determine if that's fix at this point. Either way thanks again! I worked out the 'no head' as that was just my bad lol
Hey, I was able to repro the issue out of the box on BiRP. All LODs are disabled on remote avatars, making them invisible. This is most likely a limitation on Meta's side.
The most straightforward fix is to run in URP, but I'll see what I can do. Maybe I can find a patch around it.
Nvm it might no be related to render pipeline. Doing some more testing...
Avatars 2.0 is a tough cookie.. no tutorials, hardly any dev documentation. You'd expect there to be a bit more now that they're even forcing it
It's actually my fault 😓 My test project was on Normcore 2.9.5, (the latest is 2.13.0) and there's been a regression in Normcore. Version 2.10.4 and older are not affected by the regression, which is why it affected you and not me.
I'll do a couple things:
* I'm working on a proper fix for the bug which we'll try to release as soon as possible to unblock avatars.
* Users can downgrade to 2.10.4 in the meantime, although I recommend waiting for the workaround patch (details below).
* I'm working on a workaround inside our avatars package so that downgrading won't be necessary. I'm hoping to get this done today.
Here's the workaround 👍 . It's compatible with Normcore 2.11.0+. https://drive.google.com/file/d/1Lw6UkRLOrhBke2JlW_WJb91yQ1vQ-zSQ/view?usp=sharing
The file I modified is
MetaAvatarModel.cs
.
Now working on a proper fix that we'll ship in Normcore.this latest update that Mark just posted fixed that but thanks!
In case you're using player controllers, do the remote's leg animations (walking, sitting, crouching etc) also work properly? I can't test yet but those leg animations just seem too revolutionary to work right out of the box lol
I have that stiff leg shuffle, and the feet are in the floor a bit. I'm going to try and work it out later today. I'll let you know if I make any progress.
Can confirm the legs not animating (feet aren't in the floor though). Just a wild guess but I wonder if this is the culprit? It's the local avatar that seems to have an mecanim legs animation controller, causing all kinds of errors because the locals have no head or legs to work with. Contrarily, the remotes lack this component, causing idle legs?

The
Failed to poll
error pops up when the headset is sleeping or not connected. It's only a problem if you see it while your device is tracking. Can you ensure device tracking is working on local & remote and run another test?
I was testing using Playmode and a Windows PCVR build and I struggled a bit with running tracking on both - depending on launch order and window focus. The best way to test would be using 2 separate devices. But I'll check again about the legs not animating.
Yes it had me confused at first too, but Mecanim Legs Animation Controller
is meant to be on the local avatar. It looks like every avatar locally drives their leg animation (in addition to the usual head and hands animation). Remote avatars simply replay the data that the owner sends, and don't run any animation logic themselves. It makes sense because the owner then fully drives the animation.
Heads-up, we just released Normcore 2.13.1 which fixes the invisible remote avatars issue. The patch I made to the avatars package last Friday is no longer necessary, and you can use the previous version (https://drive.google.com/file/d/1-OVR9twbbZvGWwTWDXWLq2-K5U8l9sde/view?usp=drive_link)Neat! I almost got it to work now, but I think most or all of the reasons I'm not fully there yet are on my side now. Here's what I've observed:
- Posture tracking, and idle, crouching, and walking animations work, but walking only when the player physically moves around in their playing field and not when smooth moving with the player controller (which should be possible based on some demos I've seen). I'm sharing the tracking settings of my player object. Should something be made differently?
- Lipsync. Could be me but I think it actually is in sync with how the player speaks rather than just if they speak or not. If so, that's pretty awesome.
- The avatars are entirely visible with both remote and local avatars, but only as long as I'm still using the old meta avatar shaders (which doesn't cause any problems for me AFAIK)
- Would be nice if the "Failed to update state, no head position found" would be a one-time, non-breaking LogWarning (similar to Meta's "headset not connected warning"), since that requirement kind of hinders the flexibility of testing in the editor

All in all this is heading towards some serious Ready Player One stuff. Totally worth it
Hey thanks for the info, it's really shaping up nicely!
- Smooth movement: I haven't tested this actually, but I agree it's pretty important. I'll investigate. I wouldn't be surprised if Meta Avatars only considers tracking data for driving the leg animations. Are you applying smooth movement by moving the root's transform (NormalMetaLocalAvatar)?
- Lipsync: Yes I believe Meta Avatars runs analysis in realtime on the voice for correct mouth shapes.
- Shaders: Seems fine for me on BiRP. I'll check again.
- "Failed to update state, no head position found": Agreed. I'll see what I can do about it.
The acutal Meta Avatar Entity is a child of the Normcore prefab. I wonder if moving the Meta Avatar Entity instead of the root would solve smooth movement. Gonna test.
I'll be out of office for a week, I'll continue working on it when I get back.
It seems the avatar position/rotation is provided to the leg animations (
MecanimLegsAnimationController.GetHeadPosition
) through the OvrAvatarInputTrackingDelegate
(SampleInputTrackingDelegate
) that we set inside SampleInputManager
. Which is currently the hardware pose.
If we add a RealtimeTransform's pose to it we could get something going for locomotion. Or we could modify MecanimLegsAnimationController
to take in a root transform. I'll focus on this when I get back.enjoy your break bro
I'm also trying to figure out how to replace this with the old solid blue material when the texture is missing or still loading. From a distance that pinkish cyborg looking suit looks cool but from up close it's some straight 90s body horror lol

Hey, I'm back! Working on smooth movement/rotation support for the leg animations
@waterwarp (🇳🇱) New version: https://drive.google.com/file/d/1c4p-MZ082fXyx4EG9CBSqtfElwKZEePJ/view?usp=sharing
1. Smooth movement/rotation is reflected automatically on the leg animations. This is handled by the
LocomotionLegAnimationDriver
component in the NormalMetaLocalAvatar
prefab.
2. Disabled the spammy "Failed to update state, no head position found" message.
Still trying to repro the pinkish cyborg look. I did notice something similar if there's more than one Camera tagged as Main Camera in the scene.I hate to say this but I'm not noticing any difference in alpha 3 :/ Walking/rotating animations only show when you physically walk around IRL.
I deleted the old one in the packages folder and replaced it with the new one (and first emptied the entire library folder to be sure). It does show as alpha.3 in the editor's package window. Also I'm using the player's TrackingSpace as the local player's "root" in the Realtime Avatar Manager (anything higher will have make the hands rotating with the head). I even still get the spammy "no head position" error. Is there anything else I should have done to get it working?
Ah my bad for not mentioning this step: You'll have to delete the sample files of the Normcore Meta XR package from your Assets folder and import the sample again. This is because the fixes were done to those files and not the package itself.
ah yes that's it! Wow this is cool
Is it easy to (temporarily) overrule the transforms of the avatar's body parts? that would come in handy to force them into more natural positions in certain situations - like forcing the chest's Y-position in a fixed value to make them "sit" while inside a chair's collider.
Oh, Meta Movement SDK is now available and might make these things a lot simpler and less aggressive than the approach I was thinking of: https://developers.meta.com/horizon/documentation/unity/move-overview/
I haven't looked into the Movement SDK yet. But there is a toggle for sitting on the
OvrAvatarAnimationBehavior
component:
From the docs:

There's also docs for custom animations (seems complicated though): https://developers.meta.com/horizon/documentation/unity/meta-avatars-locomotion
Seemed doable! I gave NormalMetaLocalAvatar a trigger box collider and kinetic rigidbody. Then gave "chair" objects this code:

For apps where detailed hand tracking is important (like shaking someone's hand or showing what small object you're interacting with). This is kind of a problem. I need the remote avatars' hand positions to perfectly align with the local user's hand positions, regardless of sitting, standing, or player height differences (even if it'll make the arms a little freaky, it's a trade-off). What I did for this:
- Input Blend enabled (already is by default)
- Arm Blend maxed to 1 (also default, at 0 they just hang still)
- Anchoring state is Floor (headset fixed the hand problem but made avatars clip in the ground or float based on the player's height, dynamic crouching fixed the hand problem but made the avatars of seated players look constipated)
- GPU skinning instead of compute
- Assigned wrists as critical joints and forced their transform to follow the player's hands (didn't work because meta avatars use skinning)
- If Normcore's next avatar update will enable support for "remote avatar scaling" that would be worth a try, but will make seated players look like dwarves and crouching will be freakish (legs suddenly getting shorter)
I'm worried Meta obsessively prefers aesthetics over function and doesn't want to support a simple "keep the hands where they actually have them". I'll just stick to dynamic crouching until something better comes along and inform players that this is a "standing game"


I'm back from the holidays! Thanks for figuring this out, I'm sure other users will find this thorough investigation very useful.
On my side I'm wrapping up the documentation so we can officially release. Also testing with version 33 of the SDK that was released during the break. No breaking changes in that one but just making sure.
@waterwarp (🇳🇱) woh this is /wild/. If you render a cube with its own RealtimeTransform and set it to the world position of the hand where does it show up on local and remote clients.
It's kind of mind blowing that Meta would allow the hands to be in two different places. Especially if the parent transform of the avatar matches perfectly on both clients.
Yeah the cubes neatly follow the hand transform but not the avatar's hands. I'm far from a coding expert so I'm not 100% certain it's not me, but anything close to a solution requires really hack-ish ways. It's how Meta seems to roll tho. Less user-friendliness is less visible in promo videos than their avatars having long, weird looking arms I guess. :/
btw dynamic crouching only works in editor. Documentation also pointed out it's meant for mixed reality only so I guess that's why. I just use Headset anchored when accurate hands are really essential and just shrug off feet clipping into the ground
man that's so rough, but also classic Meta 😦 - It seems like when they went to do leg animations, rather than trying to stretch the legs they pin everyone's feet to the ground...
what a disaster
I read that Meta was looking forward to people dating in the metaverse. That's going to be some awkward handholding lol
lmao
@NormalMark I think in LocomotionLegAnimationDriver, adding delta.y = 0 to GetPositionDelta is helpful to prevent walking animations when Y position is changing, for instance when on a moving platform.
Good catch, I'll fix it 🙏
@waterwarp (🇳🇱) We released our package! https://docs.normcore.io/guides/meta/meta-avatars-setup
It's compatible with Meta Avatars v33 and v35
Like for the earlier version, for migrating you'll have to delete the Normcore Meta XR sample and import it again
@Robi🐋 @marvinrando @chickylittle Letting you guys know as well. It's been a minute but we just released our Meta Avatars 2.0 integration.
thanks!
is there a changelog on this latest version?
The differences between the officially released version and the alpha .zip I uploaded earlier in this thread are:
* Compatible with Meta Avatars SDK v33 + v35-pre.1 (instead of v31)
* In LocomotionLegAnimationDriver.cs, added delta.y = 0 to GetPositionDelta to prevent walking animations when Y position is changing, for instance when on a moving platform. (credits to waterwarp)
v33 and v35-pre.1 from Meta include better hand alignment, pose fixes, and remote avatar scaling.
latest version works really well and those bad hand heights seem mostly a thing of the past with remote scaling (and Meta Avatar's upcoming v35 update will probably finetune it even more with Avatar joints override). Upon avatarcreated, I do "behavior.RemoteScaleFactor = head.transform.position.y / 1.65f" for any non-local avatar and it seems to do the job as far as I can tell.
is there a reason you have remoteScaling disabled by default on the remote avatars? Like is there any downside to it I'm not aware of?
Glad to hear the update went smoothly 🙂
There's no downside, it just wasn't clear to me how to use the feature before v35-pre.1 dropped.
Yes a scale of 1.0 on a remote avatar corresponds to 1.65m, it's the exact constant from Meta:
private const float _neutralHeadsetYForDefaultAvatarHeight = 1.65f;
Meta uses the same formula you do in v35-pre.1 for the ApplyRemoteScaleFactorForCurrentTrackingData
and CalcRemoteScaleFactorForCurrentTrackingData
functions in OvrAvatarAnimationBehavior.cs
.ah nice so they kind of automate it then. Makes sense because at first glance it almost seemed to suggest that you'd have to set the amount manually based on the player's physical height (which would be weird and unnecessary)
Uh one thing though.. often when I tweak around with the normcore's meta package (usually when updating), my build is over 200Mb larger. Same thing happened now after updating Normcore Realtime + Meta Avatars. Build is 360Mb while it used to be a little over a 100Mb.
I've fixed it in the past but never really figured out what did it. I tried not having an avatar manager in the main app (but only in the assetbundled multiplayer scenes), making a clean build, removing avatar samples from the main menu, clean up old assets, deleting all unused assets, and removing any Normcore.
Is this a known problem?
I'm sure the extra build size is coming from the preset avatars. There used to be around ~10 in the old version of Avatars. In Avatars 2.0 there's about 30. https://developers.meta.com/horizon/documentation/unity/meta-avatars-load-avatars#preset-avatar
You can find this window in
MetaAvatarsDK/Assets/SampleAssets/Preset Selector
:
Might be worth adding this to a Common Questions page for Meta Avatars in the docs. I remember I asked you this question too lol
I was hoping it would have anything to do with those presets, since my window looks like this since the update. Those console errors appear when I have it opened.
I pretty much ignored it because I wasn't using presets anyway, but by the looks of it I'm going to have to get this working anyway

The avatar animations in 2.0 are around 150MB (in project before build) which might also contribute. The animation fbx files include meshes. If those meshes do end up in the build then that could be increasing the size.

That's unfortunate. Yeah lmk if you manage to disable the presets because they're my suspect number 1 for the increased build size
those definitely make it into the build because there's a lot of dependency errors in the console when those are removed. Guess there's no way around then. Nitpicking which animations I would or wouldn't use doesn't seem wise.
tbh I'm actually not noticing much of a difference when using remote avatar scaling. I see its slider go up and down when that player's head does so it all seems to work. Maybe the difference is extremely subtle or something.. have you tried it?
It worked for me
I remember I had to set both the bool (to enable it) and the scale
In the samples from Meta the scaling only works in the LegsLoopback scene
Because it's tied to the
OvrAvatarAnimationBehavior
component I believe
I'll test again today
The scaling works for meThe checkbox must be ticked tho:

It's also counter-intuitive in that you set the scale on the local player
It has no effect locally, but the remote player who observes that player will see the effect
oh yeah I'm using this for the remote player, with remote scaling enabled and the scale factor slide automatically moves with that player's head. I'll tweak around some more!
Are you calling
ApplyRemoteScaleFactorForCurrentTrackingData
every frame by any chance? It's the only thing I can think of
Well also make sure you set the scale factor on the local player by the local client - the results will not be visible on the local client but they will be visible for everyone else who sees this player as a remote player on their sideman.. Sorry for the inconvenience. This actually fixed it. I have the tendency to look in the most complicated corners first before considering the most simple approaches
I mean I even went out of my way to -exclude- the local player in code
No worries Water, I really appreciate you trying out the package and bringing up these issues. No doubt other users will hit the same difficulties but we'll have the answers for them 🫡
Alright in this case I think I really do have something. So I spent the week trying to figure out why everything works perfectly in and from the Unity Editor, but an avatar played in a Quest build will not rescale for others. In short: an avatar played from Unity Editor (even if viewed from a Quest) will scale correctly, but not the other way around (or from Quest player to Quest player). Debug.Log in both build and editor confirms remoteScalingEnabled = true for all avatars (local and remote), and I can see the scale factor slider moving up and down with the avatar’s head Y position. But in a build, the avatar just stays the same size.
Things I've tried:
- Calculating remote scaling using the OVR rig’s head instead of the avatar’s head.
- Using LateUpdate to set the remote scale value.
- Using a coroutine to force an even later update.
Possible roots of the problem, but both just seem so unlikely:
- Remote scaling simply doesn’t work from an .apk for local avatars?
- In build, the scene is loaded from an assetbundle (which is different from testing in-editor, but logging still shows all the correct values).
Any insights would be greatly appreciated!
I'll look into it
I've only tested scaling in the editor, so I'll test it on Quest
Which version of Meta Avatars SDK are you using?
hey! that's Normcore Meta XR 2.0.1
With Normcore 2.13.2
Meta XR all in one 72
Meta Avatars SDK 33