We’re levaraging NuiTrack SDK, and we’ve found a few issues.
First of all, we’re using nuitrack.net.dll , it’s the only API we’re using.
Given that you have more than one sensor connected (let’s say, an Astra an a D435), how do you select which one to initialize?
For what is ‘Nuitrack.Init(string)’ config parameter is used exactly? I recall seeing that you can pass a path to the directory in which nuitrack is installed… does it mean that if use that, I don’t need to set the enviroment variable NUITRACK_HOME?
We also got this issue:
With no compatible sensor connected to the computer, I expected ‘Nuitrack.Init("")’ to throw an exception; instead, it just executed fine.
Immeditely after, ‘DepthSensor.Create();’ was executed and threw ‘System.AccessViolationException’ which is an exception that cannot be catched and forces program termination, which is not very user friendly.
There is NO way currently to select the sensor that should be connected - ASTRA will always be selected before INTEL.
Yes the string you pass to Init("") can be the FULL path to a nuitrack.config file. As in:
c:\nuitrack\data\nuitrack.config
You may however need to update some of the paths in the nuitrack.config file itself - as there seemed to be a bug at one point that resulted the licence file and the middleware files not being found correctly.
Once done YES that executable would bypass the need for the NUITRACK_HOME file - HOWEVER - each installation of nuitrack requires a licence file that must be activated on the target computer - as the file is bound to the hardware - and to the sensor according to the documentation.
For this activation to work - you MUST still have NUITRACK_HOME setup and the PATH environment variables setup correctly as well.
So the net result of using Init(“c:\nuitrack\data\nuitrack.config”) may be somewhat limited.
And more to the point - each build of nuitrack regularly makes core changes to the contents of the config file - so we tend to avoid making any changes to that file at all.
If you want to make changes in the config - doing them at runtime using the SDK setConfigValue(“key”,“value”); method is more reliable.
Init() is a pretty weird method at times … but technically I guess its not really an exception if the system does not find a valid device.
The real issue that we have right now - its that there is no way to KNOW this - or to KNOW what device is actually connected.
Something as simple as the ability to call methods like Nuitrack::isConnected(); and Nuitrack::getConnectedDevice(); would solve so many issues.
In the c++ sdk we put a try/catch around all nuitrack calls to get around this sort of error - but the issue here is that since .net 4.0 the default for “AccessViolationExceptions” was changed - basically .net used to catch these exceptions but now it doesn’t.
If you need a hack to make it work right now - could be something like this - which creates an unsafe wrapper for calls that may have potential AccessViolationException issues.
[HandleProcessCorruptedStateExceptions]
public void createNuitrackModules()
{
int Stage = 0;
try
{
Stage = 1;
_depthSensor = DepthSensor.Create();
Stage = 2;
_colorSensor = ColorSensor.Create();
Stage = 3;
_userTracker = UserTracker.Create();
Stage = 4;
_skeletonTracker = SkeletonTracker.Create();
Stage = 5;
_handTracker = HandTracker.Create();
Stage = 6;
_gestureRecognizer = GestureRecognizer.Create();
Stage = 7;
}
catch (AccessViolationException e)
{
// You should really terminate your application here
// As the system state is potentially suspect - but at least you can now do it elegantly.
}
}
In the c# API, if we try to initialize NuiTrack while NO sensor is connected, this is what happens:
NuiTrack.Init(""); call passes. I would have expected an exception here.
DepthSensor.Create(); throws System.AccessViolationException, which cannot be catched with a try catch block, resulting in an unexpected application crash.
What would I expect: whenever something’s wrong, throw an exception that can be controlled and redirected.
Exceptions like System.AccessViolationException are, by nature, uncontrollable and in the best case they produce unexpected results, and catastrophic crashes at worst.