OpenNI Skeleton Tracking

wow, sounds awesome, i’d really love to see and use those features. some of them i had already hack together for a project of mine but unfortunately not in a library-worthy way … quite messy :smiley:
i also read the people of openni want to completely eliminate the calibration process in the future, that would be perfect of course.

something that i found to be very nasty when working with openni was setting the number of tracked users. in some cases you want to track everyone in front of the kinect, in some cases only one person. in other cases only a limited number of users. it would be great if there was a way to set that up easily. in the end i found a hackish way to track only one user and ignore everyone else but it wasn’t very stable :frowning:

this all looks awesome.

do you know if there are any updates on the intermittent keyboard/mouse/usb killing feature when running openni on OSX?

It shouldn’t be a problem to add more users to your program. In fact there’s a method that sets the maximum amount of users, that adds new user instances in case that you want more than the current amount of users. So for instance you could extend the ofxUserGenerator class, make it start with one user, when the new user callback is called add a new ofxTrakedUser, so you could eventually have as many users as you want. also you can add a method to deallocate the unused users. I’m working on some OpenNI based projects in which a function like this might comein handy. If a implement it I’ll let you know.


@kylemcdonald, I’ve never seen the issues that you mention (I’ve always used OSX, btw). When do this happen??


@roymacdonald it depends on the computer – in my experience, some people are more susceptible than others. but if you get a class of 30 students to all run ofxOpenNI, 5-10 of them will have their keyboard stop responding and need to restart. i haven’t figured out the cause yet.

in my experience tracking multiple users isn’t a problem. my problem was tracking ONLY one user. in ofxopenni i could set maxnumusers but from the openni log messages i could see that it was still internally looking for new users even when there was already one tracked user. and as i said above i found a hackish solution at the end, that was never 100% stable

I’m wondering if you guys can offer me some advice on code, style and politics.

I’ve asked a few times in the forum about where to go with ofxOpenNI. Back in March or April there was a brief contact with Diederick about merging our forks and I’ve PM’d him recently but haven’t received a response.

I’ve been putting a lot of work into this thing and it feels like a lot of people are using, or are at least looking at the code.

In the beginning - and so far - I’ve been fine with just hammering away at a fork. And really there is nothing wrong with this. But perhaps it’s a bit confusing for people (including me) and makes making any radical changes to the code trickier.

