Extended Move class and mounting vehicles in Oculus Rift
by Paul Weston · in Torque 3D Professional · 12/12/2013 (7:08 pm) · 10 replies
Hey all,
Have been playing with the Oculus Rift development kit in Torque 3D MIT 3.0 (w/AFX 2.0), and have run into an issue.
At first we had not included Extended Move class, and when I played our game with the Rift I was able to mount a vehicle and fly around no problem... But there was no head tracking with the Rift in the game... So I regenerated projects with the Extended Move class enabled and recompiled the engine.
Now head tracking works (awesome by the way), but the second we mount a vehicle or a turret the game crashes. Nothing notable in the console other than it was at the point of mounting.
Is there some reason the Extended Move class could be conflicting with mounting vehicles?
What is funny is that this does not occur when I play the game with Rift disabled. Mounting vehicles works fine.
Stumped at this end, any ideas would be appreciated.
Thanks
P
Have been playing with the Oculus Rift development kit in Torque 3D MIT 3.0 (w/AFX 2.0), and have run into an issue.
At first we had not included Extended Move class, and when I played our game with the Rift I was able to mount a vehicle and fly around no problem... But there was no head tracking with the Rift in the game... So I regenerated projects with the Extended Move class enabled and recompiled the engine.
Now head tracking works (awesome by the way), but the second we mount a vehicle or a turret the game crashes. Nothing notable in the console other than it was at the point of mounting.
Is there some reason the Extended Move class could be conflicting with mounting vehicles?
What is funny is that this does not occur when I play the game with Rift disabled. Mounting vehicles works fine.
Stumped at this end, any ideas would be appreciated.
Thanks
P
About the author
Programming team lead, Gambit Realm development studio. Based in Ottawa, ON, Canada.
#2
What he is talking about is int he Project Manager you need to select the Extended Move Class to allow input from Oculus Rift, Razer Hydra and Leap Motion devices.
The side effect of this is that mounting a Vehicle crashes Torque but no errors are shown in the logs (You can set a vehicle as the player fine though)
As for GUI in the rift it doesn't work well at all and isn't useable atm the best way to have GUI would be to build one into the 3d environment.
I had the idea of just displaying a 2D gui on a 3d object and changing the material based on selections then making that disappear but i haven't had much time to even look into that sorta thing.
I have been able to get a GUI to show up properly but that was by creating the exact same gui twice for both screens but even if you do that the mouse doesn't work as it only shows up on one screen or the other so you need to create a better system.
One option is to purchase the Awesomium browser plugin and apply the texture to your arm or even a model that you show infront of the user then you use your head and left mouse click to select the item and that can be html built gui then it can send commands back and forth so you can grab what items you have from T3D and it will populate the HTML with what you have and can send the command back to T3D to use said item that is another option.
12/15/2013 (3:13 pm)
I have this same issue.What he is talking about is int he Project Manager you need to select the Extended Move Class to allow input from Oculus Rift, Razer Hydra and Leap Motion devices.
The side effect of this is that mounting a Vehicle crashes Torque but no errors are shown in the logs (You can set a vehicle as the player fine though)
As for GUI in the rift it doesn't work well at all and isn't useable atm the best way to have GUI would be to build one into the 3d environment.
I had the idea of just displaying a 2D gui on a 3d object and changing the material based on selections then making that disappear but i haven't had much time to even look into that sorta thing.
I have been able to get a GUI to show up properly but that was by creating the exact same gui twice for both screens but even if you do that the mouse doesn't work as it only shows up on one screen or the other so you need to create a better system.
One option is to purchase the Awesomium browser plugin and apply the texture to your arm or even a model that you show infront of the user then you use your head and left mouse click to select the item and that can be html built gui then it can send commands back and forth so you can grab what items you have from T3D and it will populate the HTML with what you have and can send the command back to T3D to use said item that is another option.
#3
OK so I'm not crazy haha :) I thought it might have been a conflict with AFX or another of our resources, so am glad it is happening to somebody else as well.
So, can we infer that the crash has something to do with assigning the player control of a vehicle when the Oculus is in use, because the head tracking is somehow confusing it since one cannot look around when mounted in a vehicle?
As I mentioned, when I disable the Oculus I can hop into a vehicle and pilot it just fine, using the same EXE with Extended Move compiled in... So the actual Extended Move class doesn't seem to affect Torque with this crash until the Oculus is actually in use.
We have Awesomium compiled in as well, and it has worked great as a replacement for the QT webkit - lighter footprint and the javascript-to-torquescript is very useful. We're experimenting with various ways of converting our popup GUIs into web pages, so that what was once controlled in GUIs can be controlled right in the environment when using the Rift... I'm confident over time we can find some cool solutions to those GUI issues, I'm not too worried about that.
However, it would be nice to at least get the popup screen messages (the AFX ones we use are nice) mirroring in the Rift so text can be read with the Oculus on... I have been testing various demos and games with the Rift and Team Fortress 2 handles things pretty well - the text is mirrored and so are the menu buttons, etc, so the game it pretty usable with the Rift on. Would like to move towards a solution like that as we learn more.
Anyhow, good to have an ally here NiN-NiN... Let's keep each other updated on our progress, I'm sure the community can learn a lot from what we figure out over the next while as it concerns the Rift.
Cheers
P
12/16/2013 (6:27 am)
Exactly!OK so I'm not crazy haha :) I thought it might have been a conflict with AFX or another of our resources, so am glad it is happening to somebody else as well.
So, can we infer that the crash has something to do with assigning the player control of a vehicle when the Oculus is in use, because the head tracking is somehow confusing it since one cannot look around when mounted in a vehicle?
As I mentioned, when I disable the Oculus I can hop into a vehicle and pilot it just fine, using the same EXE with Extended Move compiled in... So the actual Extended Move class doesn't seem to affect Torque with this crash until the Oculus is actually in use.
We have Awesomium compiled in as well, and it has worked great as a replacement for the QT webkit - lighter footprint and the javascript-to-torquescript is very useful. We're experimenting with various ways of converting our popup GUIs into web pages, so that what was once controlled in GUIs can be controlled right in the environment when using the Rift... I'm confident over time we can find some cool solutions to those GUI issues, I'm not too worried about that.
However, it would be nice to at least get the popup screen messages (the AFX ones we use are nice) mirroring in the Rift so text can be read with the Oculus on... I have been testing various demos and games with the Rift and Team Fortress 2 handles things pretty well - the text is mirrored and so are the menu buttons, etc, so the game it pretty usable with the Rift on. Would like to move towards a solution like that as we learn more.
Anyhow, good to have an ally here NiN-NiN... Let's keep each other updated on our progress, I'm sure the community can learn a lot from what we figure out over the next while as it concerns the Rift.
Cheers
P
#4
When it crashes for me I can see the player mounted and it's in 3rd person view but it seems like it crashes when it comes to the camera.
I did try a few script changes for camera but that didn't work but it possibly might have something to do with the scripting specific for vehicle it may have something specific that is in the player class for the rift that's not in the vehicle class but this is only a guess I'm still rather new.
I'm not at home atm but could it possible be bindings for X and Y axis for vehicle in the default bindings? Possible may need to check the vehicle class in scrips/server I think it is?
That is interesting I've been playing with Awesomium as well but I may have botched my compile as it seems I can't change the webpages I change them in script but they stay the same as the original Awesomium demo I used.
I did get gui to work ok using standard GUI look wise but it was very hard trying to have the screen show where i've placed it to make sure it was in proper positions. The other issue is the mouse only shows in one side of the rift not both so it's a ghost effect which annoyed my eyes after a short while.
If all the AFX windows are individual GUI pages then you can copy and paste it next to each other and move it to the other side but you kinda need to go into the game to see if it's in the right spot it's annoying to fiddle with but then you have things like sliders not sliding for both gui elements etc.
Will do i'm hoping to get some time soon to try some GUI options as I need them for an app i'm making as well.
Hopefully someone can help with the vehicle code and see where this bug is :)
12/16/2013 (5:31 pm)
Quote:So, can we infer that the crash has something to do with assigning the player control of a vehicle when the Oculus is in use, because the head tracking is somehow confusing it since one cannot look around when mounted in a vehicle?
When it crashes for me I can see the player mounted and it's in 3rd person view but it seems like it crashes when it comes to the camera.
I did try a few script changes for camera but that didn't work but it possibly might have something to do with the scripting specific for vehicle it may have something specific that is in the player class for the rift that's not in the vehicle class but this is only a guess I'm still rather new.
I'm not at home atm but could it possible be bindings for X and Y axis for vehicle in the default bindings? Possible may need to check the vehicle class in scrips/server I think it is?
Quote:We have Awesomium compiled in as well, and it has worked great as a replacement for the QT webkit - lighter footprint and the javascript-to-torquescript is very useful. We're experimenting with various ways of converting our popup GUIs into web pages, so that what was once controlled in GUIs can be controlled right in the environment when using the Rift... I'm confident over time we can find some cool solutions to those GUI issues, I'm not too worried about that.
That is interesting I've been playing with Awesomium as well but I may have botched my compile as it seems I can't change the webpages I change them in script but they stay the same as the original Awesomium demo I used.
I did get gui to work ok using standard GUI look wise but it was very hard trying to have the screen show where i've placed it to make sure it was in proper positions. The other issue is the mouse only shows in one side of the rift not both so it's a ghost effect which annoyed my eyes after a short while.
If all the AFX windows are individual GUI pages then you can copy and paste it next to each other and move it to the other side but you kinda need to go into the game to see if it's in the right spot it's annoying to fiddle with but then you have things like sliders not sliding for both gui elements etc.
Quote:Anyhow, good to have an ally here NiN-NiN... Let's keep each other updated on our progress, I'm sure the community can learn a lot from what we figure out over the next while as it concerns the Rift.
Will do i'm hoping to get some time soon to try some GUI options as I need them for an app i'm making as well.
Hopefully someone can help with the vehicle code and see where this bug is :)
#5
I know the Oculus stuff is all new and many users out there have no clue about it... However in a couple of years this technology will be more mainstream, and we're just trying to get a handle on best practices in terms of handling GUIs and gameplay through this new interface.
If we can beat this mounting issue, our game is close to being completely playable in the Rift, once I convert all my existing clickable objects into Awesomium web controls...
Here is a tease of everything looking good in the Rift so far :)
12/17/2013 (6:55 am)
Really happy to have somebody else who knows what I'm talking about :)I know the Oculus stuff is all new and many users out there have no clue about it... However in a couple of years this technology will be more mainstream, and we're just trying to get a handle on best practices in terms of handling GUIs and gameplay through this new interface.
If we can beat this mounting issue, our game is close to being completely playable in the Rift, once I convert all my existing clickable objects into Awesomium web controls...
Here is a tease of everything looking good in the Rift so far :)
#6
Since the Rift seems to correctly mirror the Awesomium objects in stereo, perhaps it will do the same with GUIs attached to shapes. I think it was a resource Tom Spillman worked on, I will check the archives to see what I can find.
12/17/2013 (6:59 am)
I also seem to remember there is a resource to attach GUIs to shapes - in the same way Awesomium or QT webkit do... Therefore maybe there is a way to simply take existing game popup GUIs, and render them to in-game consoles. Since the Rift seems to correctly mirror the Awesomium objects in stereo, perhaps it will do the same with GUIs attached to shapes. I think it was a resource Tom Spillman worked on, I will check the archives to see what I can find.
#7
I did notice that on the last picture at the front of the enterprise it seems the glow issue is still there between the different eyes.
Are you using 3.5? the glow issue has been fixed.
I think I remember a resource I just checked but don't have it in my list of favs I will see if I can find it as well.
12/17/2013 (2:57 pm)
Those picture look fantastic :) I can't wait to check that out in the rift :DI did notice that on the last picture at the front of the enterprise it seems the glow issue is still there between the different eyes.
Are you using 3.5? the glow issue has been fixed.
I think I remember a resource I just checked but don't have it in my list of favs I will see if I can find it as well.
#8
Is there a way to find which specific files were modified in 3.5 to fix that glow? I have noticed it in the Rift when walking around and it is a bit annoying. Kind of funny though in the Enterprise, because it reminds me of JJ Abrams' excessive use of lens flares in the new movies haha :)
If I knew the specific changes, I'd be more inclined to patch my existing 3.0 code rather than start again with 3.5 (which may not even be very AFX 2.0 compatible).
Thanks
12/18/2013 (6:06 am)
We're using 3.0 because that's the version Jeff Faust has built the new AFX 2.0 against... We have so many resources in our custom code base that every time I want to upgrade the engine I have to paste in all our changes into several dozen files, so I'm hesitant to move up to 3.5.Is there a way to find which specific files were modified in 3.5 to fix that glow? I have noticed it in the Rift when walking around and it is a bit annoying. Kind of funny though in the Enterprise, because it reminds me of JJ Abrams' excessive use of lens flares in the new movies haha :)
If I knew the specific changes, I'd be more inclined to patch my existing 3.0 code rather than start again with 3.5 (which may not even be very AFX 2.0 compatible).
Thanks
#9
12/19/2013 (11:13 am)
I got the rift working while mounted to a cheetah and put it up on GitHub at www.garagegames.com/community/forums/viewthread/135827. It's built against the current development branch (3.5), but if it works for you, you should be able to view the changes on GitHub and add to your 3.0 build depending on how extensively you've modified Vehicle.
#10
www.garagegames.com/community/blogs/view/22570
01/28/2014 (9:37 am)
Just posted a blog about our trials and tribulations with integrating the Oculus Rift, check it out:www.garagegames.com/community/blogs/view/22570
Torque Owner DreamPharaoh
Gods and Nemesis
What do you mean by extended move class? Are you talking about moving shapes that your player can walk freely on like a train or boat? Additionally, I was wondering how the gui system works for you. I know the Oculus Rift version of Torque had an issue with displaying gui text. This will be a major set back for me since I am developing an RPG.