@rickard said:
Been spending some time trying to build the linux version. I've gotten as far as it outputing "OculusLib.o". The liboculus.so target is not succesful, however, complaining about the following:
Are you trying to compile windows version using mingw32 or cross-compile linux version on windows? Depending on that, you are going to need very different approach.
@rickard said:
Been spending some time trying to build the linux version. I've gotten as far as it outputing "OculusLib.o". The liboculus.so target is not succesful, however, complaining about the following:
I’m assuming it’s a missing library of some sort. Removing the flags gives me errors like the following:
OculusLib.o:oculusvr_input_OculusRift.cpp:(.text+0x2f): undefined reference to OVR::System::Init(OVR::Log*, OVR::Allocator*)' ending with ../mingw32/bin/ld.exe: OculusLib.o: bad reloc address 0x4 in section .text$_ZN3OVR9Allocator11GetInstanceEv[__ZN3OVR9Allocator11GetInstanceEv]'collect2.exe: error: ld returned 1 exit status
Yes, those libraries are required by the Oculus SDK on Linux.
@abies said:
Are you trying to compile windows version using mingw32 or cross-compile linux version on windows? Depending on that, you are going to need very different approach.
I don’t have experience with cross-compiling from windows but I would let the user build the library in Linux by executing a simple script. The user anyway has to install the Xinerama library by doing apt-get install libxinerama1 (the other three are preinstalled at least on my system, Kubuntu 13.10)
Ok, @yombo, i might have misunderstood you. I was hoping I could crosscompile the linux libs on windows.
I might end up installing ubuntu on a machine and build the lib’s there, instead. Might be simpler in the end.
@abies said:
@yombo - I was asking rickard about crosscompilation, because it looked like he wanted to use linux configuration to build windows version of library...
BTW, why do you require all these libraries for linking? I cannot see any references to them from the OculusLib.cpp
The libraries are used in run-time from the oculus library (libovr.a)
@rickard said:
Ok, @yombo, i might have misunderstood you. I was hoping I could crosscompile the linux libs on windows.
I might end up installing ubuntu on a machine and build the lib's there, instead. Might be simpler in the end.
Okay… sorry for the confusion, I also didn’t think you need the libraries too.
It should be possible to cross-build Linux libs on mingw.
The only downside is that you can test them only on mingw, not on Linux itself. Not a big deal, the differences between mingw and Linux shouldn’t matter, it’s mostly stuff like the presence or absence of filesystem paths.
Implemented more native methods, reset and predictive.
Replaced the euler angles with proper Quaternion. Feels smoother!
You no longer need to initialize the OculusRiftReader in a static context (thanks to rupy for making me look at the JRift implementation and realizing there’s actually a bug in the SDK (or so it seems?))
I’ve decided to use your library since you keep updating it, and I’ve managed to make it work in Linux without modifying your sources (OculusRift.java and the .h and .cpp files, I only use that)
(Sorry about the ugly directory variables)
It generates the libOculusLib.so library file.
You can ommit the -lpthread -lX11 -lXinerama -ludev in the linker line, the .so becomes smaller but it seems to work without them, though it could be necessary to have them installed, i don’t know
Then I load the libOculusLib.so library in java with this, as in your win32 case:
System.loadLibrary( “OculusLib” );
(It adds the “lib” and the “.so”)
I still have to make the distortion shaders in my engine…
@rickard said:
Thanks for this!
I'll look at this and upload the results as soon as I have time.
Oh no! I forgot something (and have lied)
I DID a modification in the .cpp, as the conio.h header is not available in Linux. Substituting it for memory.h compiles flawlessly.
Sorry!
Since I had some spare time today, I wanted to try this out again!
I get some problems though, that you hopefully can help me with…
I pull the latest source jmonkeyengine-oculus-rift from the svn repo.
Open in jMonekyEngine SDK 3 stable.
Pull the latest jME3 source from the repo, build, and reference jME3-core.jar and jMonkeyEngine.jar
But i get an errors when i try to build:
ant -f C:\code\OculusRift\jmonkeyengine-oculus-rift clean jar
C:\code\OculusRift\jmonkeyengine-oculus-rift\nbproject\build-impl.xml:64: Source resource does not exist: C:\code\OculusRift\jmonkeyengine-oculus-rift\nblibraries.properties
BUILD FAILED (total time: 0 seconds)
I’ve only built it from my own sources, so I can’t say. It might have to do with how you set up the project, I guess. Did you try to build with the build.xml that is commited?
I actually made a plugin for the project, but never got around to submitting it. I’ll put that down on my list too.
Hello guys, recently I always get this error when trying to run the program:
java.lang.ArrayIndexOutOfBoundsException: 6
This is because the data at (OculusRiftReader.java:111) only have 6 index (0-5).
I found that in the oculusvr_input_OculusRift.cpp the data var is only initialized with 6 data[6], shouldn’t it be 7 ?
How to fix this Problem?
@monyet said:
Hello guys, recently I always get this error when trying to run the program:
java.lang.ArrayIndexOutOfBoundsException: 6
This is because the data at (OculusRiftReader.java:111) only have 6 index (0-5).
I found that in the oculusvr_input_OculusRift.cpp the data var is only initialized with 6 data[6], shouldn't it be 7 ?
How to fix this Problem?
Thanks a lot
Hi, are you building the c++ sources yourself? If so, I might have missed to update those the last time. It seems the var was indeed initialized with 6 items.
I think the jar should be up to date, but let me know if that is the problem.
So I just use eclipse and link your whole project as a project in the build path. And this error just keep on coming.
I didn’t try to rebuild the c++.
Currently I use the older revision and it works.
Thanks Rickard.
Seriously, it sounds like you want to judge the Rift by what the browser displays, and I doubt that that’s a good basis since you’re under binocular darkroom conditions with the headset on.
Besides, display technology for the consumer version will have a much higher resolution, and it might even change display technology (OLED is good, but IPS might be cheaper so the budget can accommodate other, more important improvements elsewhere… etc. etc. etc.)
