Up until now whenever someone asked about our open source projects I referred them directly to my Github page. That’s the repository, sure, but might be a bit noisy as it contains a mix of the projects I’ve created and maintain, with repositories I’ve forked (some of which I contribute to, but not all), with older projects.
I decided it was time to clear things up a bit, so I’ve done a brief write up on those that I’m actively maintaining. It has a better introduction to each, including both their application and licensing details.
On a previous post, I was commenting on how the Kinect’s lack of success as a gaming input device could easily be mistaken as a failure of the device itself, if one doesn’t look at the multitude of areas where it’s being used. Its future seems to be up in the air, however - if those other applications are niche, and it hasn’t succeeded in entertainment, then what?
I’m willing to make a prediction about where it’ll go: Kinect (or devices like it) will become ubiquitous and fade into the background.
I had lots of interesting conversations after my talk at the recent nucl.ai conference in Vienna, but one in particular sticks to mind. I was talking to an indie game developer who’s using the Kinect for a project on his college, who remarked:
Yeah, the Kinect is great. Too bad it failed
It’s an interesting sentiment because it’s a gamer or game-development one. On the home, as a game controller, the Kinect was definitely a failure. That is no surprise: I’m on the record as saying that game controlling and avateering are perhaps the two tasks that the Kinect is worst at (even though they are two tasks for which it keeps being pushed).
But there are all the areas where Kinect succeeds that have nothing to do with game development.
I participated on a fascinating panel yesterday at the (still ongoing and live-streamed) nucl.ai 2015 conference. One question asked by Richard Kogelnig, the moderator, was why have new input devices like Kinect and Leap Motion have failed to really penetrate the consumer market, and what sort of a device would really have a chance at making a difference.
I don’t think it’s a technical problem. I think it’s a message problem.
A recurrent question about UnitySteer is how to implement behavior like that of a flock of starlings (seems that Mr. Reynolds was right on the money when he chose flocking for his paper).
Usually the person who writes mentions that their implementation is “getting there”, but they’re not quite happy with the result yet. The main issue with the question is that if the results are right or not are all about perception - it’s not a problem where there is a single, provably optimal solution.
With that in mind, I’ll detail some of the aspects of the starlings from the video above, and mention how you can mimic them in UnitySteer.
Tropology is an experiment in visualizing conceptual networks from TVTropes. The initial idea was that, starting from a chosen concept, we could visualize the list of tropes and articles it referenced, along with the relationships between them.
Experimenting with the data, which even after some judicious pruning includes over 220 thousand nodes and 11 million relationships, led me to quickly conclude that the model was too widely connected. We couldn’t just visualize the raw data and needed to apply some sort of direction in order to make the visualizations sensible.
The long and short of it is that I was initially attacking the import process as one would on a JDBC client for a relational database. Query for these values here, create those if some don’t exist, insert relationships here, etc.