Beta - Help - Avatar troubleshooting tips

## Avatar floating above ground

Problem:

The avatar is floating above the ground about 3 inches. I don't know if this is due to the kinect.

Solution:

* Try adjusting the avatar size slider under: VR Menu -> Profile -> Kinematics tab -> Avatar Scale

* Or move the avatar down using the "Down" button on avatar navigation controls.

## View is from inside my avatars and some geometry is blocking my vision

Problem:

* The model did import properly, but currently I can only see from inside it's head, is there a way to fix that?

Solution:
Yes, you have to change the "near clip" slider. Go to VR Menu -> Time bar(below menu window, left side)

## Troubleshooting arm bend offsets

Problem:

Is it just me or are the controllers offset just a little to the right? when I T-pose IRL, the left arm of my model remains a little bent while the right one is capable of being straight.

Solution:

Check that the alignment of the avatar's hands to the controllers are reasonably correct but enabling controller visibility and checking the avatar's hands in VR to see if they are both symmetrically aligned the same or if one hand has a different controller offset than the other. Also, turning down the slider "Rotate chest by hands" or the other spine adjustments made some improvement.

## Avatar sinking on the floor

Problem:

I researched a little into why some avatars are sinking through the floor. I was able to find some models which had hips located at the floor level in the .fbx and would result in the avatar's feet dropping below the floor in Unity.

Solution:

Try option called "Apply Mecanim TPose" when esxporting a model in the APS\_SDK component, it will try to set the armature into the Unity mecanim T-pose prior to building the avatar, this helped fix the floor level issue for some avatars.

## Solving avatar offsets

Problem:

Avatars are showing misaligned or offset in space.
Solution:

I was able to successfully build these avatars and export them and mocap to Blender without seeing any offsets on either avatar.

* Avatar#1 Was modeled with it's hips at floor level in the .fbx - This was causing the mocap avatar to sink into the floor.
* Avatar#1 Used the armature "root" bone as the hip (the spine bone and the 'actual' hip bone were not connected)
* Avatar#1 The armature "root" bone and actual hip bone occupy the same position (floor origin point).
* Avatar#2 Also used the armature "root" for hip but had named the root as hip and spine was a child of that bone.
* Avatar#2 Was scaled to 0.02 but because of the missing armature "root" Luxor was calculating default inverse scale as >50 making the avatar very tall.
* Avatar#2 In the Unity example was using a .dae and not a .fbx - So I added .dae support alongside .fbx support. Users may now build avatars using either .fbx or .dae

I found that by adding a "AmatureRoot" placeholder object to each avatar which used root as the hip was enough to fix the issue. And thanks to these two avatars I was able to write conditional logic into the current sdk that adds the root placeholder automatically.

Not as important but in that second Unity example avatar package there were both .fbx and .dae examples for the same avatar. One potentially problematic issue I realized was when I tried using the .fbx to build the second avatar. It seemed to work in Luxor but I saw misalignment with the avatar's arms and legs after running the SceneLoader in Blender.

I realized that the .fbx was originally exported with animations and Unity was using the first keyframes instead of the armature's actual bind poses. The only thing I found that solves this is to open the .fbx in Blender and re-export the .fbx without the animations.

There appears to be no way to resolve this issue programmatically so it raises a very important consideration for anyone exporting .fbx models and building mocap avatars in Luxor - You sould not export .fbx avatars with animations (alternatively the first animation should be exactly the bind pose < advanced).

## Avatar messes up when importing to blender

Problem:

Model looks on in MF when recording but after exporting the scene and importing to blender well:

Solution:

I figured out what the issues was, actually there were two things which is why it took so long for me to figure it out. I noticed in Blender that the armature origin is about a half meter below the floor, so I reset the origin to zero, but then there were also animation keyframes which after exporting the .fbx with the new origin the keyframes would move the entire model below the floor and cause another issue. Finally after resetting the armature origin to zero and deleting all keyframes, then I could export it to Unity and build it as a custom avatar and no longer was there offsets when building the scene in blender.

## If you get a mess like this, clean up your custom avatar before exporting from blender

I finally looked at that .fbx you shared and I saw in Blender the armature was Not in tpose, and that it had animation keyframes, also it was slightly floating in the air. I reset the armature pose and deleted then re-exported the .fbx and it works.

## Clean up your avatar before exporting from blender

Okay, I just tried building that creature avatar and noticed a couple issues, to begin the skeleton has somewhere in the range of like 300+ bones, which is a bit excessive for trying to build a custom mocap avatar and is definitely is not a standard Rigify armature.

Then I also noticed the creature has like 3 spines and somewhere around 7 hips or so, it also has about 3 heads and was causing Unity to autodetect the incorrect head bone.

I had to fix the head bone mapping and then enforce tpose when then it looked correct. But after pressing play in the editor I noticed parts of the creature's body mesh did not seem to be attached to the actual skeleton or were weight painted to the wrong bones.

But I was able to build it as a custom avatar, after adding the APS\_SDK and pressing build avatar it did generate a output avatar folder containing the thumbnails, and the avatar asset even loaded in APS, but because of the decoupled bones issues the avatar was very stretchy and when recording mocap it caused some undesired results.

I would recommend cleaning up that armature first in Blender by removing unused, unconnected and redundant bones and ensuring there is continuity throughout the hierarchy so that the weight painting doesn't become segmented.

## Make sure your bones are assigned correctly in Unity

If your setups looks something like this, you need to do some manual assigning:

It look like all that's missing is the feet bone haven't been assigned. Does the armature your using include feet bines?

The avatar files are probably not being generated because the pose is invalid and missing some of the required bones. But it appears you're on the right track.

Sometimes unity is unable to determine all of the bones that are necessary for mecanim, and often it can also choose the incorrect bones if the armature contains many additional bones or uses weird names; so be sure to check all bone mappings for consistency. How are the feet bones named on that amateur? Does it include any twist or stretch bones?

Usually simply assigning the mapping manually is sufficient. This step very closely resembles building a avatar for vrchat, so I'm pretty sure there are a bunch of tutorials around that cover how to manually assign and setup the mecanim humanoid map.

Some avatars can be more involved than others, but often are compatible. You can usually drag the appropriate bone from the hierarchy and drop the reference on one of the circles that indicates the missing requirement. Unity has a difficult time auto detecting finger digit bons, but feet are usually okay. Im quite interested to know why it missed em, are they not named similar to footL and footR?