SteamVR and NoloVR on iOS
I am the author of the iOS SteamVR HMD software, iVRy. I have been trying for weeks to make contact with this company so that I can add native NoloVR support to my software, with no luck. Is this company still in business? Does anyone have any idea how to get them to respond? The best I've got is some kind of "we'll get back to you" via the Facebook page, but no actual contact from the company itself. I have many users of my software asking for NoloVR tracking support, but without getting the hardware and some kind of SDK, it's obviously impossible...
iVRy on the App Store:
https://itunes.apple.com/us/app/ivry/id1210129937
iVRy on the App Store:
https://itunes.apple.com/us/app/ivry/id1210129937
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
You can install the drivers on you PC without the NOLO hardware if you want to test your implementation.
you can find all SDK in
https://github.com/NOLOVR
and my email is :zhenze@lyrobotix.com
you can also take the message in github issue.
the best place maybe github or email or other way you would like
1) Why do you use "busy waiting" in your thread that reads from the NoloVR hardware? Is there no method available in your runtime to get callbacks or notifications when new position data is available?
2) What are you trying to achieve with your "double click menu button" code? A "recenter" type operation?
"1.Currently, there is no calllbacks method,but you can get all data from the method like "get_Nolo_LeftControllerData" in your thread.maybe callbacks is the best way,and we will add it in the future.
2.we want to add some method belong us,we want double system to reset headset marker's yaw.double click menu to turn around in steamVR.
3.yes,We started doing OSVR this last year,we also think this is a old version.and Next step,we want OSVR doing this things by OSVR,not us.
thank you for your suppot"
Are you able to provide documentation on how your runtime talks to ZeroMQ (ie. the protocol)? It seems a better solution (for high performance PC applications) would be to eliminate your runtime and talk directly to the hardware.
I am not happy to put any code into my driver which will degrade its performance, so we need to find a way around this (1) design flaw.
Okey,i have understand your demand, and i will talk to my colleague.
hi, my colleague has update the OSVR-driver code.so please check it.
https://github.com/NOLOVR/NOLO-Others/tree/master/NOLO_OSVR_SteamvrDriver/Source_Code
Are you able to provide documentation on how your runtime talks to ZeroMQ (ie. the protocol)?
I want to bypass your runtime, it is not efficient design or optimal code.
Your colleague's code changes are a minor refactor, doesn't really change anything...
I'm looking for the (ZeroMQ) protocol info so that I can re-implement the runtime myself.
The refactor in the OSVR driver was moving some stuff out of "static globals", which is another programming style that should have died with BASIC.
hi,
we will not provide the ZMQ protocol,and we still use our runtime to docking.
OSVR,Trinus and other all use this runtime.
it is our rule.and we will perfect and Long-term maintenance this runtime.
we will add a callback.test and put it tomorrow.
Do you have any requirements for this callback?
please check
typedef void(*callbackFn)(void* context);
void registerCallback(callbackFn callback, void *context);
This allows the code being called back to provide a pointer (for example to a C++ object) so that there isn't a need for global variables (which are generally a *very bad* idea in modern code). If you had done this in the SDK, you would have been able to avoid the scenario you have at the moment of global flag variables in the OSVR driver.
So, in order for the SDK to be usable in professional, production code written outside of Nolo, you will need to add this functionality to the SDK.
Here is what you would need to change:
typedef void(__cdecl *noloData_FuncCallBackNotify)(NoloData _noloData, void* context);
typedef void(__cdecl *expandMsg_FuncCallBack)(ExpandMsgType expandMsgType, void* context);
typedef void(__cdecl *funcCallBack)(void* context);
However, as you probably don't want to break source/binary compatibility with existing apps/drivers, you will need to add these to your SDK:
typedef void(__cdecl *noloData_FuncCallBackNotifyEx)(NoloData _noloData, void* context);
typedef void(__cdecl *expandMsg_FuncCallBackEx)(ExpandMsgType expandMsgType, void* context);
typedef void(__cdecl *funcCallBackEx)(void* context);
NOLO_API bool _cdecl disConnect_FunCallBackEx(funcCallBackEx fun, void* context);
NOLO_API bool _cdecl connectSuccess_FunCallBackEx(funcCallBackEx fun, void* context);
NOLO_API bool _cdecl expandDataNotify_FuncCallBackEx(expandMsg_FuncCallBackEx fun, void* context);
NOLO_API bool _cdecl noloDataNotify_FuncCallBackEx(noloData_FuncCallBackNotifyEx fun, void* context);
The context (which can be NULL) passed to the callback would be the context passed to the function that registers the callback eg.
class Object
{
private:
bool _connected;
static void connectCallback(void *context)
{
Object *that = reinterpret_cast<Object*>(context);
that->_connected = true;
}
public:
Object::Object()
{
_connected = false;
connectSuccess_FunCallBackEx(connectCallback, this);
}
};
https://github.com/NOLOVR/NOLO-Windows-SDK/issues/2
At the moment, I will develop test versions of my driver using a hard-coded path for the NoloVR DLLs. I won't ship a product like this, nor will I introduce dependencies or 'bloat' to my driver (and I suspect neither will any other serious VR developers).
So, (easiest) the Nolo installer writes a value to the registry containing the path to the NoloVR DLLs. The driver/app queries the registry, finds the path of the driver and then loads it. Afterwards it can do detection checks to determine if Nolo hardware is actually attached.
In any case, this will be better for you, as you really only want 1 copy of a Nolo DLL on the system (the copy the user installed with the driver). You don't want to be in the situation where you have each app having a different version of the Nolo DLL, none of which match the version installed with the (latest version of) the driver.
https://github.com/NOLOVR/NOLO-Windows-SDK/issues/3
Please let me know when you have a working version (ie. DLL matches header files) of the SDK and I will resume my work.
Thanks.
https://github.com/NOLOVR/NOLO-Windows-SDK/issues/4
In the first test version of the driver, I'm reading the Nolo data whenever I get a motion update from the HMD sensors, and then "fusing" the Nolo position data with the headset's rotational data. This works well, but obviously isn't optimal, as the timing of the headset sensor data is not matched to the sample frequency of the Nolo hardware.
So that I can continue work on the integration, I've implemented a simulator for the HMD data callback. In the simulator the driver reads the NoloVR hardware at 100Hz, and calls the callback with data. This is just for testing, the release version of the driver that has Nolo support will check for the presence of the noloDataNotify_FuncCallBack() export and fall back to the first method above if it's not available.
I've put all of the NoloVR integration into a C++ class that hides all of the details of the Nolo SDK, and will scan the user's hard drives for the location of the Nolo libraries (for now) and load them dynamically. I will probably need to do a USB device check to see if the Nolo hardware is attached so that I can avoid looking for the libraries on a system that doesn't have NoloVR.
I expect that I will release the new version of the iVRy driver with NoloVR support in the next few days, and will update it with new versions of the Nolo SDK when they become available. It seems that the driver will need to maintain (at least until Nolo reaches 1.0) backwards compatibility with earlier SDK versions, to give users the option to choose whichever NoloVR driver version works for them.