Or you just skip adding the gui node. It doesn’t do anything. in TestOpenVR.
Well, the crosshair is a small test of the GUI stuff, which was in TestVRApplication. It should still be part of the test & not be skipped. Getting distortion working shouldn’t have to affect that piece (unless, of course, you are trying to make restructural changes at the same time). I have to head out for a bit, but I hope to get back to this later tonight. I’m trying to find compromise between VRApplication & the changes you made, so we can get back on the original track. I notice you are using fixed 512x512 frame buffer sizes, and not the OpenVR texture determination size available in “prepareCameraResolution”, part of the original VRAppState. I can get that fixed too. Together, we should be able to make a jump in progress here & I just want to make sure among all this debate, I really appreciate your help!
Well, it is WIP. I just wanted to check it in so that you had something to look at besides this thread. The 512 are coming straight from the jme test of offscreen rendering. I think it’s a big advantage that we can set a custom size and not be restricted to the actual camera (like we were originally in the oculus filters)
Edit: I actually don’t mind working on these bits on my own until it works. That may make things easier. I generally just want some advice for now.
Priority one should be to get distortion working, we can worry about architecture later 
Seriously. I think we can look at general abstraction once OpenVR is working. The current VRAppState expects too much to be useful as a generic appstate.
The longer we can keep OpenVR separate, the easier it will be to make it work.
Sorry for spamming the thread. But to get this thing on track:
I’m pretty sure that the java code is behaving OK, what data is coming is displayed correctly. There are printouts of the TexCoords coming from the JNA part and they’re all uniformly distributed. I think this is where the issue is. Do you have any control/oversight over what’s passed there? If it’s coming unmodified from the c+±core, I think we need to look outside of our part.
If you can try with a real HMD that would be a great start, I think.
[quote=“phr00t, post:95, topic:32413”]
Together, we should be able to make a jump in progress here & I just want to make sure among all this debate, I really appreciate your help![/quote]
We both want to see this work. You’ve done a tremendous amount of ground work on this plugin. Getting to where we are with the rendering in such a short time is much due to that. I basically just had to hook things up.
I’m still seeing just black on my end. Not sure why. Did you make any changes to shaders or something else that didn’t get checked in? It is getting late & I need to head to bed, so I can’t really look too much deeper into it now. I first was trying to fit things back into VRApplication just to get it to run without crashing, but I see you are initializing the hardware & compositor in the AppState, so the two need some more reconciliation than I was hoping for. It is possible I broke something when trying to merge things. It is a headache trying to work on just distortion, when you wrote initialization all over again in different classes…
I’ll look more into it tomorrow… feel free to tinker with what code you have. When either one of us gets something working, we’ll have to merge our methods (which might be a little messy now).
The reason you’re having problems is because I made a partial commit due to not wanting to break backwards-compatibility.
I just made a commit to mitigate this by removing the VRGuiNode dependency.
If you have a desperate urge to merge this WIP test case with the existing architecture before distortion is working, that is your headache. I’d much rather see what is required to get OpenVR to work at all with jMonkeyEngine before cramming additional features in there. But I’ve made that clear before.
Now that there is a working test case committed (and let me know if it isn’t working, ie TestOpenVR doesn’t display the image), let me know if you want to discuss how to get distortion working. Otherwise I’m taking a break from this. It’s already taking too much energy that I rather spend on constructive things.
I wasn’t expecting a partial commit, VRGuiNode being broken or a rewrite of initialization in a whole new class structure. We are taking a step forward in distortion progress, and 2 steps back elsewhere. I’d love to just work on distortion, but now I have to be concerned with restoring lost functionality & reconciling the library’s structure. It isn’t about cramming additional features in, it is maintaining existing features that should be modular and separate from the distortion piece.
As the library grows, we can’t create separate test cases for each new feature we want to implement. It is a headache to tie it back into the main project. We should have worked on distortion as a modularized part of the existing library.
I’m going to start some of that work now, so we can get back to an integrated distortion solution.
I moved your test case back into the existing library & revived the VRGuiNode stuff. I tried to keep everything you’ve done as whole, only moving out hardware & compositor initialization back into VRApplication. I moved the “observer” code out of the OpenVRAppState initialization, just incase it isn’t set yet (to avoid a null crash). I updated both test cases. Unfortunately, I don’t know why I’m still only seeing a black screen. I tried making the distortion meshes be rendered as solid white, and I can’t see them. I’m not sure what in the move is causing the problem… I’m using your OpenVRAppState & am not using the StereoCameraControl, as you did in your test case. You can see the commit here:
Hmm. I synced your changes and TestOpenVR worked for me.
I’m not using your jme build though so I had to comment out the start method of VRApplication. But I doubt that’s it. On the other hand, you could try removing the setSwapBuffer calls. I don’t think it’s necessary for OpenVR.
Edit: I also looked through the commit. I didn’t spot anything.
That was it! It was the setSwapBuffer call. Removed it, and I’m getting the two views. Thanks!
OK, big update:
New things working: VRGuiNode, FOV, camera projection, frustrum culling and camera resolution based on OpenVR requirements.
I moved some things out of OpenVRAppState & into VRApplication. I renamed the AppState to OpenVRCamControl (since that is all it is doing now). I plan on hiding the AppState from the developer & managing it from VRApplication for simplicity. Developers will only need to make their Application a VRApplication and set things like VRApplication.setObserver(player). I also want to avoid any problems with changes away from SimpleApplication to BaseApplication, as VRApplication can accommodate that. You can see how simple this can be by the improvements to TestOpenVR.java
No need to create a guiNode or AppState yourself.
@rickard & I had an offline discussion, and he may fork this library because he may want to approach the same problem from a different angle with a different structure. At the very least, we will continue to work together on the tricky bits.
About distortion: it is hard to tell if we are seeing none because we have no Rift hooked up (and are using a “null driver”), or if it because we are doing something wrong in the code. I plan to hook my Rift up as soon as possible to see if any other behavior happens.
I still need to get post processing filters cloned to both views, something that worked previously.
I have an oddity with the GUI when it is placed in a specific spot (which I think is around [0,0,0]). It appears as if the crosshair is somehow being rendered from within the distortion scene (that should only have the two distortion meshes). I checked the main viewport, and it only has the scene attached with the two distortion geometries… so how is the crosshair drawing over them both? Screenshot:
Note: only people who extend application directly will be affected by any of these changes. SimpleApplication will be deprecated for a long time before that.
So does it extend AbstractControl now… or is just misnamed?
That’s probably a good idea. I think rickard probably has his eye on this actually being incorporated into JME at some point.
Actually, I take this back. By extending VRApplication apps will be forced to use SimpleApplication or BaseApplication regardless of their original intent. So this will be an issue for VRApplication but would not be otherwise.
Great!
Yeah. It means there will be some code copying/merging, but it’ll make it easier for us to explore the different visions we have.
I didn’t see anything with my DK1 (it wasn’t even deteced by SteamVR it seems). That was with 0.4.3. Will be interesting to see if you get a different result.
I can take a look at how to solve that.
I’ll just honestly admit, I don’t have the time & resources to worry about jME3 incorporation specifics. I want VR development to be as simple as possible for me & my jME3 branch. Considering I’m using it for active, commercial products, I suspect many other developers will benefit from using the same tools. Making sure I am doing something “the official jME3 recommended way” is a thorn in my side. I know you guys, as engine developers, don’t have these same priorities. This is why it is probably best that we have separate repositories, as I have a separate jME3 repository.
I suspect all VR developers won’t care if they are using BaseApplication or SimpleApplication: they just want to make a VR application. I’m targeting those people, by hiding all those engine details from them (and myself). We just don’t have the time for that. Simplicity is king.
Perhaps we just need to agree to disagree here & move on to our separate repositories… we have lots of library work to do.
Thank you. I copy & pasted the code from the old StereoCameraControl into the AppState, like cloneProcessors(). The code that calls that function is currently commented out, because I think it is trying to grab filters from the distortion scene… but we won’t have filters in the distortion scene (which only has the 2 distortion meshes), correct?
Right. I think it might be pretty easy (not tested!). Since there are two viewports here as well (one for each eye camera), you should just have to add the post processors on them.
Edit: store the viewport in setupFrameBuffer
Thanks. I’ll get to looking at this more tomorrow. Any ideas on what is causing the big crosshair, spanning both viewports (that must mean it is leaking into the distortion scene, right)?
Just to test out the shader and distortion mesh, I “wiggled” the distorion coordinates manually:
Looks like it is working as expected.
The tricky thing about filters and post processors… a normal application will be adding them to the default viewPort. However, we don’t want them in the default viewport, but added to the 2 eye viewports. We might need another VRGuiNode solution, where it captures processors & filters trying to be added, and instead puts them into the eyes if VR is enabled, and into the main viewport otherwise.
1 Like
Fixed the crosshair appearing in the distortion scene. I had to check the Post Viewports & remove the GUI scene from it. Also, some other GUI fixes are included: