Interactive Visualization with Kinect

By | Uncategorized | No Comments

Recently I started working on a quick demo to create an interactive visualization with Kinect. The idea was to create a music visualization that could be interacted with Kinect and after someone interacts a trigger causes a message to appear.

Starting out, I experimented with creating the demo using OpenFrameworks using CPU Particles. I experimented with particles morphing into multiple shapes/images and different visual combinations.

After a couple of days, I realized that this path would require time and effort to produce any decent results and I was planning to make this demo within 2 weeks. Looking up at multiple different solutions, I went for the one with the one that would produce the biggest bang for the buck i.e Unity3D.

I started experimenting with 2D GPU particles using different examples and did rapid iterations, but after a few experiments I realized that too required more time than I was willing to invest right now.

This hunt for a nice GPU particle solution led me to TC Particles. This package is incredible, I have gone up to 2 million particles maintaining 60 fps. So now that I had the particles resolved, I messed around with my audio device settings and read the input from my mic so that I can use the song currently being played as input.

For the visualization I just mapped the FFT to particle properties. Properties were mapped with a simple formula, Property = Factor * fn(FFT[sample]). I used the factor to scale the FFT value to produce a better visual result and used some kind of a function (e.g cos, log, exponent) to produce a different mapping for particle behaviour.

After that I just integrated a Unity Kinect sample to use skeleton tracking and added box colliders to the skeleton to allow interaction. I don’t really like this method of interaction, it would be far better if the particle systems was in 2D and we could collide directly with depth map data, but ill leave that for some other day.

All in all it turned out to be a nice proof of concept.

Project ThirdCharm Initiated

By | Developer Diary, Game Development, iOS, Platforms, ThirdCharm, Uncategorized, Unity | No Comments
[imageeffect image=”1106″ type=”reflection” lightbox=”yes” target=”_self”]

We have been busy working on our next game, code named ThirdCharm. We are pretty bad with names so we just decided to use that for now until we land on a good name.

There is not much we can say or show about it but here is a concept art image and some untextured level designs that we have been trying out. Stay tuned.

[postgallery_grid id=”grid_thirdcharm1″ title=”Project ThirdCharm” data_source=”data-4″ orderby=”ASC” flickr_set=”No username entered” slidesetid=”ThirdCharm1″ content_type=”image” lightbox=”yes”]

Unity way of thinking

By | Uncategorized | No Comments

It’s been around a year since we moved to Unity 3D from marmalade engine. There were a lot of reasons to move to Unity which I will be discussing in a future post. One of the key reasons for the switch was that we had hired a new artist, and I felt that we were wasting talent without the artists being able to control the scene. I’ll have to say I am glad we made the switch.

Unity’s biggest strength is of course it’s incredible scene editor. I had always praised Unity for creating an interface that was so easy to grasp on to, and was even more impressed when I saw the team work with Unity in no time at all. All I had to do was install Unity on their systems, and before the day ended the team had a level ready.

Being an indie, we need rapid iterations to produce polished titles. I can’t stress here enough about how rapid and how many the iterations need to be. This is where Unity excels. The entire flow in Unity allows you to just play with the thing all day long. When the team is bored, they randomly cook up terrains and go on a long drive.

Still, for every idea we come up with there is always a feature/cost consideration, after which the idea goes to execution. But here lies the problem. In the old days, it would take a decent amount of time to even get a basic prototype of an idea into the game. Feathers would ruffle, classes would be modified, new additions would be made to old systems. So any mid-size change would require decent amount of time.

This is where Unity is a game changer. Unity allows you to make changes so fast that you don’t need to sit and think over a new concept in your head for hours. You can just prototype it. These rapid iterations allow you to do far more then contemporary engines ever could specially with a small team. The problem with this is, it needs you to change your mindset.

Point being, working for > 8 years with old school engines the tech have evolved. Unity has brought about a new landscape of rapid iterations. The feature/cost, I do in my head always had an arbitrary imbalance as when the feature seemed big I automatically somehow thought the cost is supposed to be big too. It has taken me some time to get used to it, but now that i have really changed my mindset i feel much more agile. We think up crazy new ideas and just implement them in a couple of hours to actually play what we had in our mind.