Jump to content

Alex_HTC

Moderators
  • Posts

    291
  • Joined

  • Last visited

Posts posted by Alex_HTC

  1. @OneBonsai

    Howdy!

    I think i'm missing the question here -- if i understand correctly, you're overriding the output of /user/head and then getting an unexpected head position in the headset. This sounds like the desired output. I'm not sure what causes the lag that required one to use such a workaround though, so I can't comment fully on the wisdom of trying to use the head as an output position.  

    Trying to interpret this another way - if you're using a tracker as a proxy for the head position, then the geometry/orientation of the puck would be different than that of an actual headset. "forward"/etc might not be what you would expect and would require some fiddling. 

  2. @ste-phil
    Hi Philipp!

    Creating a C++ application using the open source loader is something that has been done by a few folks, so I'm a little confused as to what the error may be.

    Using the hello_xr app that's a part of https://github.com/KhronosGroup/OpenXR-SDK-Source seems to work just fine for me, does that also work for you?

    What other functionality other than what is in hello_xr sample above are you using? Can you fork and create a branch with these changes?

    Thanks,
    Alex

  3. @PSCR

    Hello,

    Sorry to hear you're having an issue with marker based scene alignment. 

    The marker may not be recognized in this case, which can be something like not being enough contrast to pick up the image. Printing out the marker and having appropriate lighting would be important to ensure that the marker is picked up. This is a professional way of saying: when i prototype things on my computer or phone screen, my coworkers have to remind me to print it out to avoid errors (or at least change the contrast setting on the screen, but this sometimes isn't enough).

    The bit that threw me from this specific message was "Unable to identify the map, please check if the procedure and location is correct", which to me suggests that the marker_list.json file does not have this marker associated with the map

  4. @RicePort
    lowmemory killer starts with the background apps then kills the foreground if there still is not enough memory, which is what it did in the logs

    RE openxr, https://github.com/ViveSoftware/VIVE-OpenXR/ 2.0.0 is the latest. When switching you might have been seeing some cached AndroidManifest.xml files causing conflict between versions. It's useful information usually, but it does look like a memory issue that the profiler and memory profiler would expose quickly.

  5. @RicePort

    Howdy, 

    Sorry to hear that you're experiencing crashes.

    There are a few open questions about the project and logfiles

    1) What sdk and version are you using - wave or openxr, and have you tried updating to the latest versions of the corresponding packages 
    2) There seems to be some issue with "com.HTC.MotionTracker.MotionTrackerDataHandler.UpdateData" and i'm not sure I'm seeing where that might come from
    3) Most likely is that the memory grew too large in the scene change based on "2023-11-07 09:53:35.662 836-836/? E/lowmemorykiller: Kill 'com.my.test.app' (19898), uid 10162, oom_adj 0 to free 1726804kB"

    There are more ways to accidentally use a ton of memory in the new rendering pipelines, so maybe check this out in your app with the memory profiler https://docs.unity3d.com/Manual/ProfilerMemory.html

  6. @PeteLTS

    I agree that the messaging can be better around this change.

    The rationale is a little unclear, but from my understanding there were some external factors outside of our control and relatively sudden.

    As Dev pointed out, the difference is really just a different endpoint - using urls that point to github rather than a upm server.

    "com.htc.upm.vive.openxr": "https://github.com/ViveSoftware/VIVE-OpenXR.git?path=/com.htc.upm.vive.openxr#versions/2.0.0",

    Versus another one

    There are features that github offers that artifact repositories do not, and we're excited to engage with our community.

    We appreciate your patience and understanding.

    -Alex

  7. CT's suggestions is spot on. Offsetting channels is the #1 defense - i tend to work in wifi-heavy areas and it makes a big difference. Even more so if you have multiple routers in the same room.

    I also found some additional success with using routers that support multiple bands to help prevent channel saturation in more dynamic environments - where the signals change rapidly. Some routers also have configuration to have change bands dynamically as well, so check your router admin page

  8. @MCA31

    Throwing out some ideas --
    1) can you try using the controller sample scene (you can import it by going to the openxr samples project and importing the samples under the "samples" tab). This should show a debug dump of different key presses
    2) Maybe try updating to the openxr 2.x package here https://developer.vive.com/resources/openxr/unity/tutorials/how-to-install-vive-openxr-plugin/ There are regular fixes and updates to different versions of unity, ie for 2022 project. One thing to note in both of these, is that you may need to import our mappings and ensure they 

    3) could try a 2021 lts to see if the same version of openxr is not reasonable
    4) Try looking at the xr interaction debugger 


     

  9. @PeteLTSHowdy Pete!  

    We had a few changes at a high level:
    1) our onboarding flow suggests using the installer that @Dev1234 suggested depending on the package you're using openxr, wave, or legacy openxr pc/aio as described in the instructions linked by dev https://developer.vive.com/resources/openxr/unity/tutorials/how-to-install-vive-openxr-plugin/
    2) We combined our openxr pc and AIO packages into one in the openxr 2.x series. And since we're on github, you can check the diffs and releases on the releases page https://github.com/ViveSoftware/VIVE-OpenXR/releases
    3) AIO openxr 1.x packages are still available at https://github.com/ViveSoftware/VIVE-OpenXR-AIO

    Definitely don't hesitate to reach out with any other questions!

    Thanks
    Alex
     

  10. @jiunlinCan you put the RT issue on your ray-dar. or do you have a response already. That the ray tracing seems to clobber the background a bit in some circumstances.

    @Paolo Leoncini 1) good to hear that you found the workaround useful! 2) Related to RT - Interesting! I am unaware of any deferred rendering issues, but with my mental model of things the type of ghosting shown in the second video would definitely happen with ray tracing for several reasons, most importantly would be opaque pixels being put in front of the background image.

    I'm not the authority here, but to some extent this is what i would expect ray tracing to do - put non-transparent stuff on top of the background. Of course RT is a big field, but i would expect both lighting passes on the pc and content rendering using ray tracing to have similar results. I'm sure there's some way to maybe get them to play well together with some alpha in the lighting colors -- just a wild guess from me to try to better understand in the meantime.

  11. @Paolo Leoncini

    Howdy Paolo!

    I understand you've encountered an issue with video passthrough mapping on semi-transparent surfaces in VBS, and you're looking for a way to achieve a pure MR passthrough mapping on your 3D scene surfaces. Let's tackle your concerns:

    Color and Alpha Settings:
    1. It appears that color is utilized even when the alpha flag is set to 0. While I'm not certain about the 'best' settings, many find either pure white or gray to be preferable.

    Unreal-Specific Alpha Issues:
    2. There might be some unreal-specific alpha issues, which I believe have been addressed in the latest version of vbs. 

     

    Best Practices:
    - **General**: Tutorial for MR Contents
    - **Unreal**:
       - [Unreal Passthrough Underlay] for a basic understanding.
       - [Unreal Passthrough Quality Performance] for tuning performance, scale, and position.
    - **Unity**:
       - **Wave SDK**: [Unity XR Passthrough]
       - **OpenXR**: [Unity Passthrough with OpenXR]

    Contextual Usage of MR:
    Ensure the tracking mode is not set to 'instant mode'; room-scale tracking is preferred. Follow the MR room setup in the settings, then explore the Scene Perception SDK as specified [here], and the 'scene perception' demo for a hands-on understanding.

    Occlusion Based on Mesh Scans:
    Using scene perception, obtain a visual mesh `WVR_SceneMeshType.WVR_SceneMeshType_VisualMesh` as specified [here], and employ layers or other tests to cull virtual objects for occlusion.

    MR Passthrough Mapping in Chroma-Key Style:
    We have some helpers for this in unity. An example project is available  https://github.com/ViveSoftware/Jelbee-MR-Demo. It comprises a component to select an area and lower-level APIs for more customized use-cases. Typically, these are used in reference to real-world objects using anchors as specified [here], or for 'HUD' style setups. You can blend the two by culling/occluding objects in the real world based on the position of the visual mesh provided by the above SDKs.

    I hope these resources and explanations address your concerns and help you move forward with your project!

    • Like 1
  12. 9 hours ago, ruiying said:

    Ran into the same issue. Any update?

    @ruiying
    Which problem above? Here are some of the problems/solutions suggested
    1) signing issue with creating an apk
    This appears to be an issue with the way that unity looks for the keystore file. A user reported that deleting that file allowed it to work again. This seems to be an issue with unity that can be resolved by deleting (or moving) the "D:\Android\Home\.android\debug.keystore" file, so it can create one that it recognizes it. I linked to a few threads that point this out
    2) Confusion about sdk and/or input
    try building against a known-good branch like the openxr_hand_tracking branch here https://github.com/ViveDeveloperRelations/MinimalRepo/tree/openxr_hand_tracking
    3)Trying to load multiple scenes 
    -These will all have different camera rigs and likely cause issues. if you want to try our samples as-given then use one scene at a time.
    -It's worth noting that unity only loads one scene at a time if multiple are selected, so you'd need to de-select one and/or try to load scenes at runtime with your own code for that.
    4) Occlusion on one eye - this can happen for a variety of reasons, including you being too close to the UI. There was not enough detail to tell what was being referred to.

×
×
  • Create New...