https://openkinect.org/w/api.php?action=feedcontributions&user=Slomp&feedformat=atomOpenKinect - User contributions [en]2024-03-29T09:20:56ZUser contributionsMediaWiki 1.30.0https://openkinect.org/w/index.php?title=Installation/Compilation_Guides&diff=887Installation/Compilation Guides2010-12-26T18:37:31Z<p>Slomp: </p>
<hr />
<div>THE GUIDE FOR UTTER NEWBIES (like me) as of 11/29/2010<br />
<br />
<br />
== Instructions for OSX ==<br />
<br />
<br />
If you want to get ofxKinect up and running as quickly as possible, you'll need the latest Xcode (3.2.5 right now, please note this is a 3.5GB download that may take hours) and either version 61 or 62 of openFrameworks. Here's how I got Theo's ofxKinect demo and Dan Shiffman's Processing demo running in 10 minutes after struggling with manual builds for hours:<br />
<br />
Plug in the Kinect - you may have to unplug and replug, close Xcode and start again to get it going - flashing green means it's still waiting to connect.<br />
<br />
Download Theo's ofx project here:<br />
<br />
https://github.com/ofTheo/ofxKinect<br />
<br />
Drop the whole folder into the openFrameworks folder of_preRelease_v0061_osxSL_FAT in /apps/examples<br />
<br />
---> Make sure you you have the LATEST Xcode, version 3.2.5 <--- This was my mistake, easy if you have it.<br />
<br />
Go into Theo's folder (currently called ofTheo-ofxKinect-78ad750) and find ofxKinect.xcodeproj<br />
<br />
Double-click on that, when it opens in Xcode hit build and run. It'll take a minute or so.<br />
<br />
That's it. It's a start. Shiffman's Processing app now works (you'll need Processing 1.2.1), as does the TuioKinect app (but not the Xcode project, for some reason).<br />
<br />
Good Luck! - Dave Pentecost (MacBook Pro, 10.6.4)<br />
<br />
<br />
== Instructions for Windows ==<br />
<br />
Refer to: http://openkinect.org/wiki/Getting_Started_Windows<br />
<br />
<br />
== Instructions for Linux ==<br />
<br />
'''RedHat/Fedora''' (based on http://openkinect.org/wiki/Getting_Started - sections should probably be synchronized)<br />
<br />
This is what was needed to get the glview libfreenect demo working on a non-developer Fedora 12 workstation:<br />
<br />
'''install necessary RPMs'''<br />
$ su<br />
$ yum install git cmake gcc gcc-c++ libusb1 libusb1-devel libXi libXi-devel libXmu libXmu-devel freeglut freeglut-devel<br />
$ exit<br />
<br />
'''create a location for your repository'''<br />
$ cd /tmp<br />
$ mkdir kinect<br />
$ cd kinect<br />
<br />
'''clone the repo'''<br />
$ git clone https://github.com/OpenKinect/libfreenect.git<br />
$ cd libfreenect<br />
<br />
'''cmake'''<br />
$ mkdir build<br />
$ cd build<br />
$ cmake ..<br />
$ make<br />
<br />
'''testing'''<br />
$ su<br />
$ cd bin<br />
$ glview<br />
<br />
Once glview launches, press 'w' to tilt the Kinect up, 'x' to tilt the connect down, or 's' to return the Kinect to level. Pressing '0' to '6' changes the color of the led on the face of the Kinect.<br />
<br />
Sometimes you may have to kill glview & restart to make it work.</div>Slomphttps://openkinect.org/w/index.php?title=Code_Integration&diff=879Code Integration2010-12-23T22:23:40Z<p>Slomp: </p>
<hr />
<div>== Open Kinect Repo Policy ==<br />
<br />
In an effort to keep up with the additions from the community while<br />
keeping a clean and usable source history in git, we've established a<br />
policy on merges to the main repository. This integration policy will<br />
hopefully make it easy for us to find bug and figure out where new<br />
features come in, while also keeping conflicts with new and ongoing<br />
development to a minimum.<br />
<br />
<br />
=== Git Basics ===<br />
<br />
For a good overview of git, check out<br />
<br />
* http://wiki.freegeek.org/index.php/Git_for_dummies - Quick overview of how to use git and why it's awesome<br />
* http://progit.org - In depth book on git, most everything you could ever want to know without getting deep into the internals<br />
* http://gitready.com/beginner/2009/01/21/pushing-and-pulling.html - ''A picture is worth a thousand words...''<br />
* http://blip.tv/file/4045262 - ''...and a video is worth a thousand pictures!''<br />
<br />
=== Workflows ===<br />
<br />
These are terse descriptions of our expected workflow. For a plain english description of how we use git, check out the Developer Story portion below.<br />
<br />
==== Developer workflow ====<br />
<br />
* Developer clones repository<br />
* Developer makes a new branch to work on feature with. Master branch should be reserved for upstreams unless developer knows what they are doing with git.<br />
** git checkout -b [new feature branch name] master<br />
* Developer makes changes to feature branch, signing off on every commit.<br />
* Developer submits feature branch via pull request or patch filed as project issue.<br />
* Once patch is merged to main repo, developer updates from remote repo and merges main repo into their master.<br />
* Developer then makes new branch off master, continues on new feature.<br />
* If developer has another feature they have worked on between the time they have submitted, needed commits can be cherry picked to new branch.<br />
<br />
==== Integration workflow ====<br />
<br />
Whenever an integrator brings in a new commit, it should be rebased to the head of the master branch on the main repo. However, due to the volume of pull requests and patches we're receiving, this may not always be the case for pull requests. This workflow makes sure we maintain linearity in the main repo while also not changing code out from under developers<br />
<br />
* Integrator receives pull request or patch<br />
** If pull request, integrator makes sure it is rebased. <br />
*** If not rebased, and developer is in IRC channel, talk to developer there to have them properly rebase. If developer is not in IRC channel, integrator pulls to local repo and rebases. If conflicts arise, notify developer via pull request comment.<br />
** If patch, integrate on top. If conflicted, contact developer via github issue comments.<br />
* Integrator merges patch into main branch. Should always come in at head if rebase was successful.<br />
* Integrator pushes to main repo<br />
<br />
== Development Story ==<br />
<br />
=== Introduction ===<br />
<br />
Before we begin, it's very worth getting up to speed on git at<br />
<br />
http://progit.org<br />
<br />
I'll be covering git operations here, but not going into too much<br />
detail. The Pro Git book site covers everything in hideous, yet<br />
readable and understandable detail.<br />
<br />
=== WHY ARE YOU MAKING THIS SO HARD I JUST WANT TO CODE ===<br />
<br />
So, you've decided you want to develop on an OpenKinect project. Yay!<br />
We need all the help we can get. As project maintainers, We want to<br />
make sure that everyone's help is both attributed and commited<br />
correctly, as well kept in line with everyone else that's trying to<br />
help. That's why we've created our development and integration<br />
workflows, listed above. We realize these lists are somewhat opaque to<br />
people not familiar with git or development using distributed systems,<br />
so this portion of the document is a plain-english explanation of how<br />
development of new features should work on OpenKinect repositories.<br />
<br />
To see what we're trying to avoid doing, check out the example and<br />
explanation at<br />
<br />
http://blog.xebia.com/2010/09/20/git-workflow/<br />
<br />
or even worse<br />
<br />
http://blog.spearce.org/2007/07/difficult-gitk-graphs.html<br />
<br />
This tutorial will also assume that you've created a github account<br />
and are using github for your repo storage. If you aren't, it is<br />
assumed you know what you're doing, so you can skip the github<br />
steps.<br />
<br />
=== Starting Development ===<br />
<br />
The first thing you'll do as a developer is make your own fork of our<br />
repository. For those familiar with other code versioning systems,<br />
this isn't as serious as it sounds. Forking is a core practice of git,<br />
since everyone has their own repo.<br />
<br />
To fork on github, sign into your account, go to <br />
<br />
https://www.github.com/OpenKinect/libfreenect<br />
<br />
and hit the "Fork Repo" button. This will cause the current state of<br />
the repo to be copied to your account, and you will now have a<br />
libfreenect repo available to work on. Once this is done, open up a<br />
terminal and run:<br />
<br />
git clone git@github.com:[your_account_name]/libfreenect.git<br />
<br />
This will bring the git repo to your file system, and set up your repo<br />
as a remote named "origin". Unlike centralized versioning systems, git<br />
allows you to set up multiple repositories you can sync with. In our<br />
case, you'll want to sync with the main OpenKinect repo too. So, while<br />
your "origin" will be your fork of the OpenKinect repo, you'll want to<br />
add the main OpenKinect repo as another remote. This can be done by<br />
running:<br />
<br />
git remote add upstream git://github.com/OpenKinect/libfreenect.git<br />
<br />
in the repo clone you just made. Now if you run<br />
<br />
git remote show<br />
<br />
You'll see you have two remotes<br />
<br />
* origin - Your own fork of our main repo<br />
* upstream - The main repo<br />
<br />
You will have read/write access to the origin remote, but only read<br />
access to the upstream remote. This means you can push changes to your<br />
own copy of the repo, but can only read changes from the main<br />
repo. Changes to the main repo have to be made by the repo integrator,<br />
which we'll talk about later.<br />
<br />
=== Keeping up to date with the main repo ===<br />
<br />
Now then, you'll want to have a branch in your repo that's kept up<br />
with the latest changes from the upstream remote. This is how you will<br />
be able to integrate changes made by other people into your work, and<br />
what you will need to base your changes off of when you submit changes<br />
to us. We'll use the "master" branch of your repo for this. So the<br />
latest commit on your master branch should always match the latest<br />
commit on the upstream master branch. If it happens that at some point<br />
it doesn't, we'll talk about how to fix that later.<br />
<br />
Since your current master is cloned from your repo, which was forked<br />
from the upstream repo, your master and the upstream master should<br />
still match in terms of latest commit. However, to make sure, run<br />
<br />
git remote update<br />
<br />
You should see git try to get updates from origin and upstream. This<br />
means it's checking both of those remote repositories for any changes,<br />
and downloading them to their respective remote sandboxes. Doing a<br />
remote update doesn't change any of your local branches, it just<br />
changes what your repo knows about where the remote repos are and what<br />
updates they have. If you see there are changes with the remote<br />
repository, you can do<br />
<br />
git checkout master<br />
git merge upstream/master<br />
<br />
Which tells your repository to merge what's in the upstream's master<br />
branch to your local repo master branchh. This will keep you up to<br />
date with everyone else's changes.<br />
<br />
=== Making your own changes ===<br />
<br />
Once you've made sure you're got a place that's up to date with the<br />
upstream, it's time to start making changes. First off, you'll want to<br />
make a branch off of upstream:<br />
<br />
git checkout -b [feature-branch-name] master<br />
<br />
I'm not going to cover the process of how commits work here, as that's<br />
covered quite well in other basic git tutorials. Also, please make<br />
sure to read about how to sign off on your commits at the<br />
[[Contributing Code]] page.<br />
<br />
However, there's one thing we require that probably doesn't come 'til<br />
later chapters in the git book. We always want your changes to be<br />
'''on top of''' the upstream changes. So, for instance, let's say<br />
you're ready to start a new feature, and the commit chain of the<br />
upstream repo look like<br />
<br />
A -> B -> C<br />
<br />
(I'm using letters here to represent the SHA1 commit hashes)<br />
<br />
So, C is the current latest change in the upstream repo. You start<br />
making commits on top of this in your feature branch, and get<br />
something that looks like<br />
<br />
A -> B -> C -> D -> E<br />
<br />
So upstream was at C, and you added commits D and E. However, while<br />
you're doing your work, other people have submitted their finished<br />
work, and it's come into the upstream. So the next time you do<br />
<br />
git remote update<br />
git merge upstream/master master<br />
<br />
Upstream now looks like<br />
<br />
A -> B -> C -> F -> G<br />
<br />
Which means your branch and upstream now differ by two commits,<br />
respectively. You have commits D and E, it has commits F and G. Since<br />
the upstream repo should be the reference repo, we want to get your<br />
commits up on top of what's on the upstream repo. This is done by an<br />
operation called "rebasing", because we want to change the "base" of<br />
your D and E commits from commit C of the upstream repo to commit G.<br />
With your feature branch currently checked out, this is done via the<br />
command<br />
<br />
git rebase master<br />
<br />
This peels your commits off of your branch, finds the common ancestor<br />
(commit C), so it starts at<br />
<br />
A -> B -> C<br />
<br />
merges in commits from the upstream, so we have<br />
<br />
A -> B -> C -> F -> G<br />
<br />
then starts replaying your commits on top of that, so we get<br />
<br />
A -> B -> C -> F -> G -> D<br />
<br />
Now, if there's a conflict in D, it'll stop at this point, as you to<br />
fix it, and tell you how to continue or stop the process. Otherwise,<br />
it'll keep going, and we end up with the IDEA OF:<br />
<br />
A -> B -> C -> F -> G -> H (formerly D) -> I (formerly E)<br />
<br />
D is pretty much equal to H, and E is pretty much equal to I. However,<br />
since they're at different places than they started, git calls them by<br />
different IDs now. So while the contents of the commits are the same,<br />
their positions in history are different, so they get new and<br />
different IDs.<br />
<br />
Anyways, what we end up with is what the integrator would like to see<br />
when getting your commits.<br />
<br />
=== Getting your changes integrated ===<br />
<br />
Check out [[Contributing Code]] to see how to get your changes<br />
integrated.<br />
<br />
=== Dealing with our integration process ===<br />
<br />
Once you've submitted your code to us, we'll try to integrate it as<br />
soon as possible. However, it's quite rare that we get one integration<br />
request at a time. Usually, we integrate 3+ patches in a go, which<br />
means your code, while being rebased up to the latest of what you know<br />
the repo to be, may not be current by the time it comes in, because<br />
we're making changes quickly. So, you submitted <br />
<br />
A -> B -> C -> F -> G -> H -> I<br />
<br />
to us, but we're integrating patches before yours, and we now have <br />
<br />
A -> B -> C -> F -> G -> J -> K -> L<br />
<br />
At this point as integrators, we have two choices:<br />
<br />
* We could kick your patch request back and wait for you to send us a merge with an update<br />
* We can rebase your stuff ourselves. <br />
<br />
As of this writing, we're taking a workflow that looks like this:<br />
<br />
* We'll try and rebase your stuff<br />
* If it conflicts, we kick the pull request back to you to fix or tell us to fix, because we don't want to change commits with your name signed to it without your approval.<br />
* If it doesn't conflict, we merge the newly rebased code.<br />
<br />
This means that when your stuff is merged, it may come in with ids you<br />
aren't expecting. In the above case, to review, you sent us<br />
<br />
A -> B -> C -> F -> G -> H -> I<br />
<br />
We were already merging and had<br />
<br />
A -> B -> C -> F -> G -> J -> K -> L<br />
<br />
Now we've taken your H and I and put them on the end of that and due<br />
to how rebasing works we have<br />
<br />
A -> B -> C -> F -> G -> J -> K -> L -> M (formerly H) -> N (formerly I)<br />
<br />
So, when you do a <br />
<br />
git remote update<br />
git merge upstream/master upstream<br />
<br />
next, your upstream will look like<br />
<br />
A -> B -> C -> F -> G -> J -> K -> L -> M -> N<br />
<br />
However, since integration isn't instantanious but you may want to<br />
work on new features with the work you've gotten done currently while<br />
waiting for us to integrate, you may've gone off and made a new branch<br />
that looks like<br />
<br />
A -> B -> C -> F -> G -> H -> I -> O -> P -> Q<br />
<br />
Of course, H and I are in the main repo now, but now they're called M<br />
and N instead. Git can figure this out for itself and will make sure<br />
not to reapply like patches. So, if you rebase, you'll get:<br />
<br />
A -> B -> C -> F -> G -> J -> K -> L -> M -> N -> O -> P -> Q<br />
<br />
=== I accidentally commited to my upstream tracking branch, what do I do? ===<br />
<br />
By "upstream tracking branch" here, we mean whatever branch you're<br />
trying to keep synchronized with the upstream master. In the case of<br />
this document, that's your local master.<br />
<br />
First off, don't panic. Git makes it pretty hard to lose changes that<br />
are already commited. We just need to get your master branch looking<br />
like the upstream master branch again. First off, make a new branch<br />
off of your current master.<br />
<br />
git branch -b [name of fix branch] master<br />
<br />
Next, you'll want to do what git calls a "reset". This resets the<br />
latest commit your branch points to, to another commit. Since we want<br />
this to look like the master of the upstream, we do<br />
<br />
git checkout master<br />
git reset upstream/master<br />
<br />
This will make the head of our local master looks like the upstream<br />
master. You may see some lines like<br />
<br />
M c/lib/cameras.h<br />
<br />
This means that in a commit that was not on the upstream master branch<br />
was removed, but git left the changes to the file there. They are now<br />
just unstaged changes. If you want to completely remove all changes to<br />
files, do<br />
<br />
git reset --hard upstream/master<br />
<br />
This will make sure any commited files that had changes before the<br />
reset are now in the state that matches upstream/master. Your changes<br />
will still be in the [name of fix branch] branch you made earlier, so<br />
you haven't lost anything. Now you can check out the branch you made<br />
by doing<br />
<br />
git checkout [name of fix branch]<br />
<br />
and can then continue on with your work, with a cleaned master branch.<br />
<br />
=== Are there other ways to do all of this? ===<br />
<br />
Yes. This document takes a rather paranoid view of the "git pull"<br />
operation, instead prefering to set remotes and always do merges<br />
locally. Another option for updating your feature branches to be on<br />
top of the upstream would be to do<br />
<br />
git pull --rebase git://github.com/OpenKinect/libfreenect.git master<br />
<br />
Which will rebase your changes to the top of whatever is on the<br />
remote without the need for an upstream tracking branch. <br />
<br />
There are probably even more ways of dealing with this, so please feel<br />
free to add to this document as is needed.</div>Slomphttps://openkinect.org/w/index.php?title=Getting_Started_Windows&diff=878Getting Started Windows2010-12-23T22:03:10Z<p>Slomp: </p>
<hr />
<div>== Building Kinect Drivers from Source ==<br />
<br />
=== Dependencies ===<br />
Download these and install them somwhere:<br />
<br />
http://sourceforge.net/apps/trac/libusb-win32/wiki<br />
<br />
ftp://sourceware.org/pub/pthreads-win32/dll-latest<br />
<br />
http://www.xmission.com/~nate/glut.html<br />
<br />
=== Driver installation ===<br />
<br />
There are two parts to libfreenect -- the low-level libusb-based device driver and libfreenect itself, the library that talks to the driver. You only need to install the driver once.<br />
<br />
==== General instructions ====<br />
<br />
Plug in your Kinect. The Xbox NUI Motor loads first. Cancel any dialog that searches for drivers and open the Windows Device Manager. Find the Motor device, right click, and press "update device drivers" and manually browse for the location. Select the /platform/windows/inf folder within the libfreenect folders. After the Motor is installed, the Xbox NUI Camera and Xbox NUI Audio will connect and you can repeat the same thing for those drivers.<br />
<br />
==== Windows 7: step-by-step walkthrough ====<br />
<br />
Plug in your Kinect. Windows will warn that no device driver was found for the plugged device (the LED of Kinect '''will not''' turn on). If Windows presents a dialog asking to search for drivers, simply cancel it.<br />
<br />
Open the Device Manager:<br />
<br />
'''Start''' >> '''Control Panel''' >> '''System and Security''' >> '''System''' >> '''Device Manager'''<br />
<br />
A device called "''Xbox NUI Motor''" should be somewhere there (most probably be under "'''Other devices'''") with a small yellow warning symbol "!" on top of its icon. Right click on it, and select "'''Update Driver Software...'''", then click on "'''Browse my computer for driver software'''".<br />
<br />
Then pick "'''Browse'''" and select the folder where the "''XBox_NUI_Motor.inf''" is located. Click "'''Next'''" and if warned by Windows that a non-certified driver is about to be installed, just '''order it to install it anyway'''.<br />
<br />
After that, the Kinect LED should start blinking green. Now there will be two additional devices in the Device Manager list: "''Xbox NUI Camera''" and "''Xbox NUI Audio''". Repeat the above instructions for them as well.<br />
<br />
You are now ready to build libfreenect and start developing your own software in Windows with Kinect!<br />
<br />
=== Building the Instructions ===<br />
<br />
[http://img709.imageshack.us/img709/1444/screenvfi.jpg]<br />
<br />
In the following, the process in order to create the drivers for Kinect in Windows and to run the example program.<br />
<br />
* '''Step 1:''' Download CMAKE (Cross-Platform Make) and make sure you have a working C compiler (example Visual Studio 2010 or MinGW)<br />
<br />
* '''Step 2:''' Download the the master branch and all the Dependencies<br />
<br />
* '''Step 3:''' Run CMake-gui and point to the root directory where /src, /examples, etc. are children (where it has the first CMakeLists.txt)<br />
<br />
* '''Step 4:''' Use the configure option, select your C complier and let it run. It will point out several mistakes that will be presented as red in the CMake Gui. You must correct these problems. For the libfreenect header you must point at c/include, for USB header c/dependencies/include and so on...['''NOTE:''' For now only select the EXAMPLES and C_SYNC build options. The others such as FAKENECT have not been updated for Visual Studio yet.]<br />
<br />
* '''Step 5:''' Finally accomplish configure and generate files (CMake-> configure, CMake-> generate). When it has errors then update the missing folders to the folders of the dependencies. The *_LIBRARY variables need to point to actual .lib files not a folder. INCLUDE variables need to point to the appropriate include directories. You might need to check the advanced checkbox to access some variables. <br />
<br />
* '''Step 6:''' After you can successfully generate the projects, open libfreenect.sln in Visual Studio and build the project.</div>Slomphttps://openkinect.org/w/index.php?title=People&diff=818People2010-12-18T10:19:24Z<p>Slomp: </p>
<hr />
<div>This page lists the people currently involved in the OpenKinect community and development effort. If you're starting a new project or working on a particular new feature, check here to make sure someone else isn't already working on it!<br />
<br />
= Community lead =<br />
Joshua Blake ([[User:JoshB|JoshB]]) is the OpenKinect community founder and lead. He is responsible for bringing together everyone interested in OpenKinect and tries to coordinate the project's efforts and the people who work on them. He also serves as a point-of-contact between the OpenKinect community and other projects, companies, and the general public.<br />
<br />
= Subprojects =<br />
<br />
== Administration ==<br />
This includes mailing list and PR efforts such as twitter and blogs.<br />
<br />
* Joshua Blake ([[User:JoshB|JoshB]])<br />
* Seth Sandler (cerupcat), assists with Google Group mailing list apps<br />
* Nink, primarily runs @openkinect on twitter<br />
* Hector Martin (marcan), runs the openkinect.org server and Wiki software<br />
<br />
== Regional Meetup Coordinators ==<br />
This includes people organizing events and meetups in cities around the world.<br />
<br />
* Sean Kean ([[User:Seankean|seankean]]) - [[http://www.meetup.com/OpenKinect NYC OpenKinect Meetup]]<br />
* Matt - [[http://www.meetup.com/3DVision/ San Francisco 3D Vision Meetup]]<br />
<br />
== Repo maintainers ==<br />
Repo Maintainers have commit access to the official repository and integrate pull requests and patches.<br />
<br />
* Kyle Machulis ([[User:Qdot|qDot]])<br />
* Hector Martin ([[User:Marcan|marcan]])<br />
* Joshua Blake ([[User:JoshB|JoshB]])<br />
<br />
== libfreenect ==<br />
libfreenect is the driver and API project that includes all code that communicates directly with the hardware for Linux, OS X, and Windows. The repository is located at https://github.com/OpenKinect/libfreenect/.<br />
<br />
* Hector Martin ([[User:Marcan|marcan]]) - original author and current maintainer<br />
* Kyle Machulis ([[User:Qdot|qDot]]) - integration, Git master, cmake maintainer, OS X maintainer, win32 something or other<br />
* Joshua Blake ([[User:JoshB|JoshB]]) - win32, C# wrapper<br />
* Brandyn White ([[User:Brandyn|Brandyn]]) - Python wrapper, C Synchronous Wrapper, Fakenect, Kinect Record Utility<br />
* Arne Bernin - debian/ubuntu packaging<br />
* Theo Watson (ofTheo) - ofxKinect: OpenFrameworks wrapper for libfreenect<br />
* stephanemagnenat - Working on ROS node which uses libfreenect, would like to push changes upstream. Our lab could help with calibration.<br />
* Drew Fisher ([[User:Zarvox|zarvox]]) - Working on camera protocol, reverse engineering, and documentation<br />
* zephod - Working on audio protocol and Win32 C++ <br />
* Tully Foote (tfoote) - Working on ROS node https://github.com/ros-pkg-git/kinect and managing separate branch used for integration with the ROS bindings https://github.com/ros-pkg-git/libfreenect<br />
* Aditya Gaddam ([[User:LostInCake|LostInCake]]) - Cross platform C# wrapper. Helping with win32 library effort. Ruby Wrapper.<br />
* Scott Byrns (scottb) - Java wrapper<br />
* Juan Carlos del Valle (ekinox) - Action Script 3 server and API<br />
* Oscar Valdez (ozipi) - Actionscript 3 server and API<br />
* Mike Slinn (mslinn) - Action Script 3<br />
* Taha Bintahir - Processing<br />
* Mark Renouf (mrenouf/tweakt) - Ubuntu packaging https://launchpad.net/~mark-renouf/+archive/openkinect/<br />
* CADET - Working on skeleton segmentation library (2Real engine) http://www.cadet.at<br />
* Aaron Zinman - JavaScript via DepthJS<br />
* Doug Fritz - JavaScript via DepthJS<br />
* Roy Shilkrot - JavaScript via DepthJS<br />
* Greg Elliott - JavaScript via DepthJS<br />
* Kai Ritterbusch(phen), C++ example & bugfixes<br />
* Marcos Slomp ([[User:Slomp|Slomp]]) - Win32 port (libusb-1.0 emulation layer)</div>Slomphttps://openkinect.org/w/index.php?title=User:Slomp&diff=817User:Slomp2010-12-18T10:18:39Z<p>Slomp: Created page with "Marcos Paulo Berteli Slomp (Marcos Slomp, for short) ''Win32 port: libusb-1.0 API emulation for libusb-win32 (libusb-0.1)'' '''IRC alias:''' Slomp"</p>
<hr />
<div>Marcos Paulo Berteli Slomp<br />
<br />
(Marcos Slomp, for short)<br />
<br />
''Win32 port: libusb-1.0 API emulation for libusb-win32 (libusb-0.1)''<br />
<br />
'''IRC alias:''' Slomp</div>Slomp