SDK and development

Hi,

Do you have plans to provide a SDK for developers? It could be great to have a C API allowing us to create some content for the headset. I think that a plugin for OSVR could be awesome. The Pimax 4K doesn’t have position tracking nor motion controllers. However with an OSVR plugin, it is possible to use the headset with Kinect (OSVR-Kinect plugin) and all sort of motion controllers.

If you want to talk about that, feel free ton ping me :wink:

Thanks

There is a c++ SDK, in this thread you’ll find references to the original thread: http://community.openmr.ai/t/developing-in-c-for-pimax-4k-hmd/710

Thanks a lot! I have downloaded it, it contains an Unity and Unreal plugins, also a C interface. Do you know if there are docs somewhere?

No there isn’t. Here’s a post where I’ve deciphered myself some stuff, haven’t even tried it myself though yet:

http://community.openmr.ai/t/developing-in-c-for-pimax-4k-hmd/710/26?u=sjefdeklerk

Hi,

Thanks but I’ve a question. I try to create a plugin for OSVR (C++), I’ve imported the PVR_API.h file, but where are the DLL for the linker?

I can’t build my project because of this error

1>com_osvr_pimax4k.obj : error LNK2001: symbole externe non résolu g_pvr_interface
1>com_osvr_pimax4k.obj : error LNK2001: symbole externe non résolu g_pvr_client_dll

Also why don’t you directly call pvr_initialise() ?

Thanks for your help :wink:

Search your C drive for libPVRClient

I have a 64 bit version in: C:\Program Files\Pimax\LibPVRClient64.dll
And 32 bit version in C:\Windows\System32\LibPVRClient32.dll
and same 32 bit version in: C:\Windows\SysWOW64\LibPVRClient32.dll

Use the 32/64 bit version depending the program you intend to develop. Although I think you should use the 64 bit version if you’re on a 64 bit platform: in PVR_types,h it defines PVR_PTR_SIZE according to your OS. You could try setting it there to 4 (=32 bit) manually and use the 32 bit dll. But I’m not sure if that works.

“Also why don’t you directly call pvr_initialise() ?”

Look at PVR_interface.h. In pvr_initInterface() you see that it uses this function to retrieve the interface into the DLL. It then stores it internally and after that you can call pvr_initialise(). If you call pvr_initialise() without having called pvr_initInterface() I’m 100% sure it will crash.

Yes but look at the pvr_initialise() function, it calls pvr_initInterface in all case, so you can start by calling pvr_initialise no?

static PVR_FORCE_INLINE pvrResult pvr_initialise() {
	pvrResult ret = pvr_initInterface();
	if (ret != pvr_success) {
		return ret;
	}
	return __g_pvr_interface__->initialise();
}

Thanks for the dll location! I hope to give you some cool news soon

You’re totally right ! LOL I missed that :wink: No need to call it manually, just start with pvr_initialise(), the call is included already.

Good luck, let me know how it goes ! I’m currently working on reverse engineering the FW myself, but I might mess around with the SDK too at some point.

Also, if you’re planning to develop for Extended mode, keep in mind that in Extended mode the headset simply emulates an Oculus DK2. So for extended mode you could simply use the Oculus DK2 SDK. Keep in mind though that only specific versions of the SDK seem to work with our headset.

Hum, I need a libPVRClient.lib or another library, I can’t directly use the DLL (it’s for the linker), do you know where can I find it?

LIB files are only need when you’re linking statically. For dynamic linking, which happens here, you should not need a .lib file. See also: c++ - What is inside .lib file of Static library, Statically linked dynamic library and dynamically linked dynamic library? - Stack Overflow

“You don’t need a .lib file to use a dynamic library, but without one you cannot treat functions from the DLL as normal functions in your code. Instead you must manually call LoadLibrary to load the DLL (and FreeLibrary when you’re done), and GetProcAddress to obtain the address of the function or data item in the DLL. You must then cast the returned address to an appropriate pointer-to-function in order to use it”

That’s exactly what happens here. The code calls LoadLibrary and then uses GetProcAddress to obtain the address of the “pGetInterface” function. Next it calls this function, which returns the interface. The functions you call next are all part of this interface.

So don’t link the DLL statically. In fact you shouldn’t even tell the linker about the DLL I think. The whole point of dynamic linking is that you create the link to the DLL at runtime. It’s how viruses for example link a DLL to an exe at runtime.

Just make sure that the 32 bit or 64 bit version (depending on your platform) of the DLL is in the same directory as your exe and you should be fine.

Thanks again for all these precious tips :wink:

However I still have this error

1>com_osvr_pimax4k.obj : error LNK2001: symbole externe non résolu g_pvr_interface
1>com_osvr_pimax4k.obj : error LNK2001: symbole externe non résolu g_pvr_client_dll

Have you an idea?

This is my code

Thanks again :wink:

Hehe. Ok. The error is because of a small mistake they’ve made. You need to remove the “PVR_EXTERN_C” twice from "PVR_API.h.

I’ve just tried it and then it compiles fine. It also seems to work since pvr_initialise() returns 0, which is pvr_success.

But, make sure you’re compiling 64 bits if you’re on a 64 bits platform (In VS2015: build/configuration manager go to active solution platform and change into x64). And then make sure the 64 bits version of the DLL is in the same dir as your exe.

1 Like

Ok It works here :slight_smile: This is my code:

#include "stdafx.h"
#include "PVR_API.h"
#include <iostream>
using namespace std;

int main()
{
    int i;
    PvrHmdHandle hmdh;

	if (pvr_initialise() == 0)
		cout << "success initialising" << endl;
  

	if (pvr_createHmd(&hmdh) == 0)
		cout << "success creating hmd" << endl;

         cin >> i;
         return 0;
}

It returns ‘success’ twice, so it created the hmd object successfully. However the device MUST be in pimax mode. If it’s extended mode, the creating of the hmd object will fail. If you want to develop for ‘extended mode’, you should use the Oculus DK2 SDK (make sure to use the correct version).

Thanks! I don’t have any erros but I have removed both PVR_EXTERN_C but I’m not very sure. Can you show me the first lines of your API file please?

I was able to create a simple program that reads the sensor data!

My plugin for OSVR is almost done too. The extended and direct mode will be managed by OSVR.

The best could be to have a native OSVR driver, such as the HDK.

Good work, happy to hear it all works ! Good luck !

BTW Maybe you could share your progress here, I’m sure others would like to see basic code like how to read sensor data. Giving a little back to the community to progress it is always a good thing :slight_smile:

Well it’s very basic but this is the my test program to read the orientation of the HMD

My plugin for OSVR is not yet public because it doesn’t load with the OSVR server. I’m talking with the OSVR team to find the issue.

1 Like

I guess this is all people need, a small example of how to start the API and read sensor data. Happy we cracked that :wink: The more people start developing, the better. I’m still analyzing the FW itself, but I’m not sure if it will lead to anything just yet …

What do you want to do with the firmware? I think that it could be awesome to create a driver for OpenHMD. OpenHMD is a software that doesn’t require the original runtime for running HMD. You can use the Oculus Rift DK1, DK2, CV1 without any Oculus Software. However it’s extended mode only.

I think that a native driver for both OpenHMD and OSVR could be great. The current software just works, but it’s NOT optimized. Because it’s closed source, we can’t improve it.