Jump to content

Dario

Administrators
  • Posts

    407
  • Joined

  • Last visited

Reputation

48 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We just updated the VIVE Cosmos Controller feature in the top most pinned topic. This supports the latest Unity updates.
  2. Generally, you wouldnt change materials or scripts in Packages (shared across projects - hence may be set to read-only) - but if you need to make an edit - it's best to copy the package into your local packages repo cache and then make edits there or copy what you need to edit and include it in your assets (avoiding script name scope issues).
  3. Make sure in the package manager you scroll down and select the latest 4.1.1 and not the default selected one. Also, select to download the samples for each package. Installing Essence first will auto install the other 2 package dependencies - then as before go to Project settings for each package to actually install the samples. Known issue: there are sample dependencies and those aren't auto detected so install all the samples.
  4. If you can share the apk privately with us (in a private message or email) that will help us see the issue first hand. Was this tested on Quest and Quest2? Also any relevant code snippets and/or settings would help as well.
  5. Are you using the Vive Cosmos Controllers feature for Unity? What worries me is that you mention "and other platforms" in which case have you checked on the Unity OpenXR forum? This is why I recommended the older .9 rather than a 1.0.0-pre..
  6. Ok got it: You meant: users e.g. when installing Viveport (users not publishing - but just using Viveport and only when never having installed SteamVR before). So you're referencing the embedded/bundled Steamvr with Viveport - even though that steamVR should be able to update itself (and set the default openxr as itself). So potentially the window is small for when a user who doesn't update would see the issue (a subset of a subset). In anycase now that it's clear, I'll have somone on the Viveport forum look into this issue.
  7. Hi @simeon For the Vive Cosmos OpenXR runtime you should be ok - for the SteamVR OpenXR runtime you need to have installed SteamVR (preferably the latest version) to get OpenXR support there. For both runtimes, from the SteamVR console or from the Vive console, you can specify which runtime is the default (on Windows it checks a registry setting). For SteamVR you can check which runtime is the default or set SteamVR as the default from the Developer Settings in the Steamvr console.
  8. You can select which OpenXR runtime you want to run in the drop down in Unity (or select default) - if using default which ever runtime is set will be used (can be set from within each runtime (ViveCosmos or SteamVR) best, Dario
  9. Ok I found the issue on my side. It was read only materials in Packages. They have to be copied into Assets and makes sure they aren't read-only.
  10. Hi @kjakubison We've had URP working since 3.2 (even 3.2 legacy before Unity XR plugin system) so this is unexpected. I tested several apps (and a new project) that uses URP (with Unity 2019.4.28) and updated to the latest Wave 4.1 and no problem Then I tested with all the latest versions: Wave 4.1, Unity 2020.3.14 - in a new proiect using the URP template but using a scene where I converted materials to URP... and I was able to repro. So I will confirm with older projects as well as the template scene soon. So what I see is that the build process is some how reverting the materials to non URP - the editor is showing the pink materials after the build - again this is after converting materials to URP before building. It looks to me so far as a Unity bug - I'm going to continue to isolate the issue and follow up here. I would suggest if you can revert to 2019 - or start going backwards from your current 2020.x version until it works would be the immediate recourse until we can isolate and report the issue.
  11. Please try: 1) in player settings select "both" under input system 2) use the 0.9... version of XRI
  12. No it doesn't techically replace it - it wraps it into a common interface - I'll be naswering question live in an hour at the VRTO conference
  13. And it's also working fine - I think what's tripping people up is a Unity bug: Also it's "verified" in 2020.3.11 and not .10 and it forces you to come off of the verified version of Input System with no way to go back - so I wouldn't call it "verified"
  14. It's there and moreover 1.2.2 is working - mke sure you don't move location of the tar ball....
  15. Hi @Laurent I am seeing it in 2020.3.11 What is tripping folks up is that you have to add it to the Project Settings -> Input System Package (possibly a Unity bug)
×
×
  • Create New...