Using the OVRInteractionRig as a Custom Avatar spawns in strange locations
Hey ya'll - I've made the OVRCameraRig my custom avatar and followed the documentation to get that setup. It spawns but the position always seems to be different. It usually spawns in the floor. I tried making an empty GameObject to use as the local player root transform, but then it spawns in the sky for some reason. Any guidance would be appreciated. Thanks!
13 Replies
Hi @Brotchvorger. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
It sounds like you're experiencing issues with the spawn position of your custom avatar when using OVRCameraRig as the avatar root. This is a common challenge when integrating custom camera rigs or XR setups with Normcore's avatar system.
Here are some key points and recommendations based on the Normcore documentation:
1. Avatar Root and Head Assignment:
When using a custom camera rig (like OVRCameraRig), it's important to ensure that the RealtimeAvatarManager is correctly wired up to use the transforms from your rig. Specifically, you should assign the correct root, head, and hand transforms from your OVRCameraRig to the RealtimeAvatarManager. This ensures that the avatar's position and orientation match your camera rig, rather than defaulting to unexpected locations. If these references are not set up properly, the avatar may spawn at the origin or in an incorrect position, such as inside the floor or in the sky.
XR Avatars and Voice Chat 2. Prefab Setup:
Make sure your custom avatar prefab (which includes the OVRCameraRig or its relevant parts) is set up as described in the documentation:
- The prefab should have a RealtimeAvatar component at its root. - The prefab should be placed in a Resources folder so it can be instantiated at runtime. - Assign this prefab to the RealtimeAvatarManager's "Local Avatar Prefab" field. 3. Transform Hierarchy and Positioning:
If you use an empty GameObject as the root, ensure that its position is set to (0,0,0) in the scene and that the OVRCameraRig is a child of this root. Unexpected offsets can occur if the root or child objects have non-zero positions or rotations.
Creating custom avatars 4. RealtimeTransform and Rigidbody:
If your avatar prefab includes a RealtimeTransform, be aware that transform synchronization can be affected by the presence of Rigidbody components and the transform hierarchy. For XR avatars, you typically want to synchronize the head and hands, not the entire camera rig, to avoid conflicts.
RealtimeTransform 5. Testing and Debugging:
- Double-check the initial positions of all relevant GameObjects in your prefab. - In Play mode, inspect the instantiated avatar's transform hierarchy to see where the offset is introduced. - Make sure there are no conflicting scripts or components that might be resetting or modifying the position at runtime. If after these checks the issue persists, please provide more details about your prefab hierarchy and how you've assigned the transforms in RealtimeAvatarManager. This will help narrow down the cause of the unexpected spawn positions. Summary:
The most likely cause is incorrect assignment of root/head/hand transforms or unexpected offsets in your prefab hierarchy. Carefully review your prefab setup and the transform assignments in RealtimeAvatarManager to ensure everything is wired up as expected. If you need more detailed step-by-step guidance, the XR Avatars and Voice Chat guide is a great resource. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
When using a custom camera rig (like OVRCameraRig), it's important to ensure that the RealtimeAvatarManager is correctly wired up to use the transforms from your rig. Specifically, you should assign the correct root, head, and hand transforms from your OVRCameraRig to the RealtimeAvatarManager. This ensures that the avatar's position and orientation match your camera rig, rather than defaulting to unexpected locations. If these references are not set up properly, the avatar may spawn at the origin or in an incorrect position, such as inside the floor or in the sky.
XR Avatars and Voice Chat 2. Prefab Setup:
Make sure your custom avatar prefab (which includes the OVRCameraRig or its relevant parts) is set up as described in the documentation:
- The prefab should have a RealtimeAvatar component at its root. - The prefab should be placed in a Resources folder so it can be instantiated at runtime. - Assign this prefab to the RealtimeAvatarManager's "Local Avatar Prefab" field. 3. Transform Hierarchy and Positioning:
If you use an empty GameObject as the root, ensure that its position is set to (0,0,0) in the scene and that the OVRCameraRig is a child of this root. Unexpected offsets can occur if the root or child objects have non-zero positions or rotations.
Creating custom avatars 4. RealtimeTransform and Rigidbody:
If your avatar prefab includes a RealtimeTransform, be aware that transform synchronization can be affected by the presence of Rigidbody components and the transform hierarchy. For XR avatars, you typically want to synchronize the head and hands, not the entire camera rig, to avoid conflicts.
RealtimeTransform 5. Testing and Debugging:
- Double-check the initial positions of all relevant GameObjects in your prefab. - In Play mode, inspect the instantiated avatar's transform hierarchy to see where the offset is introduced. - Make sure there are no conflicting scripts or components that might be resetting or modifying the position at runtime. If after these checks the issue persists, please provide more details about your prefab hierarchy and how you've assigned the transforms in RealtimeAvatarManager. This will help narrow down the cause of the unexpected spawn positions. Summary:
The most likely cause is incorrect assignment of root/head/hand transforms or unexpected offsets in your prefab hierarchy. Carefully review your prefab setup and the transform assignments in RealtimeAvatarManager to ensure everything is wired up as expected. If you need more detailed step-by-step guidance, the XR Avatars and Voice Chat guide is a great resource. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@473336925474783233> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant Which components from the OVRCameraRig should be set as Head, Left Hand, and Right Hand?
Let me check the knowledge base for you again. One moment! :books:
----------------------
The knowledge sources do not explicitly specify which components from the OVRCameraRig should be set as Head, Left Hand, and Right Hand in the RealtimeAvatarManager. However, they do state that when using a custom camera rig, you need to wire up the Root, Head, and Hand transform inputs on the RealtimeAvatarManager to ensure your RealtimeAvatar instance matches the transforms of your camera rig instead of using the default Unity XR APIs. This is especially important when using plugins like VRIK or custom rigs like OVRCameraRig.
If you are unsure which transforms to use, you should look for the corresponding head and hand anchor transforms within your OVRCameraRig and assign those to the RealtimeAvatarManager’s fields. If the documentation for OVRCameraRig or your project’s hierarchy does not make this clear, you may need to inspect the OVRCameraRig in your Unity scene to identify the correct transforms.
I'm sorry, but there is no explicit mapping provided in the Normcore documentation for OVRCameraRig’s components to the Head, Left Hand, and Right Hand fields in RealtimeAvatarManager Common Questions: XR.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@473336925474783233> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@Normcore Assistant This issue still persists even with the correct transforms for head and hands. I can move around fine but when another player join the room we both get pushed into the ground and can't move.
Let me check the knowledge base for you again. One moment! :books:
----------------------
I'm sorry you're still experiencing this issue. Based on the knowledge sources, here are some important points and possible causes for avatars being pushed into the ground and unable to move when another player joins:
1. Transform Synchronization and Ownership
If both players are being pushed into the ground and can't move, it's likely related to how ownership and synchronization are set up. In Normcore, only the client that owns a RealtimeTransform should be able to move it. If ownership is not set correctly, or if multiple clients are trying to control the same transform, you can get conflicting updates that result in unexpected positions or "stuck" avatars.
Make sure each player prefab's root RealtimeView and RealtimeTransform are owned only by the local client, and that you use
When instantiating the player prefab, you should call
If your player prefab uses a Rigidbody with RealtimeTransform, make sure to set "Maintain Ownership While Sleeping" in the inspector. Otherwise, ownership may be cleared when the Rigidbody goes to sleep, allowing other clients to take over and potentially cause conflicts RealtimeTransform + Physics. 4. Transform Hierarchy and Rigidbody Parenting
If your OVRCameraRig or avatar prefab has a Rigidbody and is parented under another moving object, or if there are multiple Rigidbodies in the hierarchy, this can cause unpredictable results. Normcore recommends that Rigidbody objects with RealtimeTransform should not have moving parents, and child objects with Rigidbody should be avoided RealtimeTransform: Transform mode vs. Rigidbody mode. 5. Reparenting and Runtime Changes
RealtimeTransform does not support reparenting at runtime. If your setup involves changing the parent of the avatar or its components at runtime, this can lead to inconsistent state between clients and unexpected behavior RealtimeTransform Extra Notes. Summary:
The most likely causes are ownership conflicts or issues with Rigidbody and transform hierarchy. Double-check that each player only owns their own avatar's transforms, that "Maintain Ownership While Sleeping" is enabled if using Rigidbody, and that your prefab hierarchy does not violate the Rigidbody parenting rules. If these are all set correctly and the issue persists, the knowledge sources do not provide further troubleshooting steps for this specific scenario. If you can share more about your prefab hierarchy and ownership setup, it may help narrow down the issue further. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
If both players are being pushed into the ground and can't move, it's likely related to how ownership and synchronization are set up. In Normcore, only the client that owns a RealtimeTransform should be able to move it. If ownership is not set correctly, or if multiple clients are trying to control the same transform, you can get conflicting updates that result in unexpected positions or "stuck" avatars.
Make sure each player prefab's root RealtimeView and RealtimeTransform are owned only by the local client, and that you use
isOwnedLocallyInHierarchy to ensure only the local player can move their own avatar Ownership + Lifetime Flags.
2. Requesting OwnershipWhen instantiating the player prefab, you should call
RequestOwnership() on each RealtimeTransform that you want the local client to control. This signals to all other clients that this client is the source of truth for those transforms. If you don't do this, or if ownership is not maintained, the server or another client may override the position, causing the avatar to be reset or pushed into the ground Creating a Player Controller.
3. Maintain Ownership While SleepingIf your player prefab uses a Rigidbody with RealtimeTransform, make sure to set "Maintain Ownership While Sleeping" in the inspector. Otherwise, ownership may be cleared when the Rigidbody goes to sleep, allowing other clients to take over and potentially cause conflicts RealtimeTransform + Physics. 4. Transform Hierarchy and Rigidbody Parenting
If your OVRCameraRig or avatar prefab has a Rigidbody and is parented under another moving object, or if there are multiple Rigidbodies in the hierarchy, this can cause unpredictable results. Normcore recommends that Rigidbody objects with RealtimeTransform should not have moving parents, and child objects with Rigidbody should be avoided RealtimeTransform: Transform mode vs. Rigidbody mode. 5. Reparenting and Runtime Changes
RealtimeTransform does not support reparenting at runtime. If your setup involves changing the parent of the avatar or its components at runtime, this can lead to inconsistent state between clients and unexpected behavior RealtimeTransform Extra Notes. Summary:
The most likely causes are ownership conflicts or issues with Rigidbody and transform hierarchy. Double-check that each player only owns their own avatar's transforms, that "Maintain Ownership While Sleeping" is enabled if using Rigidbody, and that your prefab hierarchy does not violate the Rigidbody parenting rules. If these are all set correctly and the issue persists, the knowledge sources do not provide further troubleshooting steps for this specific scenario. If you can share more about your prefab hierarchy and ownership setup, it may help narrow down the issue further. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@473336925474783233> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai To specify, I'm actually using the OVR Interaction Rig from Quest SDK
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thank you for clarifying that you are using the OVR Interaction Rig from the Quest SDK. Based on the knowledge sources provided, there is no explicit documentation or guidance specific to the OVR Interaction Rig or its transform assignments within Normcore’s official documentation.
The documentation does state that when using a custom camera rig (such as OVRCameraRig or similar XR rigs), you must wire up the Root, Head, and Hand transform inputs on the RealtimeAvatarManager to the corresponding transforms from your rig. This ensures that the avatar’s position and orientation match your camera rig, rather than defaulting to unexpected locations. However, it does not provide a mapping or specific instructions for the OVR Interaction Rig’s structure or components Common Questions: XR.
Summary:
I'm sorry, but the knowledge sources do not contain enough information to provide a definitive answer about which specific components from the OVR Interaction Rig should be assigned as Head, Left Hand, and Right Hand in Normcore. You will need to inspect your rig’s hierarchy in Unity to identify the correct transforms for these assignments. If you continue to experience issues, you may want to consult the Normcore community or Discord for more detailed, project-specific guidance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
I'm sorry, but the knowledge sources do not contain enough information to provide a definitive answer about which specific components from the OVR Interaction Rig should be assigned as Head, Left Hand, and Right Hand in Normcore. You will need to inspect your rig’s hierarchy in Unity to identify the correct transforms for these assignments. If you continue to experience issues, you may want to consult the Normcore community or Discord for more detailed, project-specific guidance. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@473336925474783233> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
sounds like you're running player input on remote avatars. you can add a check for isOwnedLocallyInHeirarchy before running any local code or the easiest method is to separate the XR rig from your avatar prefab
Thanks for the reply, @Mechabit ! How exactly would I separate the XR Rig from the avatar? Place an OVRCameraRig in the hierarchy that the local player controls, then have a separate avatar that gets spawned only for synched visuals that is controlled by the head and hands of the local OVRCameraRig?
I think I got it working - I see you plug in the Rig transforms in Local Player Avatar. Thank you!