cancel
Showing results for 
Search instead for 
Did you mean: 

Android avatars floating at 1.5m

SkyMage
Explorer
I'm running the social starter example between a gear VR and my Unity editor.
Unity v5.6.3f1, Oculus Utilities v1.19.0, OVRPlugin v1.19.0, SDK v1.19.0.

I'm finding that the character running on the PC has no cone of light underneath, and spawns at the position of the trackingspace. The character running on the android build, however, spawns at the same position, but with a base cone. That is, the android character's light cone begins at eye level, and the avatars head is probably 3-4 meters up in the air. It serializes this value, and so appears the same to remote users. 

How do you enable and disable the base cone? can its size be changed? it seems to make my character VERY tall compared a properly scaled human being. Any idea how I might have done this? lol

20 REPLIES 20

SkyMage
Explorer
I can articulate this better.
empty project, import Oculus Utilities v1.19.0, Oculus Platform SDK v1.19.0, Avatar SDK 1.16.0.
Configure all the build settings, supplying both APP IDs to the platform and the avatar sdk. Targetting android.
Most things are working properly in the Social Starter example, with the following exceptions:
* On android, remoteavatar prefab renders correctly, but without a base cone. Avatar spawns with eyes on-level with the camera, as intended. 
* On android, the localavatar prefab, with "show third person" enabled, renders with its base cone starting at eye level, putting the avatars head way up in the air.
* In the Unity 5.6.3f1 editor, the localavatar prefab renders correctly, but the remoteavatar prefab renders up in the air. 

For a while I thought the localavatar on the android was reporting the wrong localposition to the P2P manager, but that isn't the case.

With the app running in the unity editor, I can drop a localavatar, and a remoteavatar (prefabs) onto the OVRCameraRig's tracking space, and the behavior is the same. LocalAvatar will render as expected, RemoteAvatar will render with the bottom of its base cone at the same height as the LocalAvatar's eyes.

I'm also noticing that P2P connections and VOIP calls take many attempts to establish, usually over a minute of connections and subsequent timeouts. Is this normal?

SkyMage
Explorer
I got my hands on a second Galaxy S6 / Gear VR SM-R234 and ran a test with two androids (and no PC.) In this case both the local and the remote avatars rendered up in the air rather than feet-on-the-ground. My conclusions are that:

* The HEIGHT_OFFSET variable applied to the received network position of remoteavatars is in correct, should be something like position.y -= charactercontroller.height / 2

* A similar offset should be put in for the localavatar

* Avatars running in unity editor with a DK2 don't render properly. They omit their base cone and therefor render at the wrong height.

* Presence or absense of basecone affects total height of the avatar, and this seems unintended

I notice that this bug was reported 2 months ago, long before the current release came out, and that that thread has gone unanswered. I have to say, I don't think Oculus made this any priority. It's a simple, show stopping bug in your own example code. The average (indie, amateur) asset developer would have had this fixed in a day or so. I have to grade Oculus an F in this instance. We all make mistakes though.

Please try to be more responsive to feedback as a company, the developer community is going to have a major influence on Oculus' market share over the next few years. I've reviewed a lot of this forum, and IMO, Oculus should devote more staff hours to this place.

Will wait patiently for an update, and I'll come up with my own workaround for now based on my notes above. Happy Friday!

SkyMage
Explorer
Thank you sir, much appreciated!

Anonymous
Not applicable
This is still an issue as far i can tell with the latest AvatarSDK V1.27
Just to keep my personal sanity: has this officially been fixed?
In that case my problem would have to be a failure on my side.
 Or do other people too still see a +1.5 units vertical offset of Avatars on Android ?

Digibix
Protege
Yes, I can confirm the vertical offset error its still on AvatarSDK V1.27 on Android...

What I do, when I detect I am running on android, I put an Y offset of -1.7f (since on my app the avatar should be at sitting height)

Anonymous
Not applicable

digibix said:

Yes, I can confirm the vertical offset error its still on AvatarSDK V1.27 on Android...

What I do, when I detect I am running on android, I put an Y offset of -1.7f (since on my app the avatar should be at sitting height)


Thanks for the confirmation. I do the same, but problem is:
if you load a RemoteAvatar from a remote player using the Rift Headset ( via Platform SDK ) the Avatar position is correct ( at 0 ). So to make this disctinction possible,  i would have to send each remote user's HMD info over P2P, just to be able to place the avatars correctly. This is pretty insane and should defintly be fixed

Ross_Beef
Heroic Explorer
Hey all,

Wanted to provide an update. We’re working on landing this as soon as possible, updating the samples and providing documentation to
make this more clearly understood. Targeting the 1.28 SDK release if we can get it in.

High level, there’s a mismatch between the OVRCameraRig setting which we didn’t catch (Floor level vs. Eye level), and will put in a more sensible solution for it.

Thanks for your patience, apologies that this specific thread somehow got through the net (likely during our work to update avatars to the new look and shaders)

Anonymous
Not applicable
Thanks Ross for the info, a definitely welcome fix ...
And your hint about the OVRCameraRig's Eye vs. Floor level is exactly what i had on my suspicion radar too
BTW: another SERIOUS issue with the Avatar SDK on mobile ON DEVICE when loading customized avatars, is that the avatar scripts throw a HELL lot of errors when building the custom avatar textures ( some graphics error about not being able to copy regions of compressed textures or similar ). Overall Avatar SDK feels much like a beta ATM

Ross_Beef
Heroic Explorer
That’s unfortunately a Unity specific engine issue that we can’t solve for in certain versions of Unity. The logging for the texture arrays (the best way to pull off mesh combining and texture atlas) spits out a bunch of log text.

we’re in contact with Unity about it, but I’m not holding out hope for a patch to older versions. I believe we documented it in our release notes, but I’ll double check that this is in there.

Which version are you on?