Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

Android avatars floating at 1.5m

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

Comments

  • SkyMageSkyMage Posts: 12
    NerveGear
    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?

  • SkyMageSkyMage Posts: 12
    NerveGear
    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!
  • SkyMageSkyMage Posts: 12
    NerveGear
    Thank you sir, much appreciated!
  • spacefrogspacefrog Posts: 55
    Hiro Protagonist
    edited June 2018
    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 ?
  • DigibixDigibix Posts: 17 Oculus Start Member
    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)
  • spacefrogspacefrog Posts: 55
    Hiro Protagonist
    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_BeefRoss_Beef Posts: 170 Oculus Staff
    edited June 2018
    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)
  • spacefrogspacefrog Posts: 55
    Hiro Protagonist
    edited June 2018
    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_BeefRoss_Beef Posts: 170 Oculus Staff
    edited June 2018
    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?
  • spacefrogspacefrog Posts: 55
    Hiro Protagonist
    edited July 2018
    This is Unity 2017.4.6f1 latest LTS release. Honestly, that is in no way an "older" release.
    This is the exact error message ( thrown about a 100 times i guess )
    Graphics.CopyTexture with a region will not copy readable texture data for compressed formats (source texture format 50)

    But now i'm not sure that it's really the AVatarSDK any longer, as I justed tested again and it seems to throw the error even without a remote avatar in scene, so possibly it comes from the gazepointer texture or similar ... Initially i suspectedOvrAvatarTextureCopyManager.cs being the bad guy here, but now i have to investigate i bit deeper when i got time... sorry

    UPDATE: scratch my previous text. It is definitely the AvatarSDK. Even Oculus Rooms itself throws those Graphics.CopyTexture errors when entering/while loading avatars ....
  • Manu277Manu277 Posts: 4
    NerveGear
    Ross_Beef said:
    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)
    Hello Ross,
    since yesterday I am having the height problem. When jumping onto VR Y am way too high. I believe there are more people having this problem now. Is there a fix?
    Thank you!
  • cloud_canvascloud_canvas Posts: 67
    Hiro Protagonist
    edited November 2018
    spacefrog said:
    This is Unity 2017.4.6f1 latest LTS release. Honestly, that is in no way an "older" release.
    This is the exact error message ( thrown about a 100 times i guess )
    Graphics.CopyTexture with a region will not copy readable texture data for compressed formats (source texture format 50)

    But now i'm not sure that it's really the AVatarSDK any longer, as I justed tested again and it seems to throw the error even without a remote avatar in scene, so possibly it comes from the gazepointer texture or similar ... Initially i suspectedOvrAvatarTextureCopyManager.cs being the bad guy here, but now i have to investigate i bit deeper when i got time... sorry

    UPDATE: scratch my previous text. It is definitely the AvatarSDK. Even Oculus Rooms itself throws those Graphics.CopyTexture errors when entering/while loading avatars ....
    This is a really annoying bug and should be addressed to cut down on log bloat. It seems that specifically OvrAvatarMaterialManage.ProcessTexturesWithMips() has not been adjusted to accommodate for mobile Avatar SDK, because it's a consequence of setting the project Texture Compression to ASTC for Gear/Go.


    Samsung Galaxy S8 (Snapdragon 835), Gear VR (2017), Oculus Go (64GB), Unity 2018.3.14f1
  • r0b0sarur0b0saru Posts: 47 Oculus Start Member
    I am also seeing both these problems (wrong height for Gear VR Avatar and Log Graphcs.CopyTexture 100s of times). Anyone have a workaround?
  • Ross_BeefRoss_Beef Posts: 170 Oculus Staff
    edited November 2018
    Hey folks, following up. We’d previously been informed by our contact at Unity that this was only present in older versions and wouldn’t be an issue going forward, but i’m reopening the issue to get an update.

    I will say, we’ve run perf analysis on the texture log issue and it’s benign / won’t impact perf. 

    Re. Avatar height — looking into this now. We’d put in a fix previously. Can I confirm whether you’re just seeing this in SocialStarter vs. the Unity sample scenes that come packaged with the SDK itself?



  • cloud_canvascloud_canvas Posts: 67
    Hiro Protagonist
    Ross_Beef said:
    Hey folks, following up. We’d previously been informed by our contact at Unity that this was only present in older versions and wouldn’t be an issue going forward, but i’m reopening the issue to get an update.

    I will say, we’ve run perf analysis on the texture log issue and it’s benign / won’t impact perf.
    Great, thanks. I will try a build of my project on the latest 2018.2 and see if that makes a difference.
    Performance is not a concern here for me personally, it's that I'm trying to see other Debug messages while Avatars are spawning in and it's very annoying to have to deal with the spam blast of error messages.
    Samsung Galaxy S8 (Snapdragon 835), Gear VR (2017), Oculus Go (64GB), Unity 2018.3.14f1
  • cloud_canvascloud_canvas Posts: 67
    Hiro Protagonist
    Just tried a build with the latest 2018.2 (2018.2.17f1) and it's still present. Was just trying to determine what Unity means by "older versions" exactly.
    Samsung Galaxy S8 (Snapdragon 835), Gear VR (2017), Oculus Go (64GB), Unity 2018.3.14f1
  • Ross_BeefRoss_Beef Posts: 170 Oculus Staff
    Thanks @cloud_canvas - will follow up when we learn more.
  • Mosel3yMosel3y Posts: 9
    NerveGear
    @Ross_Beef
     This problem exists in Unreal, the avatars floating offset from the base on Android.
  • treeviewstudiostreeviewstudios Posts: 39
    Brain Burst
    I solved this by hacking the transform and just adding an offset of 1.65, make it child of a cube and raise it by one meter, the best a could so far.
Sign In or Register to comment.