Archived source · macOS · 2010

cocoaKinect.app

A native macOS viewer for the Microsoft Kinect, built straight onto libfreenect. It turns the depth stream into a point cloud or a triangle mesh in real time, and writes the result out as PLY or STL.

A person rendered as a dense triangle mesh of thousands of small quads, shaded green through yellow to brown by distance from the sensor, against a black background.
Mesh mode. Each vertex is one depth sample, projected into world space in the vertex shader and coloured by distance. The grid density is the detail setting, which decimates the 640×480 sample grid before triangulating it.

The depth colormap

2048 depth values, one colour ramp

The Kinect reports depth as an 11-bit number. The app builds a 2048-entry lookup texture at startup and shades every sample through it. This is that exact ramp, regenerated from the code that builds it:

Notice that it runs out. The ramp applies a cubic gamma, so the whole visible spectrum is spent by roughly value 1150 and everything beyond it clips to black. That is why the app carries near and far clipping controls: without them, most of the sensor's range renders as nothing at all.

What it does

Capabilities

Provenance

Whose work this is

cocoaKinect was written in November 2010 by Robert Pointon (fernlightning) as a demo for the OpenKinect community. It is not the work of the person maintaining this archive. All credit for the application code goes to the original author, whose own notes are preserved in the repository verbatim.

The application code carries no formal licence: main.m says "All rights reserved", while the author's notes grant permission informally — "frankly I don't care what you do with this code, hopefully you'll be nice and add me to your credits". That is a statement of intent, not a licence, so no LICENSE file has been added here. The maintainer is not the copyright holder and cannot license someone else's work.

The vendored dependencies do carry formal licences. libfreenect is Apache-2.0 or GPL-2.0 at your option; libusb is LGPL-2.1. Their terms and obligations are set out in THIRD-PARTY-LICENSES.md, which is worth reading before redistributing any of it.

Since 2010

What was fixed

The first commit is the source as received, reorganised and nothing more. Work applied on top of it falls into two piles.

Speed

The per-pixel depth clamp was making up to seven Objective-C message sends and two fmod() calls on each of 307200 pixels, every frame. Hoisting the accessors and replacing the modulo with the loop's own column index:

Measured on an Apple Silicon Mac, 200 frames per configuration.
Per frameBeforeAfter
Depth clamp4.69 ms0.71 ms6.6×
Mesh indices0.087 ms0.019 ms4.6×
Allocator1.5 MBnonereused

Both rewritten loops were checked against the originals across 960 randomised parameter combinations, and produce byte-identical output.

Defects

The export actions waited for a frame in a loop with no exit. With no device streaming, that pinned a CPU core on the main thread and froze the interface permanently — and nothing disabled the menu items, so it was two clicks away.

The binary STL writer counted facets in a pointer variable, so the arithmetic advanced in units of eight bytes and the file header announced eight times as many facets as it wrote.

Shader compile failures were logged by passing an NSString * to a %s format, which reads the object pointer as a C string: garbage or a crash, on the one code path whose job is to report shader errors.

Building

It still compiles

Open src/cocoaKinect.xcodeproj and build the cocoaKinect target. On an Intel Mac it builds and runs.

On Apple Silicon it will not link as it stands. The vendored libusb binaries are x86_64 only:

$ lipo -info src/libusb-1.0/lib/libusb-1.0.0.dylib
Non-fat file: ... is architecture: x86_64

They have to be rebuilt or replaced with a universal build first. Continuous integration on the repository parses and type-checks the sources against the current macOS SDK on every change, which catches anything that stops them being valid Objective-C — but it does not build the app, and nothing here has been run against Kinect hardware.