@phr00t said:
2) GUI distortion. Do we need it or not...? I'll PM @rickard with a link to my latest 4089 build, which has some GUI implemented that does have distortion. Curious how it looks on the DK1...
With the Oculus, you don’t have a naturally defined screen between the player’s eyes and the scene.
I.e. if the game does anything GUI-like, it’s like a sheet hanging in front of the player.
Hmm… think this: With the Oculus, if the player looks down, he’ll see his own character; with a GUI, what should he see?
My thinking is: If he still sees the GUI, he’ll think the GUI is moving around with his head. I’m not sure how actual Oculus users will experience this, but I’d expect that to be disorienting.
So the GUI will probably have to go to some in-scene vertical surface. Which means it will have distortion, else it won’t look right at the corners.
@toolforger said:
With the Oculus, you don't have a naturally defined screen between the player's eyes and the scene.
I.e. if the game does anything GUI-like, it's like a sheet hanging in front of the player.
Hmm... think this: With the Oculus, if the player looks down, he'll see his own character; with a GUI, what should he see?
My thinking is: If he still sees the GUI, he’ll think the GUI is moving around with his head. I’m not sure how actual Oculus users will experience this, but I’d expect that to be disorienting.
So the GUI will probably have to go to some in-scene vertical surface. Which means it will have distortion, else it won’t look right at the corners.
Well, there are two ways to go about it. The GUI could be projected infront of your “helmet”, so it would follow your head movements – like it does now. I think if the HUD is very minimal, and there is plenty of 3D geometry behind the HUD that does move with your head, it won’t be so disorienting.
The other option, as you mention, would be to put all of the GUI elements within the scene just infront of the camera. This would solve the distortion problem automatically, too. To make it as easy as possible to implement for end-users, the GUI node should somehow be replaced with a node that always floats infront of the camera. This way, developers could add and remove things from the GUI node and it would “just work”. All of those objects on the GUI would have to be changed from the Gui render bucket to Transparent (or translucent), though…
(For the in-scene GUI)
I think it should be possible to simply reuse the GUI root.
It is preconfigured with a parallel projection (I think) and a transform that maps GUI coordinates to screen coordinates in a straightforward way; I suspect you just need to rip these out and make the GUI root a child of the scene root.
It’s quite possibly that my view is overly simplistic-optimistic though…
I’m actually playing with the GUI-node in the scene thing right now. I will need to make a recenterGui method that will have to be called, that will place the gui infront of the view, where-ever you are currently looking (and make sure everything isn’t in parallel projection & scaled correctly).
I’m VERY CLOSE to having a working, completely re-designed GUI system for this library. It will put the GUI stuff in the scene – I’m adding a method to convert currently attached GUI things to scene-mode (basically just changes Gui bucket to Translucent bucket) & another method to center the Gui at the current look position. Working VERY WELL for 4089 so far, just need to clean some stuff up (e.g. we will always need to have a TranslucentRenderer pass done).
What revision did you check out? The current revision is v84. It is expected to add the jme3 libraries to run the test programs, but you should already have those added for your own project. What things did you need to comment out?
That might have something to do with the http loader that tries to download the scene remotely, perhaps? That should work in 3.0 stable, though… :
Thanks for the quick reply
Yes, the OculusRift initialisation is the first thing that is done in the main method. Must be something other that is wrong. I am running the tests in the oculusvr package in the test folder. I’m assuming they are correct since they are part of the project.
I did a clean checkout from google code. I’m pretty sure I’ve got the latest version. I do not have my own project yet. I am checking out your library to see if it works. It would save me the time from doing it myself. I was very happy to see that there were tests that I could use instead of spending time setting up my own project. I’m quite lazy so I appreciate when things just works Now I have to find out which libraries to add and it is a bit of a hassle. If you fix it might help others that will check out your projects as well. I’ll be checking it out again when I get the DK2 in a couple of months
Finally got a chance to have a poke around again. Lots of work since last time I looked!
@phr00t said:4) That might have something to do with the http loader that tries to download the scene remotely, perhaps? That should work in 3.0 stable, though... :
The 3.0 stable install that I have doesn't have a postFilter method in the Filter class (which OculusFilter tries to override).
The stable install also doesn’t ship with jMonkeyEngine3.jar (which contains the test data packages). I was able to yoink that and get the tests running with the updated engine libraries (had to remove all the) from the latest nightly build.
OK, big update. Completely re-designed the GUI system. GUI elements now are part of the scene, which removes the need for another pass to render GUI elements. It also takes care of distortion, as it gets distorted along with everything else in the scene. It also makes GUI elements that are rendered beyond geometry in the scene get occluded as you would expect.
There are two modes to how it can work – automatic and manual positioning. Manual positioning is handled by calling “positionGui”, which will place it at the center of the player’s view. As the player looks around and moves, the GUI won’t follow the view (like if it was standing on its own). Automatic positioning will keep it floating infront of the view, like if it was projected inside a helmet of the player.
For more details, and how to set its distance from the view, read the wiki that I updated:
Small GUI elements, centered on the screen, works the best. I haven’t really tested it with really big stuff & I’m not sure how well it works with a Rift, since I don’t have one yet However, in testing by crossing my eyes, it looks good.
I tried to get everything centered on the screen as best as possible at different resolutions. I’d like others to test to see how well it looks…
I wanted to make another positioning mode, that would keep the GUI elements centered on the X/Z plane, but not on the Y plane. That way, when a player looked side to side, the GUI would follow the view. However, when looking up and down, the GUI elements wouldn’t follow the view – this would act like the GUI was a “cockpit” that turned with the player left and right, but not up and down. This would also allow for the map effect in DreadHalls. I couldn’t get it to work, though… I’m hoping @rickard or someone else can help here…
@rickard said:
I've created a plugin, following the steps in the wiki. I have no idea whether it works, or not, though.
Can i get commit access to the plugin repo?
Added it but it gives this build error:
/var/lib/hudson/jobs/jmp-contributions/workspace/netbeans/harness/common.xml:459: Exception reading blurb from /var/lib/hudson/googlecode/jmonkeyengine-oculus-rift/license.txt
Would it be possible to also configure the plugin to work with jayfella’s github submission process (I think it would be pretty easy) so that they can get more plugins to test with?
Hello there, firstly I would like to thank you on your wonderful efforts in this project.
I just updated to the latest .jar files. Unfortunately, an error came out. It says, “an eye is already rendering”. I didn’t understand what went wrong.
Here I’ll include the error log. Please take a look at it.
Jul 19, 2014 4:27:45 PM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
java.lang.IllegalStateException: an eye is already rendering
at com.google.common.base.Preconditions.checkState(Preconditions.java:176)
at com.oculusvr.capi.Hmd.beginEyeRender(Hmd.java:148)
at oculusvr.post.OculusFilter.postFrame(OculusFilter.java:92)
at com.jme3.post.FilterPostProcessor.renderFilterChain(FilterPostProcessor.java:258)
at com.jme3.post.FilterPostProcessor.postFrame(FilterPostProcessor.java:293)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:987)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1035)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Unknown Source)
AL lib: (EE) alc_cleanup: 1 device not closed
Exception: java.lang.Error thrown from the UncaughtExceptionHandler in thread “LWJGL Renderer Thread”
However, in testing by crossing my eyes, it looks good.