Jump to content
 

jboss

Verified Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jboss

  • Rank
    Settler

Recent Profile Visitors

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

  1. I found out that the [ViveInputUtility] prefab has its own Lock Physics Update Rate flag. I need to set both to false to be able to modify the framerate. So the issue is solved, but I find it strange that VIU has its own flag and does not use the SteamVR flag.
  2. It's the Windows User Account Control. Rightclick on the Start menu icon and select Search. Then type UAC and should see something like (don't have the English Windows version) 'Change settings for User Account Control'. You can also get there through the Configuration screen --> User Accounts --> User Accounts. In the popup you need to move the slider all the way down. Yes, that is the 'Not recommended' setting.
  3. I got rid of the popup by disabling User Account Control completely. This is of course not what you want and also not what you want to tell your customers. On the other hand, one of the partners that I develop for does not report the issue, so it could be related to which account is used when installing the Vive software. Other threads also suggest that running it when looged in with the Windows administrator account works (which is the actual Administrator account, not a user account with Administrator properties, I guess, so also Run As Administrator will not help). I also noted before I disabled UAC that if I had allowed it once it woulld run without popup for subsequent checks. But as soon as I restarted the PC it needed permission again.
  4. The sample itself does not match my use case. It uses Focus() to check if the gaze hits a collider. I need to know the origin and direction of the gaze, even if the user is not looking at an object. I log that data and show it to the user afterwards to give them feedback on where they were looking at. And I traced the method calls and saw that Fccus() calls GetGazeRay(index, out ray) and then GetGazeRay(index, out origin, out direction) and that last one is the same as I am using. But I did learn in the meantime that I can use the LineRenderer with local space. If I do that and set the points to: 0,gazeOriginLocal 1,gazeOriginLoca+gazeDIrectionLocal*lengthOfRay I get a quite accurate gaze pointer. It still would be great to get world coordinates as well, since it requires converting the gazeDirectionLocal to a world verctor, using the head rotation, so if someone has a good method for that I would be very interested (Vector3.Cross is not the right one, I think, as that gives a vector perpendicular to two other vectors and we need something like an addition). And to get back to my original question, it looks like the asnwer is yes, system origin in the diagram is camera.transform.position in Unity.
  5. Ok, I thought I would be able to edit my previous post, but I can't seem to find that option. I did some more testing using VIU's ViveCameraRig and here's what I found. I am using the Combined ray and I use a LineRenderer to draw a line from the origin in the direction gazeDirectionLocal. gazeOriginLocal is fairly constant at (0.001, 0.007, -0.05). When I add that to camera.transform.position, it looks like the origin of the line is behind my eyes. If I look up or down the ray moves a lot more than when it would come from between my eyes. So I discarded the z-component of gazeOriginLocal. Then the ray was more natural, but still its origin seemed to be slightly too high. So I also discarded the y-component and now it looks quite ok. Since the x-component of gazeOriginLocal is very small I am inclined to say that camera.transform.position is in fact the position right between my eyes. That would mean that gazeOriginLocal has no added value, which sounds strange. Am I correct? I am now struggling with the rotation, since the direction is local. I notice that when I keep my head straight the line follows my eyes pretty ok. But when I tilt my head up or down, the line goes crazy, it seems to point in the vertically opposite direction (so the line goes up when I tilt my head down and look straight). I expect that it is relative to the hedaset, in other words relative the camera.transform.forward. Is that correct? It would really help if someone could give me some feedback or support on this. It is very hard to figure this out by myself, with the headset on. Whenever I try to look at what is happening I influence the gazedata of course.
  6. Thanks, I had found the getting started guide, but I must have missed the second link. And apologies for the late reaction, I did not get an email notification of your reaction.
  7. How does this diagram relate to Unity's SteamVR CameraRig or Vive Input Utility's ViveCameraRig? Is System Origin equivalent to the camera's transform.position? @Daniel_Y @Corvus @Jad @Hank_Li
  8. I must be missing it, but where can I find the SRanipal Unity API documentation? Couldn't find it in this thread, nor in the FAQ or in the downloaded zip file. Tried googling it, but I keep coming back to the same pages. Thanks!
  9. I am running into this problem both fom the SteamVR menu and from Unity. I did some troubleshooting, but haven't found a clear repeatable behaviour yet. I tried setting EyeCalibration.exe to run as admin always, but that does not seem to make a difference. Since I need to invoke it from Unity I can't set this at runtime (but I still have to, but I'll get to that). Also running this .exe manually before running my Unity application is not a good solution for my customers. I have the latest SteamVR and Sr and Tobii version installed. Here's what I did and the calibration behaviour. I ran these test with EyeCaliration not running as administrator. Testcase 1 Restart my PC Run calibration from inside SteamVR: got the UserAccountControl popup asking for permission for SRanipal. Clicked allow en got Initialization Failed in the calibration. Run it again from inside SteamVR and now it works fine, without UAC popup Run it once more from inside SteamVR and again runs fine. Quit SteamVR Restart SteamVR Run calibration from inside SteamVR and this time it failed, but without the UAC popup Run it again from inside SteamVR and it runs fine. Quit SteamVR Restart SteamVR Run calibration from inside SteamVR and this time it worked fine. Start my Unity application from the .exe file Run calibration from inside Unity exe and it worked fine Quit Unity application exe file Start my Unity application from the Unity editor Run calibration from inside Unity editor and it worked fine Testcase 2 Restart my PC Start my Unity application from the .exe file Run calibration from inside Unity application: got the UserAccountControl popup asking for permission for SRanipal. Clicked allow en got Initialization Failed in the calibration. Run it again from inside Unity application and now it works fine, without UAC popup Quit Unity application exe (this caused a SteamVR crash, don't now why) Start my Unity application from the Unity editor Run calibration from inside Unity editor: got the UserAccountControl popup asking for prermission. Clicked allow en got Initialization Failed in the calibration. Run it again from inside Unity editor and now I got Initialization Failed, but without UAC popup Run it once more from inside Unity editor and now it worked fine Quit Unity editor (SteamVR is still running) Run calibration from inside SteamVR and now it works fine, without UAC popup So, no real pattern. At one point I thought I crashed only the first time because of the UAC popup, but the tests show that that is not always true. I noticed that when I quit my application exe file (had to do this from the task manager because it was running fullscreen) that the EyeCalibrationDashboard.exe was running. I checked if that started at the same time as EyeCalibration.exe, but it seems not to. Hope someone can find a way tro solve this. Like I said, for customers this is not user-friendly. Thanks. @Corvus
  10. I'm not sure if this is the right place to ask this question (I posted it on the Unity site as well), but I'm a Vive developer and I need support, so that brought me to this forum 🙂 I am developing a baseball application for the HTC Vive using SteamVR. Since a lot of people have difficulty hitting the ball I wanted to try and change the fixed update rate to see if that made it better. So I made a script that allows me to change Time.fixedDeltaTime and display the value on screen. I know that SteamVR by default locks the fixed update rate to its display framerate (90 fps, Time.fixedDeltaTime=0.0111111), so I added the [SteamVR] prefab to my scene and set the checkbox that controls this locking to false. Made a build and tested it and it seems to work. I have the feeling I get better results at smaller fixedDeltaTime values. But then I tried it as well in the editor and there the confusion set in. In the editor the checkbox in [SteamVR] was set to true at runtime, even though I had set it to false at design time. I modified my script to show the value that the script sees and it showed False. So the editor does not represent the situation in code. Also, the fixedDeltaTime value in project settings is still 0.011111, even though my scene is running and on screen I see a different value (0.004, 250 fps). To make it even worse, I tried the same for my tennis app, which is still running on Unity 2017 (the baseball app is Unity 2019). And guess what, in Unity 2017 the editor checkbox is false and the project settings show the same fixedDeltaTime as on screen! So I hope someone can explain why this happens and reassure me that the values in the code are the correct ones. Thanks! @Jad
  11. I found the reason. In the selection Scene I am not using VIU. I have the regular SteamVR [CameraRig]. When I added the VivecameraRig it works. I guess this should be added to the documentation as pre-requisite. @chengnay
  12. @chengnay I tried it in my start-up scene. And just now as a test I tried it in two different scenes and there it works. I can see the pop-up menu and I can see the VIUBindingInterface(Clone) GameObject. In my selection scene that GameObject is not created. The selection scene has an on-screen canvas and in-world canvasses, but one of the other scenes as well. I tried a different key combination (Esc + B) to make sure the old one was not used for something else, but that also did not work in the selection scene.
  13. @Dario, unfortunately it does not work. Upgraded to the latest VIU (although in the asset store it said v1.10.7 and in the settings I see now that it says 1.10.6, even after restarting my project. Weird....). The settings are as shown in the link you sent. When I press right-shift and B nothing happens. No pop-up screen, no errors or warnings, just nothing. I tried the repair define symbols, just to see if that made a difference, but no effect. Is there a pre-requisite that is not mentioned in the description? I am using SteamVR 1.2.3, because when updating to 2.x earlier the open bindings button did not work. I just now tried the update again (to 2.5.0) and altough that button works I get a gazillion of compile errors because SteamVR_Controller and _ControllerManager and _TrackedObject no longer exist. Not only in my code but also in NewtonVR, which is no longer maintained. Great! And after this SteamVR update I don't see the VIU settings in the preferences anymore, so that seems to be broken now as well. Great! @chengnay
  14. Thanks for the explanation. You mention that the roles in SteamVR do not really matter. I am building a fullbody IK script based on the VIU and an old IKController script that works with animator.SetIkPosition() and SetIkRotation() and weights. I managed to get it working (had to do a little extra effort for the hip, since that is not an IK target in the animator), but currently I have the roles hardcoded (tracker1 is the hip, tracker2 is the left foot and tracker3 is the right foot). How is that order determined? It looks like it depends on the order in which you switch on the trackers, is that correct? And what happens if the headset goes to sleep when it is not used for a while? Or when I close my laptop and reopen it again? I remember from working with the SteamVR deviceIds directly that those actions could change the values of the deviceIds and thus mess up my IK. @chengnay
  15. Thanks for the link. That explains it well. I had never experienced this before, so I associated it with the Vive Input Utility, but I see now that it is a Unity issue. In my case it is pretty much every time I press the pad, sometimes it regsters once, sometimes 3 times, but mostly 2. But I have a fairly old laptop, so it may need to 'catch up' on frames frequently. @chengnay
×
×
  • Create New...