OpenNI Cookbook: Learn how to write NIUI-based applications and motion-controlled games

In this chapter, we will introduce primary datatypes of the OpenNI and the NiTE along with some basic information about how to access and select a data stream. Then we will try to show you some examples of events triggered by devices such as connecting or disconnecting an OpenNI supported device from computer.

But first, let's get some background about the whole OpenNI's principle first.

In this recipe we will show you how to prepare a project in Visual Studio to start programming with OpenNI 2 and NiTE 2. Using NiTE 2 is optional but it will offer following features to you::

Without NiTE, we can only use low-level data such as the output of different physical sensors of one or more devices.

We will show how to create and initialize a context object in C++ and how to use the openni::Status datatype to handle errors thrown by OpenNI core. We will use openni::Status very often in the later recipes and it is a very important part of any successful application.

In this recipe, we try to show the version number of the current OpenNI environment and then initialize the OpenNI framework. This will ask OpenNI to search for any connected device and load their modules and drivers.

We learned how to initialize OpenNI and how to retrieve the version number of OpenNI using the openni::OpenNI::getVersion() method and how to ask OpenNI to read all modules and drivers by calling openni::OpenNI::initialize() in the last recipe. In this recipe we will get the list of all the connected devices, their hardware Uri (location), and product ID (that can be used to identify the device).

int _tmain(int argc, _TCHAR* argv[])
{

char ReadLastCharOfLine()
{
  int newChar = 0;
  int lastChar;
  fflush(stdout);
  do 
  {
    lastChar = newChar;
    newChar = getchar();
  }
  while ((newChar != '\n') && (newChar != EOF...

In OpenNI 2 there is only one class that is responsible for giving us access to the output of all video-based sensors (depth/IR/RGB) that have made our work very simple compared to the OpenNI 1.x era, where we needed to use three different classes to access sensors. In this recipe we will show you how to access the depth sensor and initialize it. For accessing the IR sensor and RGB sensor we need to follow the same procedure that we will discuss more in the How It Works… section of this recipe. We will show you how to select an output video mode for a sensor too. Also we will show you how to ask a device to see if an output is supported or not.

We will not cover other configurable properties of the openni::VideoStream class including cropping and mirroring in this recipe; read Chapter 4, More about Low-level Outputs about this topic.

From the previous recipe we learned that we can use different video modes for the sensor's output, different resolutions, fps, and pixel formats. We also wrote a table of known supported resolutions and pixel formats. But in case you want to be sure about the list of supported types or if you have a new device and want to know the possible resolutions and pixel formats of one of its sensors, you can easily ask device driver. OpenNI gives us this possibility to retrieve a list of supported video modes for each sensor from the driver itself. In this recipe, we will try to show you how to retrieve a list of supported video modes for the Depth sensor and we will let the user select what video mode to use for our sensor.

We discussed about how to retrieve a list of connected devices but we never used this data to select one of those devices; we always used ANY_DEVICE as the parameter for the openni::Device::open() method without even asking ourselves what this parameter is.

In this recipe, we will show you how to select your desired device and open it. Then create openni::VideoStream for the depth sensor of this device.

But first let's talk about the openni::Device::open() method. Actually this method has a parameter of type string (actually a character array) containing the hardware location (Uri) of the desired device. We always used ANY_DEVICE as the parameter of this method until now, but actually ANY_DEVICE is equal to null and is used only for better reading of code. When passing null as the parameter of this method, OpenNI automatically selects the first device in the list of loaded and recognized devices. So if we want to select our desired device...

We learned how to get a list of connected devices from OpenNI, but here we want to use one of the new features of OpenNI 2. OpenNI 2 lets us introduce two methods that we want to be executed when there is any new device connected or disconnected. Using this ability we want to define two methods and introduce them to OpenNI as a callback for these two events (connect and disconnect). Our methods will only print a line to the console to show the user what happened, but you can use this feature to wait until the user connects a device or warn the user when a device is disconnected; or you can at least update the list of connected devices without using a timer to refresh it.

Prior to the Selecting a specific device for accessing depth stream recipe of this chapter we used ANY_DEVICE as the parameter of the openni::Device::open() method to open the first device and access its sensors. In the Selecting a specific device for accessing depth stream recipe of this chapter we learned that we can select what device to open by sending its hardware Uri to the openni::OpenNI::open() method. And in this recipe, we will learn another use of the openni::OpenNI::open() method.

You will find out how to record data from different sensors of a device to a file in the later sections of the chapter, but now we want to show how to re-open them as an individual device (just like when we open a physical device) and access saved data streams).