Jump to content


Verified Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About jboss

  • Rank

Recent Profile Visitors

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

  1. Thanks @Dario What I want is that the grab occurs at the start of the scene. Some background: I have a tennis application that is used for training (not a game) and the athlete can choose from a number of drills. It starts with a selection scene where the athlete can select if they are right- or lefthanded and if they use the controller in their hand or the tracker on the racket. And then they select the drill they want to do. Typically during a practice session they will do several drills. Each drill is a separate Unity scene, so at the start of each scene the racket should be attached automatically to the correct controller or to the tracker and at the correct position and rotation. You're right, the stickyness itself is not related to the collision detection. But if I use the Transform option the collision is not detected. And I do need the stickyness to avoid that the racket is released right at the next frame after attaching, because the trigger is no longer pressed. This is what happened when I tried the SteamVR interaction system earlier this year (https://steamcommunity.com/app/250820/discussions/7/3148519094654061096/). I created a new topic for the Following Duration question:
  2. Is it possible to make the Following Duration shorter than 0.02 (seconds, I guess)? I see a remark in the code that it depends on the Update rate, so if I would set fixedDeltaTime to let's say 0.001 (1 ms), can I then get a following duration of 0.001 as well? ( I know I need to add both the [SteamVR] and [ViveInputUtility] prefabs in the scene and in both uncheck the 'Lock physics update rate to render frequency' option to avoid falling back to 90 fps at runtime). The remark I referred to is in RigidPose.SetRigidBodyVelocity(), which is called from GrabbableBase.OnGrabRigidBody(). I understand that you need some time to calculate the velocity and that more time means greater accuracy. But more time also means more lag; the attached object seems to be on an elastic band to the controller rather than securely fixed. So my ideal solution would be to specify this in frames rather than seconds. Then as a developer I can select how much accuracy I want by selecting the number of frames and I can influence the lag by setting the framerate (fixedDeltaTime). Higher framerate (lower fixedDeltaTime) means less lag.
  3. @Asish What issues did you need to solve? I am also getting around 60/70 Hz output. I added a timestamp in the log and there is 15 or 16 miliseconds between the entries in the csv. It makes no difference if I run the scene in the editor or in a build. I have set the fixed Timestep in Unity to 0.008. Also the gaze ray does not work (which looks logical, as it is only set in StartRecord, so that would mean only once, right?).
  4. @chengnay Here's what I did as a test: I started with the ColliderEvent example scene and imported my racket and ball. I found out that the behaviour I need is the one that is on the StickyBockableRigidbody, so I copied the Sticky Grabbable script component from that object to my tennis racket. Now when I move either the left controller or the right controller over the tennis racket and press the trigger the racket is attached to the controller. And it's sticky, so I can release the trigger. What I would like to happen is that I have my own script, RacketControlSelector which does something like this (pseudo-code); switch (player.dominantHand) { case Right: GrabRacketWithController(RIght); break; case Left: GrabRacketWithController(Left); break; } void GrabRacketWithController (controllerToUse) { // Call the functionality in StickyGrabbable that is executed when the user presses the trigger Is this OnGrabRigidBody()? // You could see it as a virtual trigger press by controllerToUse racket.GetCompnent<StickyGrabbable>().OnGrabWithController(controllerToUse); } The remark about the Following Duration is in RigidPose.SetRigidBodyVelocity(), which is called from GrabbableBase.OnGrabRigidBody()
  5. I am investigating to see if Vive Input Utility can replace NewtonVR for proper collision detection in my application. It looks like the Sticky Grabbable component works in a similar way and my tennis racket does not go right through the ball, so that's promising. But It only works when pressing a button. There is a large range of possible buttons to select from, but in my application I am using a script to attach the racket to the correct controller (depending on the player's dominant hand) or tracker if that is used. I don't want to bother the player with the action of picking up the racket in every drill they do. How can I achieve this? And another question (but maybe I should make a separate thread out of it): Is it possible to make the Following Duration shorter than 0.02 (seconds, I guess)? I see a remark in the code that it depends on the Update rate, so if I would set fixedDeltaTime to let's say 0.001 (1 ms), can I then get a following duration of 0.001 as well? ( I know I need to add both the [SteamVR] and [ViveInputUtility] prefabs in the scene and in both uncheck the 'Lock physics update rate to render frequency' option to avoid falling back to 90 fps at runtime) Thanks!
  6. Great, thanks! That worked for me as well. And I have to admit I did not check the Unity forum this time, only the Vive forum
  7. I am using a dropdown menu in my application and I noticed that it is very hard to select an option. It looks like the problem is that the selection is not registered when I am moving the controller while clicking. This happens very easily. The problem also occurs in the sample UGUI scene. The other UGUI items such as a toggle are a lot less sensitive and they are easy to select. I hope someone can help me get this fixed. Thanks!
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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!
  • Create New...