Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / AGKVR recenter view / feature request

Author
Message
Coilwinder
11
Years of Service
User Offline
Joined: 28th Feb 2013
Location: Norway
Posted: 21st Jul 2017 04:37 Edited at: 21st Jul 2017 04:41
I'm just dabbling a little bit in AGKVR, and one of the first things I try is to "unlock" the player direction from the HMD direction, and get a "recenter view" function. I'm modifying the "Castle Basic" demo to test this, but no success so far. I'm sure it's something simple I'm missing, but atm I am at a loss.

In addition to my other post in the AGKVR thread, I've now tried this:

Outside the do-loop I turn off player HMD heading lock


Inside the loop somewhere I have this:


Hoping to set the player's (world) Y-rotation to be like the HMD's at the instant of pressing left controller button 1. That didn't work. Well. Actually it did work as long as the button was pressed, but that's just like locking the rotation all the time (not what I wanted. Plus it flickered). As soon as the button was released, it was back to the old direction. Which from my (new) seated position is currently to the right (90 degrees) when pressing "forward" on the right controller. I thought the player's rotation was relative, so I found it odd it went back to the old afterwards.

Also, the AGKVR.ResetSeatedZeroPose() command don't seem to work (the tracking space isn't set in the demo, but it should be Seated by default), the VR position didn't reset after I moved (physically IRL) and then tried to reset the view. Unless the command is supposed to do something else (from the name ending ...Pose)?

So my feature request / suggestion is maybe to rename ResetSeatedZeroPose to ResetSeatedZeroPosition, and add a new command; ResetSeatedZeroRotation. Or perhaps forget about the "Seated" part, make it for any tracking space (Seated, Standing and maybe Room scale?): ResetPlayerZeroPosition and ResetPlayerZeroRotation?

