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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor