[Tutor] IronPython, the wii remote, and blender

[Luke Paireepinart]

Timothy Sikes wrote:
> Well, I was playing my Wii the other day and then sat down to mess around on blender. Then I had an idea! What if the Wii remote could be used as an input device for blender? It would be great for 3d modeling, and you could always switch back to a mouse and keyboard for more precise control.
>
> So my next thought was.... Is it possible? Obviously it would be somehow, but whether it would be feasible or not for me I had to research.  I remebered that they have a wii remote library for vb.net and C#(http://blogs.msdn.com/coding4fun/archive/2007/03/14/1879033.aspx), and IronPython is a .net framework.   Would it be fairly easy to convert their code to work with IronPython?  After that is working, I would might need some help from someone who already knows the blender source, or who can write externals for it fairly well. 
>   
Gary Bishop is working on a ctypes wrapper for wiiuse, a lightweight 
single-threaded non-blocking wii remote input application.  Thus you can 
use it in normal cpython.
If you really wanted to use .NET, you might need to do something else, 
but if you use cpython you're set.  This also makes your application 
cross-platform, since wiiuse, blender and cpython are all cross-platform 
(and .NET is not.)


> Basically, is it feasible to do the above?  If I decide to carry this project out, it would take a lot of planning.  Is there anyone out there willing to help?
>   
The wii remote side of it is simple.  The blender part would be the 
difficult thing.
What you need to realize is that the wii remote only contains 
accelerometers, not gyroscopes.  As such, the way you tell how the wii 
remote is tilted is by the acceleration of gravity on the axes.  So if 
it's perfectly upright, you'll have -1g in Z, 0 in X, and 0 in Y.  If 
it's upside down, you'll have 0g,0g,1g.  if it's on its right side, 
you'll have 0g,1g,0g.

Because of this aspect of the remote's operation, you can get pitch 
(tilt forward/back) and roll (tilt left/right), but you can't get yaw.
Yaw is the action of rotating the remote horizontally around  the origin 
(the location of the accelerometers.)  In this case, the only 
accelerations that are added are X and Y, but gravity stays consistent 
at -1g on Z.  since gravity is not moving around on the axes, there's no 
way for you to detect this change.

So if you think you can do 3D modeling with just pitch and roll, and 
maybe a sensor bar for distance estimates, you could.
Or you can try what a grad student researcher did: use a custom-shaped 
sensor bar (4 LEDs) so you can determine exact 3D positioning.  You have 
to use kalman filters to estimate your position based on accelerometer 
data while the LEDs aren't visible.
> Oh, and if this is just a crazy idea, please tell me so. 
It's not crazy, it just requires some advanced knowledge about physics 
and 3d positioning.
-Luke