( Unless there is an obvious way I've overlooked ofc. )


Btw, I had NO errors using AGKVR this time (I guess I waited a bit longer before restarting the demo), and even edited it in-VR from SteamVR's desktop view at times Great stuff ! Though I don't think I'll be editing it in VR normally, but it's nice to not have to take on/off the HMD all the time.
Apologies for any typos and strange grammar.
Ron Erickson
Moderator
21
Years of Service
User Offline
Joined: 6th Dec 2002
Location: Pittsburgh, PA, USA
Posted: 21st Jul 2017 11:38 Edited at: 21st Jul 2017 11:38
Hello CoilWinder,

I'll try to explain better later because I'm really busy at the moment. I did test your code and see what you are trying to do. Here is a solution for you:

Define a variable before the loop:


Then, inside the loop, do the following:



This will set the "offset" variable to the HMD's Y rotation angle whenever your button is pushed. This offset angle is your new heading direction and you set the Player's rotation to this value every loop iteration.

I hope this helps.

Also, I have not had the startup error happen recently either. I didn't do anything on my end, but a SteamVR update recently happened which may be responsible for the improvement!

Thanks!
Ron
a.k.a WOLF!
Coilwinder
11
Years of Service
User Offline
Joined: 28th Feb 2013
Location: Norway
Posted: 22nd Jul 2017 04:22
Ron Erickson,

Thanks for replying! While your solution helped, I'm afraid I couldn't quite get it to work. At least not the way I wanted. The recenter works, but the forward direction was now unaffected by how I turned with the left controller's thumb pad. So I could still turn using that, but not steer. It was also unaffected by the HMD direction, which is what I wanted ofc.

I tried some variations of your suggestion, but I can't seem to get to grips with this atm. ( I'm thinking it's something to do with the sequence in which AGKVR.RotatePlayerLocalY( valx ), AGKVR.SetPlayerRotation( 0, offset, 0 ), AGKVR.GetPlayerAngleY() and AGKVR.UpdatePlayer( ) is called? )

Here's a short code with some alternatives commented out:
( Probably not important, but I placed this block of code right before the "Control Player Movement based on Right Controller Joystick" in the "Castle Basic" demo, just FYI )



I also tried other stuff like keeping track of the player rotation with yet another variable instead of AGKVR.GetPlayerAngleY(), to no avail (so far). In case the AGKVR.GetPlayerAngleY() is not updated until a AGKVR.UpdatePlayer( ) is called (but as it's a loop anyway, I'm unsure how much it would affect the result). Sometimes the recenter would only work when the button was held down, only to revert back to the old wrong direction when it was released (usually with AGKVR.SetPlayerRotation( 0, offset, 0 ) inside the if - endif block active).

As I don't have an immediate-ish plan to use this, I think I'm putting this on hold for now (at least I think I will.. plus my brain feels a bit like mush now). But I'm pretty sure this could also be useful for others too btw. But I'm sure some solution will be found (or... made? ) eventually.

Thanks again for your help!
Apologies for any typos and strange grammar.
Ron Erickson
Moderator
21
Years of Service
User Offline
Joined: 6th Dec 2002
Location: Pittsburgh, PA, USA
Posted: 22nd Jul 2017 11:14
Hi CoilWinder,

I'm not in a position to test anything. I'm away for the next week. I think you can solve this by just having the left controller increase/decrease the "offset" variable instead of having it rotate the player directly with the RotateLocalY command.

Thanks!

Ron
a.k.a WOLF!
Coilwinder
11
Years of Service
User Offline
Joined: 28th Feb 2013
Location: Norway
Posted: 23rd Jul 2017 07:45
Hi again,

No worries, and thanks yet again for a quick answer! That pointed me in the right direction (I couldn't let this be just yet)! But I found I still have to rotate the player with the RotateLocalY command, as the SetPlayerRotation (seemingly) doesn't actually set the rotation, but rather the movement direction (so the movement direction would change, but not the view direction).

My current solution that works like I originally intended looks like this (the first 4 lines are part of "Castle Basic" demo)



And then I discover that I messed this up a bit, as I kind of mixed together "reset view" and "reset direction to HMD without locking it" ( sorry about that! ) More a thread title misnomer maybe. I'm happy this finally worked though, as the movement direction is free from the HMD direction (except when resetting it)


But I had to try to make a proper "reset view" also (where the view gets centered to the HMD, kind of like rotating the game world around you to some default direction, and position!). But that too didn't turn out as simple as I thought it would be (lol). Partly from the below issues, or (probably mostly) from my brain feeling like it will short-circuit from all this atm.


A couple of things / questions:

Is there (or supposed to be) any difference between AGKVR.GetHMDX() and AGKVR.GetPlayerX() ( and similar for Y and Z ) ? Because I can't see any. But intuitively I'd assume the GetHMDX() etc. stuff should be for the HMD's position in the tracking space (not game world space).

Similarly for GetHMDAngleY() and AGKVR.GetPlayerAngleY() (and X / Z). While I see a difference between them (probably from sitting in another direction than default among other things), the GetHMDAngleY() seems to relative to the game world space as well: I turn the player, then the GetHMDAngleY() value also changes even if I don't physically turn my head.

What does AGKVR.ResetSeatedZeroPose() do? I don't see any "reset" in VR position when I change my real (IRL) position, but it seems to be doing something as I see some stutter / flicker when it's activated for some time (holding the button down to activate it).

Is it an oversight (bug) that SetPlayerRotation(x,y,z) only set the (game world) movement direction? Come to think about it, it seems useful to have two different commands for movement direction and view direction relative to the game world.
Apologies for any typos and strange grammar.
Ron Erickson
Moderator
21
Years of Service
User Offline
Joined: 6th Dec 2002
Location: Pittsburgh, PA, USA
Posted: 28th Jul 2017 18:43
Hi CoilWinder,

Sorry for the delay in my reply. I was away on vacation and didn't have the opportunity to respond.

Quote: "Is there (or supposed to be) any difference between AGKVR.GetHMDX() and AGKVR.GetPlayerX() ( and similar for Y and Z ) ? Because I can't see any. But intuitively I'd assume the GetHMDX() etc. stuff should be for the HMD's position in the tracking space (not game world space)."


The simple answer is no. There is no difference. This may be a little complicated to explain, but I'll give it my best shot.
The actual tracking system for your hardware (not sure if you have a Rift, Vive or something else) has a "zero" position somewhere inside your tracking space. I'll call that position "origin". As you move inside your tracking space, OpenVR reports back the HMD and controller's offset distances from that origin. That seems simple enough, but it is actually complicated to work with that system when you add rotation into the mix. If the origin is used as the base of rotation, then as you rotate the origin, the HMD and controllers begin to orbit around it. It is very complicated and not-at-all intuitive to work with the standard origin/offset system that VR tracking systems use.
As a way to greatly simplify things, I have introduced the Player container in AGKVR. The "origin" point is not visible (or accessible) to the user at all. All interaction is done through the player container. The Player's position is global in your game world. It is the "ground" position directly underneath the HMD's position. You can move the player around using the player postion commands in AGKVR, or by simply walking around in your tracking space. Internally, AGKVR is working out the "origin" position because the HMD and controller positions are offsets from the origin. When you rotate the player, AGKVR repositions the origin by orbiting it around the player position. Again, this is all happening internally in AGKVR and invisible to you. So, again, the short answer is that the HMD's X/Z position will be exactly the same as the Player's position. The HMD's Y position will be the offset distance between the Player
s gound position and the HMD. All of that is true unless you introduce some sort of pitch or roll angle to the player's orientation. Then, the X/Z position will no longer be the same for the player and HMD position.

Quote: "Similarly for GetHMDAngleY() and AGKVR.GetPlayerAngleY() (and X / Z). While I see a difference between them (probably from sitting in another direction than default among other things), the GetHMDAngleY() seems to relative to the game world space as well: I turn the player, then the GetHMDAngleY() value also changes even if I don't physically turn my head."


Yes. If you turn the player, the HMD angle will also be modified. Think of the HMD as connected to the player. So, if you turn the player, the HMD goes with it.

Quote: "What does AGKVR.ResetSeatedZeroPose() do? I don't see any "reset" in VR position when I change my real (IRL) position, but it seems to be doing something as I see some stutter / flicker when it's activated for some time (holding the button down to activate it)."


Well, I suppose it doesn't really do anything externally. Internally it resets where the zero ( "origin" ) tracking position is at. But, since I've made all of that complication invisible to the user, I guess it probably doesn't do anything you can notice! That command was in there before I worked out all the details of the player container.

Quote: "Is it an oversight (bug) that SetPlayerRotation(x,y,z) only set the (game world) movement direction? Come to think about it, it seems useful to have two different commands for movement direction and view direction relative to the game world."


I will have to think about this one. The movement or heading direction is based on the player container orientation. Currently, the view direction is based on an offset (how is your head turned?) from the player container orientation. I think it would be really strange to try to disconnect the link between view direction and heading direction. If that link did not exist, then turning the player would not also turn the view. Is that what you are attempting to do?

Ron






a.k.a WOLF!
Coilwinder
11
Years of Service
User Offline
Joined: 28th Feb 2013
Location: Norway
Posted: 29th Jul 2017 13:30
Great stuff, thanks yet again for a detailed answer!

Quote: "I will have to think about this one. The movement or heading direction is based on the player container orientation. Currently, the view direction is based on an offset (how is your head turned?) from the player container orientation. I think it would be really strange to try to disconnect the link between view direction and heading direction. If that link did not exist, then turning the player would not also turn the view. Is that what you are attempting to do?
"


Not really trying to do anything about that at this point, I was just thinking SetPlayerRotation(x,y,z) seems to be either
1) missing a way of setting the view direction absolutely (game world space), since this command seems to only work for "movement direction" in absolute terms (I guess just turning the local coordinate system, but somehow without changing the view direction? At least it seems to be the case atm?).
2) 0r it should do both ("link between view direction and heading direction").