At first I was just on that cusp you get to with a language like c/c++ -> you’re starting to get the patterns and can clean them up; I got a bit better lately and working with a forked pattern that I don’t think handles the code/problem as well as it might (or at least how I’d like to :wink: is getting more difficult.


* Should I make a whole “new” addon (ie., change the name; stop supporting the fork)? [This goes against leaving a git history of the code - although obviously credit would be given where it is due - but it would allow for easier identification of ownership/responsibility for maintenance, as well as allowing an easier refactoring of the core code]

* If I don’t do that (and indeed even if I do), what’s the best way to make a radical change to code that’s already in use? -> on the one hand, yet another API for doing the same thing (get some depth pixels, make a mask, draw a cloud point, track some blobs, hands etc) is kind of annoying, but on the other hand making it all simpler is good isn’t it? Or is it not worth it if it breaks everyones code? [I could mark certain calls deprecated; and make sure that it’s possible to use the old ofxDepth/Image/etc/Generator style; but in some parts it’s still simply going to break - keep in mind that nothing that radical has happened in the OpenNI API -> I just know how to use it better now, whereas before I was learning by changing Roxlu/Halfdanj’s code]

* I guess it’s also tedious (perhaps it’s just ego?) to be constantly working on a fork; there’s a sense of ownership loss - which is mainly because it’s not a collaboration in the sense of an ongoing communication between me and Roxlu. That would be whole different story. In the end it is plain boring to be constantly posting: “have you tried my fork” or “my fork does x” -> maybe that’s just silly? But I feel that way often when posting about “my fork”…Sometimes I wonder whether this (indeed all code) comes down to ego; it simply doesn’t matter to the vast majority of users who wrote the code first, or who maintains it; but to a few people it does, including ones self, when you’re up at 4am recompiling and wrapping drivers so they’re portable and useable on any platform.

* Instead of all the above: Should I persist more strongly with merging our code?? I don’t know Diederick. I don’'t know if he’s just too busy to respond. Perhaps the fault is mine; I’ve certainly been busy on a lot of stuff: Ultimately I have not issued a pull request on his repository - not sure why, just a gut instinct (maybe a totally wrong one) that it wouldn’t happen.

In the end the question(s) is/are:

* Should I make a merge request and PM him some more?
* Keep on working on the fork in this ‘separate’ style -> perhaps continue adopting Roxlu’s naming scheme (I see he added an ofxONI class to make a ‘simpler’ interface to the context, generators etc?
* Make a new project and give credit to Roxlu/Halfdanj?
call it ofxSimpleOpenNIToo ::slight_smile: (groan)
* Worry less and just get on with coding ???

maybe roxlu is busy, i think he has many projects going on as well. his last commit is from june though, it doesn’t seem as he’s actively developing his library at the moment.

looking at the github graph there seem to be 3 more or less active forks: yours, halfdanj and the one from roymacdonald. roy is also active in this thread and seems to have some nifty features in his fork (e.g. tracking without calibration pose). maybe it is possible to add his features to your library with a pull request and give him credit (of course only if you both agree). afterwards you could talk about if there’s the possibility of further collaboration on the library and how that should look.

then there’s still halfdanj’s fork but i haven’t tested that and i don’t know if it goes further than just modeling it for his own needs … maybe he can say something about his plans.

in my opinion you should wait for what roxlu has to say and if he’s okay with that you can keep the name for your library and give him credit. if he’s not okay with that i guess it would be best to change the library name

i wouldn’t worry too much about breaking code at this stage, i think as long as the changes are well documented nobody would have a problem with it.

i can totally understand you and in my opinion you’re doing the most ambitious ofxopenni development at the moment (including the communication with the other people and potential users on the oF board) … that doesn’t mean i think the other guys don’t do good work it’s just a feeling because you’re openly communicating your plans and also asking the people here for suggestions and i just don’t see any of the other guys doing that at the moment

so far i didn’t have problems with your API style, i think it’s good … but if you have an idea on how to make it even easier to use that would be great too of course :smiley:

these are all great questions, definitely worth talking + thinking about.

normally the way things work is that people code on a fork, then send a pull request.

if the pull request is ignored, and you continue making significant contributions, it’s totally reasonable to rename the project. it’s actually a good idea to rename the project to clarify how different it is.

my suggestion is that you send diederick a pull request, and if he ignores it or turns it down, then rename your addon and continue working on it independently. don’t worry about making a backwards compatible API, or even using the same design patterns.

the reason to avoid a “true” fork is because it divides development and community. with ofxOpenNi, i don’t think this is an issue, since diederick hasn’t touched it for a few months. i always had the feeling that he was more interested in ofxOpenNi just to get it working, not for continued support + mass use (consider the fact that “master” still has only a readme file).

even if diederick does accept the pull request, and merges for posterity, it might still be a good idea to start from scratch/with a new design. sometimes the best work happens after you’ve finished something completely, then start over :slight_smile:

It’s really great to see this happening; discusion, community development.
the truth is that this is the first time I’ve used GitHub so I’m just getting used about how it works.
I’d really like to be able to modify/update the code in the same fork as others work, so it actually is a comunity development. Is there a way to do so without pull requests? where theres no “owner” of the fork?
I think it would be really good o merge the forks.
I have worked a lot with openni and this addon and it took me some time to understand it’s mechanics and I think that a complete rework on it could be of great benefit, not only for users but also for further development. I think that there’s no need of wasting time by making things back compatible, as what’s done so far works fine and for simplicity’s sake starting from scratch would be easier. (My head is a bit “cloudy”, hence my writing and english :stuck_out_tongue_winking_eye: sorry for that)


It would be a good thing if a merge can be done, but if not who cares.

I think that the best would be to merge everything and just have one master (“official”) fork and a development one, and update the master once the dev updates are working ok.
Roxlu’s naming is fine for me. I rather use descriptive names, like Roxlu’s, than shorter and criptic ones. What I’d avoid are namespaces. I really don’t like them and makes reading the code much less intuitive. (That’s why I don’t like coding in cinder).

Lest try to keep the same name and give credit.
At least for me ofxOpenNI sounds well and gives me the impression of being the official, fully featured thing.
ofxSimpleOpenNIToo sounds like it’s lees capable little brother.

I also ask this to myself. But sometimes is good to share this worries, like now.

So, how shall we proceed?

hi sweet people! Thanks Kyle for mailing me about this! I’ve been so extremely busy with lots and lots of projects and still have ofxOpenNI on my todo list and my hands are itching for several months now to pickup where I left.

But as gameover mentions, it’s not fair for all the people who have spend many hours in making ofxOpenNI better and not having full control over the repository and not being able to see their features back in the main version. As Kyle mentions it’s totally fair to just start a new other repository and continue your work there. The same thing happens with the OF repository and that’s the nice thing about social-coding.

Though it -is- nice to have a central place for an addon. Therefore, if it’s possible I can pass on the repository to gameover so there is still one central place for ofxOpenNI. (not sure if this is possible with github). If not I can remove all code and add a readme with a link pointing to the new repository / maintainer.

@gameover, I’ll PM you with my skype account so we can have a chat about this if you’d like. I do have some ideas for new features in ofxOpenNI (i.e. flash hook, i’ve been doing some tests with creating iso surfaces using multiple kinects etc…, did some tests with mesh simplification and smoothing … all tests which aren’t ready for public use).


Hi - These are great questions and highlight a really big (and annoying) issue with using addons in oF.

  • if someone shares example code using addon x, for which there are multiple branches, there is usually no indication of which branch they are using or indication in the addon file of version/branch, so things can break in very confusing ways (e.g. methods missing or methods params don’t match even though file names are the same, etc.)

-if someone includes the addon code then the example may work but then trying to use that addon for new work and putting it in the addons folder may break other work that expects a different branch, etc.

Just last night I was trying to show someone how to use the kinect with the ofxOpenNI addon and the whole “which branch does what and where to find it” added to lots of confusion.

I’m just a user, not developing any addons, so I don’t have any answers. I wish github would auto add some branch tag or other indication to downloaded code. I don’t usually create a local repository - I just download a snapshot (maybe that’s creating some of my problems?).

Anyway, thanks to all addon developers, and to gameover for your openNI work!

Had great talk with matthew! I send a request to github support to transfer the ownership of ofxOpenNI.

this is how open source works! yes!

i know github will let you add many admins to a repository (this is how ofxKinect or libfreenect works), but i’m not sure if you can remove the original user to change the url. good luck :slight_smile:


so, how shall we continue organizing before we begin coding?
Coding style, protocols, design, workflow, etc.

I think it would be good to move to a different thread.

Not sure if this warrants its own thread but has anyone tried using the Asus Xtion with the ofxOpenni addon?

I’m writing an application which runs fine with the kinect but then crashes when using the getMetaData() method in DepthGenerator? Its crashing at this method xnUpdateMetaDataBeforeFirstRead(XnInternalNodeData*) + 6

This is on osx 10.6 with OF6.2

Does this need OF6.2? I’m on Linux 007 and I’m just digging a hole trying to get this to compile.

Thanks =)

I haven’t tried the Asus, moreover I know no one that owns one to borrow and make tests.
But I guess it should work as it is compliant with openNI. Maybe some minor changes might be needed in ofxOpenNi to make it work.

Are you calling directly the getMetaData method from your code or is just ofxOpenNI that crashes when it reaches that line of code?

I’d recomend you to update to the latest version of OpenNI and NITE.
getMetaData should be called after all the ofxOpenNI updates, especially the context update. The error thrown sounds like that you are calling this method before openNi updates thus when it gets the data from the kinect.

Not at all.
Making it to compile it’s not that hard. Just make sure that you add the correct paths to the OpenNI and nite includes and libs.
This can be either the ones installed in your computer or the ones that come inside the addon.
In the case of using the ones of the addon you might have trouble with the relative path linking.
If you have installed OpenNi in you computer this should be in /usr/include/ni and /usr/include/nite
The same apples for the libs.
The installed libs should be at /usr/lib

good luck!

Hey awesome peoples!

Thanks so much for all the feedback over the last couple of days…especially Roxlu for getting onto me so quickly, and having such a great approach to developing this project!

My apologies for having gone offline for a couple of days - I’ve been working on a show using ofxOpenNI that opened on Friday. I’m super excited because a) it’s the first time I’ve got to use the addon in a live show (we’re using it to create registered projections for set elements and as a virtual lighting system for all performers and puppets) and b) because the show is about Indigenous aboriginal creatures from around Australia, and is one of the first times some of these creatures have been allowed to be talked about and performed for general public audiences…

…but I digress…

I agree that we should move discussion of further development of ofxOpenNI to a new thread: this one is monstrously long…and by the time you read 14 pages of conflicting implementations, instructions, forks, pleas for help, etc anyone trying to start out is bound to be confused.

So on that note I’m opening ofxOpenNI-Development

Once we’ve sorted out how to merge/move the repo’s I’ll start another thread for support, installation and implementation help and update a link here.

Were are you from gameover? Im a melbourne dev doing similar things. Is the show still on, im in Sydney on saturday