I finally got my single room experiment working! I'm not sure what, but something was wrong with my procedural texture generation. When I switch to png textures it started working :)
todo:
The mouse cursor gets stolen at startup, as described here:
http://forum.lwjgl.org/index.php?topic=5572.msg29683#msg29683 (http://forum.lwjgl.org/index.php?topic=5572.msg29683#msg29683)
I get ~112fps but it is not steady at that rate.
There is some judder when looking around, but that might be from the SDK tracking head movement.
Anyway I'm just pleased to have something simple finally running. I've put my code up on github if anyone is interested. You might need to change the monitor number, since it's quite tricky to work out which monitor is the rift. enjoy.
I want to port this over to OpenGL ES, but it's not clear from the roadmap if OpenGL ES binding is part of the 3.0 3.1 release?
Related to that, is it going to be possible using openGL ES to target both desktop and mobile? I dont have much experience with ES, and I'm wondering if it is even supported on the desktop?
Otherwise I'm going to port my examples over to 'modern OpenGL' is there a 'best practice' example for using shaders with LWJGL3?
Quote from: BrickFarmer on March 09, 2015, 09:49:40I want to port this over to OpenGL ES, but it's not clear from the roadmap if OpenGL ES binding is part of the 3.0 3.1 release?
LWJGL 3 will have both libOVR and OpenGL ES bindings.
Quote from: BrickFarmer on March 09, 2015, 09:49:40Related to that, is it going to be possible using openGL ES to target both desktop and mobile? I dont have much experience with ES, and I'm wondering if it is even supported on the desktop?
See this post (http://www.g-truc.net/post-0457.html). It's a bit old, so try to make sure the information is still valid.
Quote from: BrickFarmer on March 09, 2015, 09:49:40Otherwise I'm going to port my examples over to 'modern OpenGL' is there a 'best practice' example for using shaders with LWJGL3?
There is no such thing as "best practice doing X with LWJGL". Anything that applies to OpenGL in general, applies to LWJGL. If you limit your search options to LWJGL specific code samples and tutorials (or this forum), you'll never find the information you're looking for.
Thanks for that! Some interesting reading, and still seems to reflect the current state of progress from what else I'm reading. The Google Angle looks promising, but not much of interest without a Java wrapper :) I'm gonna stick with porting this over to 'modern OpenGL' for now then, and have another look later about ES2/3.
So before I go any further, I wanted to check if my usage of LWJGL3 is correct in my simple shader example. I mean my program runs, but is there any gochas that I should know about before I take the next steps?
For example, I found a mention of glGetProgramiv(program, GL_LINK_STATUS, linked) in my book, but cant find the equivalent for LWJGL.
Also it looks like I should delete the program if linking fails, and I assume somewhere before I shut down GLFW? Or does the shader program get cleaned up internally at shutdown?
https://github.com/WhiteHexagon/example-jovr-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/riftexample/ShaderProgram120.java (https://github.com/WhiteHexagon/example-jovr-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/riftexample/ShaderProgram120.java)
Quote from: BrickFarmer on March 11, 2015, 08:46:53So before I go any further, I wanted to check if my usage of LWJGL3 is correct in my simple shader example. I mean my program runs, but is there any gochas that I should know about before I take the next steps?
For example, I found a mention of glGetProgramiv(program, GL_LINK_STATUS, linked) in my book, but cant find the equivalent for LWJGL.
You can use either glGetProgrami(int program, int pname, ByteBuffer params) or glGetProgram(int program, int pname, IntBuffer params).
Quote from: BrickFarmer on March 11, 2015, 08:46:53Also it looks like I should delete the program if linking fails, and I assume somewhere before I shut down GLFW? Or does the shader program get cleaned up internally at shutdown?
Everything is cleaned up automatically when you destroy an OpenGL context or the process exits. But it's good practice to do manual cleanup ahead of that. You should get used to properly handling the lifecycle of resources you allocate, especially if you're interested in trying Vulkan some day.
Quote from: spasi on March 09, 2015, 10:45:02
Quote from: BrickFarmer on March 09, 2015, 09:49:40I want to port this over to OpenGL ES, but it's not clear from the roadmap if OpenGL ES binding is part of the 3.0 3.1 release?
LWJGL 3 will have both libOVR and OpenGL ES bindings.
Nice! When is this planned to be released?
I have been using Pete's Minecrift driver so far:
http://aeonalpha.com (Runs at 1000+ FPS on GTX 750 Ti)
Also is Vulkan being looked at?
Being an old school direct rendering fan, I think Vulkan is the wrong priority:
First hardware should display the frame when the GPU sends the data like g-sync, but a common standard; that would be a more direct reward for VR. This multi-threaded rendering is going to slow development down, almost to a grinding halt.
Complexity is killing us slowly.
I noticed that libOVR is showing as beta support :) do you have any pointers to that for getting started? Also is it matching the Oculus Rift 0.6.0 SDK version? I'm keen to have another go with LWJGL and DK2.
I can't be of much help; I don't own a DK2, so have no way to do any testing with LWJGL. Everything is there though (the C API) and the Oculus SDK has plenty of example code to get you started and lots of useful information in the guides.
Yes, the bindings have been updated to the 0.6.0 SDK. The API has seen big improvements in the latest version. The 0.5 API felt like a hacky work-in-progress. 0.6 should be much closer to the final API and simpler to use than 0.5.
Wow that was fast, 0.6.0 has not been out for long. I'll dust of my windows box and give it a try :) Thanks!
The libOVR does not seem to be a part of the nightly, so I git cloned lwjgl3 master and tried building it from source. I needed an extra 'ant release' to build the .jar, but this also seems to be missing org.lwjgl.ovr package. Unless I used the wrong target?
I did do this on my mac, and I'm wondering if the build is platform aware? ie didnt include ovr since it's no longer supported on OSX?
or is there a config file somewhere that I need to set the build.ovr flag?
Indeed, the libOVR bindings are not included by default. You need to edit this line (https://github.com/LWJGL/lwjgl3/blob/master/config/build-modules.xml#L24), set the location to where you extracted the Oculus SDK. This is only supported on Windows atm, since the 0.6.0 runtime is Windows-only. You can use a free version of Visual Studio to build LWJGL, either Express 2013 for Windows Desktop (https://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx) or the new Community 2013 (https://www.visualstudio.com/products/visual-studio-community-vs).
I went with the community 2013, wow that is a slow install, it's taken most of the day to get everything running. jdk 1.8_45, ant 1.9.4, VS2013
So now I get as far as compile-native which fails with the linker with multiple error LNK2019 resulting in lwjgl.dll fater error LNK1120 101 unresolved externals
I'm sure it's just some more config stuff missing, but is there a guide for this so I dont waste your time? Thanks.
See this reply (http://forum.lwjgl.org/index.php?topic=5818.msg30904#msg30904).
Thanks! that helped somewhat... So I have the 'VS2013 x64 Native Tools Command Prompt' open. Java version is showing correct as 64bit server vm. ant echos x86 for build.arch. pretty sure my windows is 64bit 7 home premium SP1. A quick print in Java for os.arch shows amd64. but I'm still seeing some kind of mismatch, now with LNK1112 module machine type 'x64' conflicts with target machine type 'X86' on LIBCMT.lib(crt0dat.obj). So where might it be getting the X86 from?
The ant launcher uses the JDK pointed to by %JAVA_HOME%. Set it to a x64 JDK.
a few steps closer after a couple of fresh tries. Now I'm trying equivalent code from HelloLibOVR and I'm getting an Unsatisfied link error org.lwjgl.ovr.OVRInitParams.offsets.
I can see the ovr package in the .jar file, so that step worked, but maybe this is something not linked in for OVR? or does it generate a separate native lib? actually I dont see an output that looks like ovr in the natives directory... Is there something else required other than setting the OCULUS_SDK_PATH ?
[edit] build.ovr is true when ant is running
[edit2] actually it looks like the 'release' target only downloads the native libs... so maybe I'm using the wrong target after native-compile?
Hmm, yeah, the release target doesn't play nice with local builds. I'll have to do some changes there. For now, replace lwjgl.dll in the release with the one you've built in /libs.
yes, that did the trick! HelloLibOVR works now :) thanks!
Is it possible some classes have moved around in the latest sources, all my imports for org.lwjgl.system.glfw,GLFW... are failing, also GL11.Light and GL11.glLoadMatrix. I understand I'm on the cutting edge now building in this way, but just wondering if this is a new change or just a bad snapshot of master. Thanks.
Besides the above question, I'm also wondering about the parameters for the create call.
line 56:
https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/riftexample/RiftClient0600.java
The code runs, but the OVRHmdDesc structure comes back empty. For these generated interfaces it seems like there is a pointer version and a buffer version, so I'm wondering if I'm constructing the OVRHmdDesc object in the right way and if buffer() is the right call. I thought it might be that the buffer needed a rewind, but that doesnt seem to be the case.
Line 77 I also have a similar dilema. I found the BufferUtils :) but again I'm not feeling confident in the way I'm using the buffer since the result is also blank, although that might be releated to the above failure.
Quote from: BrickFarmer on May 29, 2015, 20:24:43Is it possible some classes have moved around in the latest sources, all my imports for org.lwjgl.system.glfw,GLFW... are failing, also GL11.Light and GL11.glLoadMatrix.
Yes, GLFW has moved and is a top level package now;
org.lwjgl.glfw. Functions like glLightfv have been renamed to match the native name, see this thread (http://forum.lwjgl.org/index.php?topic=5746.0) for details.
Quote from: BrickFarmer on May 30, 2015, 12:04:34Besides the above question, I'm also wondering about the parameters for the create call.
line 56:
https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/riftexample/RiftClient0600.java
The code runs, but the OVRHmdDesc structure comes back empty. For these generated interfaces it seems like there is a pointer version and a buffer version, so I'm wondering if I'm constructing the OVRHmdDesc object in the right way and if buffer() is the right call. I thought it might be that the buffer needed a rewind, but that doesnt seem to be the case.
Line 77 I also have a similar dilema. I found the BufferUtils :) but again I'm not feeling confident in the way I'm using the buffer since the result is also blank, although that might be releated to the above failure.
The ovrHmd_Create function writes a pointer to the pHmd parameter, which means you must use a PointerBuffer. This pointer indeed points to an ovrHmdDesc struct. The code below should answer both your questions:
// ovrHmd_Create writes a pointer to pHmd
PointerBuffer pHmd = BufferUtils.createPointerBuffer(1);
ovrHmd_Create(0, pHmd);
long hmd = pHmd.get(0); // This is the handle that you'll use in other ovrHmd* functions
// Create a ByteBuffer at the pointer and wrap it in an OVRHmdDesc
OVRHmdDesc desc = new OVRHmdDesc(memByteBuffer(hmd, OVRHmdDesc.SIZEOF));
// Read the struct fields
int resolutionW = desc.getResolutionW();
int resolutionH = desc.getResolutionH();
System.out.println("resolution W=" + resolutionW + " H=" + resolutionH);
// You can either use a struct instance, that wraps a ByteBuffer...
OVRFovPort defaultEyeFovL = new OVRFovPort();
OVRFovPort defaultEyeFovR = new OVRFovPort();
desc.getDefaultEyeFov(defaultEyeFovL.buffer(), ovrEye_Left);
desc.getDefaultEyeFov(defaultEyeFovR.buffer(), ovrEye_Right);
System.out.println(defaultEyeFovL.getUpTan()); // instance method
System.out.println(defaultEyeFovR.getDownTan()); // instance method
// ...or use ByteBuffers directly
ByteBuffer maxEyeFovL = BufferUtils.createByteBuffer(OVRFovPort.SIZEOF);
ByteBuffer maxEyeFovR = BufferUtils.createByteBuffer(OVRFovPort.SIZEOF);
desc.getMaxEyeFov(maxEyeFovL, ovrEye_Left);
desc.getMaxEyeFov(maxEyeFovR, ovrEye_Right);
System.out.println(OVRFovPort.UpTan(maxEyeFovL)); // static method
System.out.println(OVRFovPort.DownTan(maxEyeFovR)); // static methodPlease note that the way structs are exposed in LWJGL is subject to change before the final 3.0 release. For now, it's up to you whether you want to use ByteBuffers directly or the wrapper classes. The wrapper classes are more convenient, but there's an extra instance allocated. So try to avoid them in loops or other performance sensitive code and work with reusable ByteBuffer instances instead.
You may want to see this sample (https://twitter.com/CasualEffects/status/604042621141540865) by Morgan McGuire. It uses GLFW, OpenGL and LibOVR 0.6:
QuoteRunning this program should initialize a DK2 in direct-to-rift mode, display the Oculus health and safety warning, and show a simple 3D scene with full head tracking and per-user accomodation parameters.
Thanks for all that info. So today I have made quite good progress, at least I think so :) I'm looking at the following function though:
ovrPosef EyeRenderPose[2];
ovr_CalcEyePoses(hmdState.HeadPose.ThePose, ViewOffset, EyeRenderPose);
I can see this probably translating to:
OVRPosef headPose = new OVRPosef();
hmdState.getHeadPoseThePose(headPose.buffer());
OVRUtil.ovr_CalcEyePoses(headPose, hmdToEyeViewOffset, outEyePoses);
The problem I see is that the 2nd and 3rd parameters are both arrays. I ran into issues with the previous Oculus SDK that array parameters need to consist of contiguous memory blocks. So with JNA it involved something like:
private final Posef poses[] = (Posef[]) new Posef().toArray(2);
Is something similar required still. Either way I could use a tip for how to construct array parameters please.
I could take a guess that maybe I just create a ByteBuffer of double the size (since the each takes an array of 2 elements, one for each eye) and handle the pointers etc myself? Just worried this might get messy, and might not be the best way...
[edit]
Actually, do you think it would be possible from the generating code, to identify when there are array parameters or variables that have ovrEye_Count as thier size to generate a left and right accessor/setter? Since that is a special case on the OVR library, I understand if that is undesirable.
RenderPose[ovrEye_Count]
would generate:
setRenderPose0
setRenderPose1
Just an idea :) Otherwise I'm wondering if I generate a wrapper or helper class for working with the libOVR, whatever you prefer...
This indeed is going to be ugly, but we can't do much better until Project Panama (http://danheidinga.github.io/J9-Panama/StateOfTheLDL.html) becomes a reality in Java. LibOVR in particular is an API heavy on structs and as I said above LWJGL needs more work on struct support. Also keep in mind that LWJGL always prefers performance and matching the native interface, rather than convenience. I don't know what JNA does with Posef[] but I'm sure it involves copying memory.
So, I would do something like this:
// Get the head pose and eye rendering information
OVRPosef headPose = ...;
OVREyeRenderDesc leftEyeRD = ...;
OVREyeRenderDesc rightEyeRD = ...;
// hmdToEyeViewOffset is an ovrVector3f[2]
ByteBuffer hmdToEyeViewOffset = BufferUtils.createByteBuffer(2 * OVRVector3f.SIZEOF);
leftEyeRD.getHmdToEyeViewOffset(hmdToEyeViewOffset);
hmdToEyeViewOffset.position(OVRVector3f.SIZEOF);
rightEyeRD.getHmdToEyeViewOffset(hmdToEyeViewOffset);
hmdToEyeViewOffset.position(0);
// outEyePoses is an ovrPosef[2]
ByteBuffer outEyePoses = BufferUtils.createByteBuffer(2 * OVRPosef.SIZEOF);
ovr_CalcEyePoses(headPose.buffer(), hmdToEyeViewOffset, outEyePoses);
// Retrieve the eye poses
outEyePoses.limit(OVRPosef.SIZEOF);
OVRPosef leftEyePose = new OVRPosef(outEyePoses.slice().order(outEyePoses.order()));
outEyePoses.position(OVRPosef.SIZEOF);
outEyePoses.limit(2 * OVRPosef.SIZEOF);
OVRPosef rightEyePose = new OVRPosef(outEyePoses.slice().order(outEyePoses.order()));
The above could be improved in two ways (that I can think of):
1) Methods like getHmdToEyeViewOffset could also accept an offset, so you wouldn't have to mess with hmdToEyeViewOffset's position.
2) We could add a memSlice(buffer, from, to) method that would let you get the eye poses in 2 lines instead of 5.
3) Alternative to 2, we could add struct constructors that accept an offset and do the slicing internally.
Panama looks perfect for this. Anyway thanks for the rapid solution! I think that is fine for now, and is at least explicit in it's intention. Anyway I will probably wrap a lot of the boiler plate code, just to simplify reuse, at the cost of maintaining another wrapper.
I've uploaded my current progress, it builds locally, but does not yet run. I need to do some work on the FrameBuffer texture code tomorrow, and I want to remove some other dependencies.
The next nightly (#51) will have memSlice in MemoryUtils. Make sure to read the javadoc. If you use it, the last 5 lines above become:
OVRPosef leftEyePose = new OVRPosef(memSlice(outEyePoses, OVRPosef.SIZEOF));
OVRPosef rightEyePose = new OVRPosef(memSlice(outEyePoses, OVRPosef.SIZEOF, 2 * OVRPosef.SIZEOF));
Quote from: spasi on June 01, 2015, 15:43:17
The next nightly (#51) will have memSlice in MemoryUtils.
great!
On the ovrHmd_SubmitFrame I can see it's looking for layerPtrList. This seems different than my earlier question. Would this be the correct way to construct a list of pointers?
layers = BufferUtils.createByteBuffer(Long.BYTES);
layers.putLong(layer0.getPointer());
layers.position(0);
line 494 from my code. I'm just checking because I get a native crash on the ovrHmd_SubmitFrame call and that structure seems the most likerly candidate.
Use a PointerBuffer (https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/PointerBuffer.java):
PointerBuffer layers = BufferUtils.createPointerBuffer(1);
layers.put(0, layer0);
There's a ovrHmd_SubmitFrame version that accepts a Pointerbuffer, instead of ByteBuffer + layerCount.
Quote from: spasi on June 01, 2015, 16:59:33
There's a ovrHmd_SubmitFrame version that accepts a Pointerbuffer, instead of ByteBuffer + layerCount.
Much easier :) however I'm seeing conflicting info on the parameter type.
In ovr_capi_0_6_0.h
ovrLayerHeader const * const * layerPtrListand also the example in the comments for ovrHmd_SubmitFrame talk about headers rather than layers for the pointer list. But also mentions "layerPtrList Specifies a list of ovrLayer pointers"
So I'm not sure whcih I should be using there, and also if it needs the getPointer since its expecting a long:
[edit] tried both and my crash must be elsewhere. I will try again tomrrow with fresh mind :)
OVRLayerHeader header = new OVRLayerHeader();
header.setType(ovrLayerType_EyeFov);
header.setFlags(ovrLayerFlag_TextureOriginAtBottomLeft);
layer0 = new OVRLayerEyeFov();
layer0.setHeader(header.buffer());
for (int eye = 0; eye < 2; eye++) {
layer0.setColorTexture(textureSet[eye].buffer(), eye);
layer0.setViewport(textureSize.buffer(), eye);
layer0.setFov(fovPorts[eye].buffer(), eye);
// we update pose only when we have it in the render loop
}
layers = BufferUtils.createPointerBuffer(1);
layers.put(0, header.getPointer());
//layers.put(0, layer0.getPointer());
Quote from: BrickFarmer on June 01, 2015, 18:14:29In ovr_capi_0_6_0.h
ovrLayerHeader const * const * layerPtrList
and also the example in the comments for ovrHmd_SubmitFrame talk about headers rather than layers for the pointer list. But also mentions "layerPtrList Specifies a list of ovrLayer pointers"
The Header field is always the first field in all ovrLayer* structs. Which means that the address of an ovrLayer* struct will always be the same as &layer.Header (as seen in the example code).
Quote from: BrickFarmer on June 01, 2015, 18:14:29if it needs the getPointer since its expecting a long:
All LWJGL structs implement the Pointer (https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/Pointer.java) interface and there's a convenient put(int index, Pointer wrapper) (https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/main/java/org/lwjgl/PointerBuffer.java#L475) method in PointerBuffer that invokes .getPointer() for you.
Quote from: BrickFarmer on June 01, 2015, 18:14:29 OVRLayerHeader header = new OVRLayerHeader();
header.setType(ovrLayerType_EyeFov);
header.setFlags(ovrLayerFlag_TextureOriginAtBottomLeft);
layer0 = new OVRLayerEyeFov();
layer0.setHeader(header.buffer());
for (int eye = 0; eye < 2; eye++) {
layer0.setColorTexture(textureSet[eye].buffer(), eye);
layer0.setViewport(textureSize.buffer(), eye);
layer0.setFov(fovPorts[eye].buffer(), eye);
// we update pose only when we have it in the render loop
}
layers = BufferUtils.createPointerBuffer(1);
layers.put(0, header.getPointer());
//layers.put(0, layer0.getPointer());
In the code above, you're creating an OVRLayerHeader struct, then copying its contents to the Header field of the OVRLayerEyeFov struct. LWJGL generates extra methods in struct classes for getting/setting fields of nested structs. You can change the code to:
layer0 = new OVRLayerEyeFov();
layer0.setHeaderType(ovrLayerType_EyeFov);
layer0.setHeaderFlags(ovrLayerFlag_TextureOriginAtBottomLeft);
...which does the same thing without an extra struct allocation + copy.
thanks for the tips :) Getting close I think!
I had a huge confusion with the OVRGLTexture, since creating the OVRSwapTextureSet(1 per eye) provides the textures already! In fact it creates 2 textures per eye.
Anyway I think I managed to work that out, and I get 4 textures numbered 1,2,3,4 which seems sensible. But I'm still getting a native crash EXCEPTION_ACCESS_VIOLATION on the SubmitFrame call. I've traced it back to the setColorTexture, ie. if I comment that line(463) out then I dont get the crash, but obviously also no drawing :)
If you get time, please could you inspect my textureSet creation code:
https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/riftexample/RiftClient0600.java#L424
[edit] I've also tried using a single texture instead of texture per eye, but same sort of crash
This was a bug in LWJGL's generator, which I just fixed. ovrLayerEyeFov.ColorTexture is an array of pointers to ovrSwapTextureSet structs, but the generator was treating it as a nested struct array. Do a pull and rebuild LWJGL, it should work fine.
Confirmed that fixes the problem :) Now my code loops. Next job for me is to get something to display, and the headset doesnt seem to activate. But that's my problems. I'll let you know if I make further progress, and thanks for the quick fix! Peter.
[edit]
I was just looking to add the mirror buffers to get something to display at least in the desktop window. It looks like ovrHmd_CreateMirrorTextureGL is a candidate for a PointerBuffer? even if this is a single Texture being generated (not a set). ie. ovrTexture** outMirrorTexture
I did take a look at the last fix you did, but I cant figure out how that generation works, or if the above is valid, sorry!
PS I asked over on the oculus forum to see the rift would run without GLFW. Since I think the rift manages it's own window. But then I started thinking how would the glContext work in that case, since it seems to be attached to a window. Not important, I was just interested.
Quote from: BrickFarmer on June 02, 2015, 17:12:22I was just looking to add the mirror buffers to get something to display at least in the desktop window. It looks like ovrHmd_CreateMirrorTextureGL is a candidate for a PointerBuffer? even if this is a single Texture being generated (not a set). ie. ovrTexture** outMirrorTexture
There is already a PointerBuffer version of ovrHmd_CreateMirrorTextureGL, just like ovrHmd_CreateSwapTextureSetGL.
Quote from: BrickFarmer on June 02, 2015, 17:12:22PS I asked over on the oculus forum to see the rift would run without GLFW. Since I think the rift manages it's own window. But then I started thinking how would the glContext work in that case, since it seems to be attached to a window. Not important, I was just interested.
LWJGL doesn't care who manages the OpenGL context. GLContext.createFromCurrent() will work, as long as there is a current OpenGL context in the current thread. But I'm pretty sure LibOVR does not create a context of its own, it uses the context provided by the application.
Quote from: spasi on June 02, 2015, 19:46:48
There is already a PointerBuffer version of ovrHmd_CreateMirrorTextureGL, just like ovrHmd_CreateSwapTextureSetGL.
Ah yes, it was a long day :) I got the mirror mode working, and it turns out the blank display on the Rift just needed a PC reboot.
Anyway I have something that at least now shows a clearColor! Still that's quite exciting for me after 3 days :)
It can be used without a Rift, although obviously no tracking.
https://github.com/WhiteHexagon/example-lwjgl3-rift
My scene doesnt yet render, no idea why at this point, but that's todays challenge.
So I've tracked my issue down to my use of ovrMatrix4f_Projection. Please can you confirm the __result type that this is expecting? I'm passing a OVRMatrix4f buffer but not sure that is correct?
Yes, it is correct. The native function returns an ovrMatrix4f struct by value. Since this can't be translated to Java, LWJGL creates the virtual __result parameter, that must be the address to an ovrMatrix4f struct. The JNI code looks like this:
ovrFovPort *fov = (ovrFovPort *)(intptr_t)fovAddress;
*((ovrMatrix4f*)(intptr_t)__result) = ovrMatrix4f_Projection(*fov, znear, zfar, projectionModFlags);
What exactly is the problem you're having? Does the projection struct stay empty after a call to ovrMatrix4f_Projection?
Thanks, I just wanted to be sure because the parameter looked a bit different from other methods. This is what I'm calling.
OVRUtil.ovrMatrix4f_Projection(fovPorts[eye].buffer(), 0.5f, 500f, OVRUtil.ovrProjection_RightHanded, projections[eye].buffer());
gives
0.92978895, 0.0, 0.01567176, 0.0,
0.0, 0.7509745, 0.0, 0.0,
0.0, 0.0, -1.001001, -0.5005005,
0.0, 0.0, -1.0, 0.0,
(actually it's the same matrix for both eyes, even if my FOVs are different between left and right)
This is how I load it into GL_PROJECTION.
glLoadMatrixf(projections[eye].buffer());
What I noticed today, is if I change line to
glFrustum(-1.0f * canvasRatio, canvasRatio, -1.0f, 1.0f, .5f, 500.0f);
I get a very similar matrix being put into the GL_PROJECTION
0.28125, 0.0, 0.0, 0.0,
0.0, 0.5, 0.0, 0.0,
0.0, 0.0, -1.002002, -1.0,
0.0, 0.0, -1.001001, 0.0,
but my scene actually renders. So I'm missing something in my understanding. Is glFrustrum doing something other than setting the projection matrix, or is it my loading of the matrix thats incorrect? From the SDK it sounds like it might be a transpose matrix, but when they seem to be so similar I'm not so sure. To be honest this is a bit out of my comfort zone...
Hmm, not sure.
McGuire's sample uses ovrProjection_RightHanded and glLoadTransposeMatrixf. Have you tried ovrProjection_ClipRangeOpenGL?
OK thanks, I will experiment some more with that, or just stick with the glFrustum call for now :) Eventually I will move this example over to more modern OpenGL, but for now I just try to use what I previously learned a long time ago...
I just tried to move all the GLFW stuff into an optional class, ie since the mirroring is optional. However I realised I have no way to create an OpenGL context by doing this. I assume the Oculus SDK has it's own context which does not seem to be exposed, and probably best that way!
ie. the only method I can find in LWJGL for creating a context is by referenceing a window. I supose I could create a 1x1 borderless window to get around this, but just wanted to check that I didnt miss anything? and if that is maybe the best way, at least then I could still get some keyboard events too :)
Hi,
your experimentation with the Rift seems quite cool.
If you manage to get the projection settings working, which looks to be quite complicated, involving some number of parameters, we could somehow wrap that in a nice method and add that to a coming JOML-LWJGL integration library, so that one would not have to fiddle around with all that native structs and buffer stuff, which looks like it can be hidden away quite effectively, especially because... well... the Rift is just the Rift with always? the same frustum settings?
I do not own a Rift myself, but I figure the projection matrix creation can be wrapped quite nicely.
Quote from: BrickFarmer on June 04, 2015, 12:35:00ie. the only method I can find in LWJGL for creating a context is by referenceing a window. I supose I could create a 1x1 borderless window to get around this, but just wanted to check that I didnt miss anything? and if that is maybe the best way, at least then I could still get some keyboard events too :)
See this reply (http://forum.lwjgl.org/index.php?topic=5826.msg31013#msg31013). The alternative is pbuffers and LWJGL supports those too, but they are not cross-platform (e.g. WGL_ARB_pbuffer (https://github.com/LWJGL/lwjgl3-generated/blob/master/java/org/lwjgl/opengl/WGLARBPbuffer.java))
Thanks. I've decided to stick with the window. As someone pointed out on the oculus forum, its the best way to know the rift is active.
Anyway I have updated my demo to use frustum for now, so at least the scene renders! if no rift is found it auto rotates on the y axis.
Quote from: Kai on June 04, 2015, 13:05:35
Hi,
your experimentation with the Rift seems quite cool.
If you manage to get the projection settings working, which looks to be quite complicated, involving some number of parameters, we could somehow wrap that in a nice method and add that to a coming JOML-LWJGL integration library, so that one would not have to fiddle around with all that native structs and buffer stuff, which looks like it can be hidden away quite effectively, especially because... well... the Rift is just the Rift with always? the same frustum settings?
I do not own a Rift myself, but I figure the projection matrix creation can be wrapped quite nicely.
Thanks. Yes I hope to put a dependency on to JOML as soon as it makes maven ;) I want to try and put together another couple of demos to show what LWJGL 3 can do for the Rift community :) Yesterday I was working on splitting out the Rift specific code, and the scene code. So hopefully that will make it easier for people trying the library. Code reviews always welcome! I know my OpenGL is very rusty! Once I have this GL11 version working I hope to do a shader based version, and that is all new for me. Hopefully we will be able to do an ES2 version as well and maybe find a common platform between the Rift and GearVR for example. Anyway I will need help on the math side for sure, the code seems ok with this frustum call, but I would prefer if I could fix the loadMatrix issue, since that might be why I'm also seeing some warping, and some strange effects on the model view stuff.
Updated my example with fixed Matrix code and now using JOML :)
I've checked in my code, which runs without a rift (assuming you have rift enabled build of LWJGL3). Based on JOML 1.2.6 (since I think the API has changed). Ignore my maven stuff for now.
Full code here:
https://github.com/WhiteHexagon/example-lwjgl3-rift/tree/master/src/main/java/com/sunshineapps/rift/experimental
I have some issue with my colorBuffer, ie the globe changes color over time...
Switching method2 to method4 for my longitude/latitude calculations makes for an interesting optical illusion.
I do see some very slight movement in the scene geometry when moving my head around, but it's difficult to describe and only very slight. It could just be a precision issue, or a slightly incorrect projection matrix from the Rift SDK. I've no idea really, but something feels very slightly out.
here is the relevant matrix code for anyone trying to do this:
glMatrixMode(GL_MODELVIEW);
mat.identity();
Vector3f offsetPosition = new Vector3f(eyeRenderDesc[eye].getHmdToEyeViewOffsetX(), eyeRenderDesc[eye].getHmdToEyeViewOffsetY(), eyeRenderDesc[eye].getHmdToEyeViewOffsetZ());
mat.translate(offsetPosition);
Quaternion orientation = new Quaternion(eyePose.getOrientationX(), eyePose.getOrientationY(), eyePose.getOrientationZ(), eyePose.getOrientationW());
orientation.invert();
mat.rotate(orientation);
Vector3f position = new Vector3f(-eyePose.getPositionX(), -eyePose.getPositionY(), -eyePose.getPositionZ());
mat.translate(position);
mat.translate(playerEyePos); //back to 'floor' height
Nice! :) Gonna try that out in the evening without a Rift.
Yes, the Quaternion class got renamed to Quaternionf in 1.3.0.
And since 1.3.5-SNAPSHOT, angles are now all in radians instead of degrees.
I would really encourage you to use at least the 1.3.0 release, since there were some bugs resolved in all classes of JOML.
Quote from: Kai on July 10, 2015, 10:38:28
I would really encourage you to use at least the 1.3.0 release, since there were some bugs resolved in all classes of JOML.
I wait for both libs to be stable in maven central first, since I also prefer the degrees for now :)
btw any tips on making a lightweight simple menu in LWJGL3, just to select which 'scene' my demo shows. I'm thinking maybe a secondary window, that has a background image (if possible?) and just doing a mouse x/y check for which quarter of the screen was clicked...
Do you need a graphical selection for that, or would a simple keyboard input (like numpad '1' being the first scene, '2' the second, or arrow keys up/down or page up/down to cycle, etc.) suffice?
Some years ago, I came across the Themable Widget Library (http://twl.l33tlabs.org/), which provides a "window manager" and "compositor" for LWJGL/OpenGL applications, although I believe that they are still using LWJGL2, so a little porting needs to be done. But it is really great. Have tried their demos right now, and I am impressed! :)
The 1.4.0 release of JOML is due to tomorrow and will deploy to Central.
EDIT: Just had a more thorough look into TWL. Boy is that a nice library with nice pluggable renderer and input support. Got it to work easily with kappa's fantastic lwjglx library (https://github.com/kappaOne/lwjglx) to adapt LWJGL 3 to the API of LWJGL 2, which TWL currently expects. Although some few methods are missing. But it would be very little work to actually port TWL to LWJGL 3.
TWL looks really interesting, but keyboard is probably enough for now! why didnt I think of that! :)
Also in my mission to separate out the boiler plate code, my window now ends up 'not responding' and I dont get key press info, but the scene renders fine. I thought my render loop might be hogging the main thread, but that doesnt seem to be the case. Any idea what might cause the window title to have the not responding message appended please?
I've checked in my latest code, MirrorWindow holds all the glfw stuff.
btw Nice to see JOML reach Central, well done!
Quote from: BrickFarmer on July 13, 2015, 10:12:22Also in my mission to separate out the boiler plate code, my window now ends up 'not responding' and I dont get key press info, but the scene renders fine. I thought my render loop might be hogging the main thread, but that doesnt seem to be the case. Any idea what might cause the window title to have the not responding message appended please?
Why are you calling glfwPollEvents() in SwingUtilities.invokeLater? This makes no sense. The EDT is not the main thread (on Windows) and it is not the thread that created the GLFW window. You also trigger AWT initialization, which is tons of overhead. Keep it simple, move all event polling in Client.run(), which runs on the main thread. Also, there are probably more lightweight ways to throttle the mirror blit than ScheduledExecutorService.scheduleAtFixedRate.
Quote from: spasi on July 13, 2015, 13:15:30
Why are you calling glfwPollEvents() in SwingUtilities.invokeLater? This makes no sense. The EDT is not the main thread (on Windows) and it is not the thread that created the GLFW window. You also trigger AWT initialization, which is tons of overhead. Keep it simple, move all event polling in Client.run(), which runs on the main thread. Also, there are probably more lightweight ways to throttle the mirror blit than ScheduledExecutorService.scheduleAtFixedRate.
Great it's working now, thanks for your help with that!
Yeah, I wasnt sure about that blit stuff. I've used a similar approach for a scene animator in the past and found it very smooth, but maybe it is overkill here. Although currently 97% CPU time is spent in novrHmd_SubmitFrame
Now that JOML has reached Maven, I'm just wondering if/when LWJGL 3 Rift beta support might also make it into maven?
I'd like to publish some of my new experiments over on the Oculus forums, but the setup is probably too complex right now. I still have loads of work to complete, but I'm just wondering if there was a timeline I could work to that might help promote the LWJGL3 Rift support :)
otherwise I might try to build an .exe for now
I haven't enabled the LibOVR bindings in the official builds because:
a) It's (very) beta.
b) It's Windows-only currently.
c) The Windows build server does not have the Oculus SDK.
d) Very few people use it. You're probably the only one.
But promoting LWJGL is welcome... I'll see what I can do, will let you know.
Quote from: spasi on July 23, 2015, 11:58:37
I haven't enabled the LibOVR bindings in the official builds because:
a) It's (very) beta.
b) It's Windows-only currently.
c) The Windows build server does not have the Oculus SDK.
d) Very few people use it. You're probably the only one.
But promoting LWJGL is welcome... I'll see what I can do, will let you know.
a) I think people expect that, especially since the Oculus SDK will probably be in beta until the release next year of CV1
b) Sadly I dont think they change that policy too soon, since they have a tie up with MS for CV1 release
c) and there is now a new SDK 0.6.0.1 if you do get a chance for that.
d) Probably right, but I'm doing my best to change that, and I can help test new builds as and when you release them :) and of course I try to make more demos to show whats possible. maybe even some with modern OpenGL as soon as I get my head around it :)
This time next year there will be a lot of units out there, and probably more developers looking to jump on the VR bandwagon. Maybe Unity is the preferred choice right now, but if the cross platform support comes back to Oculus, then I think people will consider Java as a good choice for that. Especially if they manage to combine the mobile and desktop SDKs into a common ES2 platform. Thanks anyway for the great work so far, here is a peak at my next demo:
https://www.youtube.com/watch?v=ZD1ry73TW2I
The latest nightly (3.0.0b #8) now comes with LibOVR 0.6.0.1 bindings. Have fun!
Thanks!! Well I downloaded the nightly and it took me 10 mins to update a few API changes and implement the new performance HUD from the latest SDK (F11 in my demo) so that's already a much easier process :)
I spent the rest of the day trying to get LWJGL into my local maven repository. I kinda managed to get that working including the .dll. Next I try to find a solution for setting the java.library.path. I will feed back if I get that working. Thanks. Peter
This sample project (https://github.com/badlogic/lwjgl3-maven-gradle) might help.
Is the statement there correct, or the plan going forward? 'LWJGL also releases snapshot builds daily to SonaType'
It's a slightly different approach than what I found:
http://stackoverflow.com/questions/7515504/maven-project-with-native-dependency-and-copying-files
but neither one is ideal, since for example openAL is in a different .dll but shares the same master .jar. The problem is more with mavens approach of one artifact per pom. I had a look this morning at the maven natives plugin, and trying to pack the dll into a jar, and then unpack it into /lib, but it was all getting very messy!
Next I'm looking at Gradle, seems a lot more flexible...
Quote from: BrickFarmer on July 30, 2015, 10:34:15Is the statement there correct, or the plan going forward? 'LWJGL also releases snapshot builds daily to SonaType'
Yes, it is: https://oss.sonatype.org/content/repositories/snapshots/org/lwjgl/lwjgl/3.0.0b-SNAPSHOT/
Quote from: BrickFarmer on July 30, 2015, 10:34:15It's a slightly different approach than what I found:
http://stackoverflow.com/questions/7515504/maven-project-with-native-dependency-and-copying-files
Not sure what the best practice is, but keep in mind that we also support 3 OSes. Times 2 files, that's 6 artifacts. Would get messy and it doesn't scale well if we add more libraries in the future.
Great! I was assuming that this maven work hadn't yet been done for LWJGL, and was trying to be helpful in my own way.
Anyway I tried gradle today, and I felt like I swapped one set of problems for another :) So I went back to maven and the link you provided, I added the SharedLibraryLoader and now my project is pulling direct from sonotype, and doesnt require the java.library.path setting, which is another step in making things easier. Thanks for the info!
Quote from: BrickFarmer on July 29, 2015, 17:12:31
Thanks!! Well I downloaded the nightly and it took me 10 mins to update a few API changes and implement the new performance HUD from the latest SDK (F11 in my demo) so that's already a much easier process :)
Could you share your build of the ovr natives? Does anything need to change in the jar as well or is 3.0.0b build 9 enough? I upgraded to LWJGL 3 just because of libOVR after you told me that it was getting along nicely :)
Spasi, when do you think that you will have time to add the 0.7.0 api? It looks like a great SDK version with several simplifications.
I'll work on 0.7.0 tomorrow.
Quote from: spasi on August 28, 2015, 15:55:44
I'll work on 0.7.0 tomorrow.
You chose GLFW for (among other things) great support. We stick with LWJGL because of you! ;D
The latest nightly build (3.0.0b #22) includes updated LibOVR bindings for the 0.7.0 Oculus SDK.
Quote from: Mickelukas on August 28, 2015, 16:30:44You chose GLFW for (among other things) great support. We stick with LWJGL because of you! ;D
<3
Amazing! Brickfarmer, as you already have the build environment up and running, do you mind building the dll and share it? There's only a 64 bit version nowadays I saw.
Quote from: spasi on August 29, 2015, 09:50:32
The latest nightly build (3.0.0b #22) includes updated LibOVR bindings for the 0.7.0 Oculus SDK.
Nice! I was just on my way over here to ask about that :) I will get my demo updated.
Quote from: Mickelukas on August 29, 2015, 11:28:17
Amazing! Brickfarmer, as you already have the build environment up and running, do you mind building the dll and share it? There's only a 64 bit version nowadays I saw.
I think that's correct, the Oculus runtime is 64bit only now. So the dll that's included in the LWJGL 3 build mentioned above should work fine without a custom build.
Ok. so I worked out most of the changes I think, but at runtime I'm seeing a failed to load library jemalloc.dll
I'm using the SharedLibraryLoader approach, which seems to locate the libOVR with no problem.
I don't think SharedLibrarryLoader has been updated to handle jemalloc. In any case, LWJGL has a fallback if jemalloc is not available, does that fail too?
well the create seems to pass, but then the OVRHmdDesc is giving back 0x0 resolution. Although it might be to do with this new Luid parameter on the create, since I only pass a buffer from a created instance of OVRGraphicsLuid, ie I'm not populating it.
[edit] actually reading the change log the luid is passed back from the call, so the only other change I can see that might be related is this:
"Changed ovrHmd from a struct pointer to an opaque pointer and left ovrHmdDesc as a separate struct."
https://developer.oculus.com/history/
Could it be related to empty/corrupt values in the desc?
Quote from: BrickFarmer on August 30, 2015, 15:00:11"Changed ovrHmd from a struct pointer to an opaque pointer and left ovrHmdDesc as a separate struct."
https://developer.oculus.com/history/
Could it be related to empty/corrupt values in the desc?
I don't think so, ovrHmdDesc is also a struct returned from LibOVR (from ovr_GetHmdDesc(hmd)), you don't have to set anything in it. The change to ovrHmd is a change at the native side only, the Java API didn't change from 0.6 to 0.7.
Other than Resolution being set to 0x0, are you having other problems?
Quote from: spasi on August 30, 2015, 18:28:31
Other than Resolution being set to 0x0, are you having other problems?
To me it seems like the desc struct has not populated. Anyway if I hack in some dimensions, then the code just fails a bit further along with some d3d swap chain creation error, ie something internal to the SDK.
Any tip on how I can resolve the jemalloc error, maybe it's just that causing these problem. Is that a new dependency from libOVR or something from LWJGL?
Quote from: BrickFarmer on August 31, 2015, 08:22:48
...along with some d3d swap chain creation error, ie something internal to the SDK.
D3D swap chain? Is libOVR using DirectX/Direct3D?? o_O
Thought it would use OpenGL. Do they use Direct3D internally (which would explain why it's Windows-only) and just want the application to blit the framebuffer into an OpenGL texture, which they then display via Direct3D?
Quote from: BrickFarmer on August 31, 2015, 08:22:48To me it seems like the desc struct has not populated. Anyway if I hack in some dimensions, then the code just fails a bit further along with some d3d swap chain creation error, ie something internal to the SDK.
Could you share your init code? From the 0.7.0 OpenGL sample:
ovrHmd HMD;
ovrGraphicsLuid luid;
ovrResult result = ovr_Create(&HMD, &luid);
if (!OVR_SUCCESS(result))
return retryCreate;
ovrHmdDesc hmdDesc = ovr_GetHmdDesc(HMD);
// Setup Window and Graphics
// Note: the mirror window can be any size, for this sample we use 1/2 the HMD resolution
ovrSizei windowSize = { hmdDesc.Resolution.w / 2, hmdDesc.Resolution.h / 2 };Looks simple enough. Btw, have you updated the Oculus Runtime to 0.7.0 on your machine?
Quote from: BrickFarmer on August 31, 2015, 08:22:48Any tip on how I can resolve the jemalloc error, maybe it's just that causing these problem. Is that a new dependency from libOVR or something from LWJGL?
No, jemalloc has nothing to do with LibOVR. See this topic (http://www.java-gaming.org/topics/lwjgl-jemalloc-bindings/36524/view.html) for details.
Since you're using maven/gradle + SharedLibraryLoader, you need to update it to handle the jemalloc binaries. It currently only handles the lwjgl and openal binaries. Note that, at some point before the 3.0 release, I'll add SharedLibraryLoader (or something like it) to LWJGL and it will always be up-to-date.
In any case, it shouldn't be a problem. When LWJGL fails to load jemalloc, it falls back to the standard C library malloc functions. Functionally it's the same thing, except slower.
Here is my init code:
// step 1 - hmd init
System.out.println("step 1 - hmd init");
OVRLogCallback callback = new OVRLogCallback() {
@Override
public void invoke(long userData, int level, long message) {
System.out.println("LibOVR [" + userData + "] [" + level + "] " + memDecodeASCII(message));
}
};
OVRInitParams initParams = new OVRInitParams();
initParams.setLogCallback(callback.getPointer());
// initParams.setFlags(ovrInit_Debug);
if (ovr_Initialize(initParams.buffer()) != ovrSuccess) {
System.out.println("init failed");
}
System.out.println("OVR SDK " + ovr_GetVersionString());
// step 2 - hmd create
System.out.println("step 2 - hmd create");
PointerBuffer pHmd = BufferUtils.createPointerBuffer(1);
OVRGraphicsLuid luid = new OVRGraphicsLuid();
if (ovr_Create(pHmd, luid.buffer()) != ovrSuccess) {
System.out.println("create failed, try debug");
//debug headset is now enabled via the Oculus Configuration util . tools -> Service -> Configure
return;
}
// step 3 - hmdDesc queries
System.out.println("step 3 - hmdDesc queries");
hmd = pHmd.get(0);
hmdDesc = new OVRHmdDesc(MemoryUtil.memByteBuffer(hmd, OVRHmdDesc.SIZEOF));
System.out.println(hmdDesc.getProductNameString()+"-"+hmdDesc.getType());
if(hmdDesc.getType() == ovrHmd_None) {
System.out.println("missing init");
}
resolutionW = hmdDesc.getResolutionW();
resolutionH = hmdDesc.getResolutionH();
canvasRatio = (float)resolutionW/resolutionH;
System.out.println("resolution W=" + resolutionW + ", H=" + resolutionH);
https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/rift/experimental/RiftWindow0700.java
Yes my system is now 0700 and I checked there is no old version there. The oculus config demo scene works fine. I will ignore the jemalloc for now, but maybe the exception could be caught going forwards?
Java 1.8.0_45
LWJGL lwjgl-3.0.0b
step 0 - create rift
step 1 - hmd init
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.lwjgl.system.MemoryManage.getInstance(MemoryManage.java:24)
at org.lwjgl.system.MemoryUtil.<clinit>(MemoryUtil.java:60)
at org.lwjgl.system.libffi.Closure.<clinit>(Closure.java:44)
at com.sunshineapps.rift.experimental.RiftWindow0700.<init>(RiftWindow0700.java:130)
at com.sunshineapps.rift.experimental.Client.run(Client.java:28)
at com.sunshineapps.rift.experimental.Client.main(Client.java:88)
Caused by: java.lang.ExceptionInInitializerError
at org.lwjgl.system.jemalloc.JEmalloc.getInstance(JEmalloc.java:79)
... 10 more
Caused by: java.lang.RuntimeException: Failed to load library: jemalloc.dll (error code = 126)
at org.lwjgl.system.windows.WindowsUtil.windowsThrowException(WindowsUtil.java:28)
at org.lwjgl.system.windows.WindowsLibrary.<init>(WindowsLibrary.java:34)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:54)
at org.lwjgl.LWJGLUtil.loadLibraryNative(LWJGLUtil.java:164)
at org.lwjgl.system.jemalloc.LibJEmalloc.create(LibJEmalloc.java:35)
at org.lwjgl.system.jemalloc.LibJEmalloc.create(LibJEmalloc.java:26)
at org.lwjgl.system.jemalloc.LibJEmalloc.<clinit>(LibJEmalloc.java:19)
... 11 more
LibOVR [0] [1] 09/01/15 11:06:30: [CAPI] LibOVR module is located at C:\Windows\system32\LibOVRRT64_0_7.dll
OVR SDK 0.7.0.0
step 2 - hmd create
step 3 - hmdDesc queries
y-1381376115
resolution W=0, H=0
Quote from: BrickFarmer on September 01, 2015, 11:13:46Here is my init code:
It's wrong: you're assuming that the ovrHmd pointer points to an ovrHmdDesc struct. This was true in 0.6 but has changed in 0.7. ovrHmd is now an opaque pointer and ovrHmdDesc must be retrieved using ovr_GetHmdDesc(), see the HelloLibOVR (https://github.com/LWJGL/lwjgl3/blob/93f22d0be95c8933447550104f9e5898956f1497/modules/core/src/test/java/org/lwjgl/demo/ovr/HelloLibOVR.java) sample.
Quote from: BrickFarmer on September 01, 2015, 11:13:46I will ignore the jemalloc for now, but maybe the exception could be caught going forwards?
Sorry about that, there was a printStackTrace() in there. The next build will fallback silently.
Thanks, that's working fine now! :)
Quote from: Kai on August 31, 2015, 08:35:26
Quote from: BrickFarmer on August 31, 2015, 08:22:48
...along with some d3d swap chain creation error, ie something internal to the SDK.
D3D swap chain? Is libOVR using DirectX/Direct3D?? o_O
Thought it would use OpenGL. Do they use Direct3D internally (which would explain why it's Windows-only) and just want the application to blit the framebuffer into an OpenGL texture, which they then display via Direct3D?
Yes I was wondering the same, I've asked over on Oculus board to see if anyone knows...