I guess it could be useful for example for skid-like movements? But I haven't thought this through either, basically it was just a remark/question about that command ( SetPlayerRotation(x,y,z) , since I also had to follow the rotation with RotatePlayerLocalY( valx ) in my above code snippet for resetting the direction to the unlocked HMD ).
Apologies for any typos and strange grammar.
Ron Erickson
Moderator
21
Years of Service
User Offline
Joined: 6th Dec 2002
Location: Pittsburgh, PA, USA
Posted: 29th Jul 2017 21:21
I could probably add a command that allows you to set the global view direction, which then automatically sets the player rotation based on the current offsets. Adding something like that and also adding a command to set the global view position could be useful for 3rd person views. I'll have to think about it a little more.
a.k.a WOLF!
Coilwinder
11
Years of Service
User Offline
Joined: 28th Feb 2013
Location: Norway
Posted: 30th Jul 2017 13:22 Edited at: 30th Jul 2017 13:25
I think that would be very useful! But I'm not sure I get what the adding offsets would do (other than making the view direction something else? If there are offsets ofc).

I've made a crude reset view in the modified Castle Basic demo posted below. I figured I should use another object to help with this. Please excuse the crude "spaceship" thing (attached file in case you want to test it). Just something I quickly carved out with Wings3D (I haven't got that texturing down yet either..). I have not looked into rotating the ship on it's Z or X axis yet, so I'll just post this for now (I want to look into it later though).

It's not perfect, there are some things I haven't sorted out yet (like parenting the ship to the player, and more). But in essence it's what I'm after for a reset view. But as you see you have to "follow" the player's rotation (with RotatePlayerLocalY( value ) even when setting it with SetPlayerRotation( x, y, z). For one I think this has the potential for some rounding errors if done a lot of times? I'm not sure if that will be an issue though. For another it would be easier with setting a global view direction (I think).

I'm using a HTC Vive btw.

Controls:

Left controller button 1: Reset player heading to HMD direction (should probably be used first, at the start)
Right controller button 1: Reset view (in this case place player in the cockpit)
WASD - controls the ship
Up / Down - arrows: Ship altitude

Then the rest as before in the original Castle Basic (left controller thumb pad = direction, right controller thumb pad = move player)

Apologies for any typos and strange grammar.

Attachments

Login to view attachments
Xaby
FPSC Reloaded TGC Backer
16
Years of Service
User Offline
Joined: 17th Apr 2007
Location: Berlin
Posted: 5th Aug 2017 14:12
Support for Nintendo Switch JoyCon(s)

Login to post a reply

Server time is: 2024-03-28 14:25:23
Your offset time is: 2024-03-28 14:25:23