So I’m extending my degree’s project and about to author a paper – or at least try to.

To increase the confusion that little bit further, here’s the provisional title:

Identifying a remote input sensor that best yields a ‘more’ natural/intuitive syntax or symbology while optimising character recognition

Damn that needs to be shortened and/or made more concise or something…

My university project involved examining the input sensors on the Nintendo Wii Remote, the infra-red sensor and the accelerometer.

So, the gist of the paper is essentially to carry on this comparison, to find a possible link between the co-ordinate data from the infra-red sensor and the acceleration data from the accelerometer.  Of course, I may not be able to draw a comparison so I may leave this idea to persue another avenue of exploration…

Step one is to make an application that will simultaneously record both accelerometer and infra-red data from the Wii Remote then I can start capturing (meaningful) data…

Wish me luck!

View the better quality version at the original resolution of 1280 x 720!

The music is “Baba O’Riley” by The Who on the album “Who’s Next?”

Notes on the scenes

All objects in the scene are set up in Havok as a rigid bodies. Various different collision detection
meshes had to be set up for certain objects so the ball reacted correctly when it came into contact
with them. The only exception is the ball that is set up as a soft body. The ball is the only object in
the scene that has had its physical properties set up. The main property of concern is the ‘stiffness’
property which makes it react as though it is a metal ball. If it’s value is too low, the ball’s mesh
will distort like a rubber bouncy ball. If the value is set too high, the ball bounces off an object and
the mesh ‘explodes’.

Scene 1

At the beginning of the scene, the ball is travelling up the pinball launch pipe. Here, the ball’s
movement is determined by a path constraint. When the ball reached the end of the pipe, the Havok
simulation takes over and the ball drops down the table.

The flippers are part of the Havok simulation as rigid bodies and are key-framed to swing up and
down at set times. For Havok to register the movement of the flippers, the flippers are set to be
‘unyielding’ on the Havok properties roll-out menu. If this option isn’t checked, the Havok
simulation will only register the starting position of the flippers, so that if they move, the physics
engine will still be registering the original position. The results of this is that other objects in the
simulation may appear to be bouncing off a blank space!

Getting the motion with the ball and the flippers to simulate a real game of pinball involved keyframing
the movement of the flippers and simulating the scene in the Havok engine. This was a
highly iterative process as it is difficult to determine the exact motion of the ball after each contact
with the flipper. Each scene was constructed using this method.

There are four cameras in the scene. Overall, they track all the movements of the ball. Each
camera’s motion begins when the previous camera’s motion ends. It’s possible to follow which
camera was responsible for each sequence by looking at the filenames of the individual frames.

(The name will have ‘View01′ followed by the frame number, ‘View02′ and so on. The batch-render
function was used to render each camera’s series of frames one after the other.)

Scene 2

The beginning of this scene is exactly the same as Scene 1, with the ball following a path constraint
to the top of the launch pipe.

Unlike the previous scene, the movement is split over several *.max files. The first file deals with
the launch pipe and some movement around the flippers, using Havok as before. Then the flippers
push the ball up towards the rails on the pinball table. The sequence ends here. The next *.max file
contains the movement of the ball on the rails which is controlled by a path constraint. The last
*.max file contains the movement of the ball off the rails and around the table purely making use of
the Havok engine again.

(Each sequence within each *.max file only contains one camera.)

Pinball table material

The pinball table was made in Adobe Photoshop. To make the material fit perfectly to the table and
look as thought it was part of the other objects on the pinball table like the buffers etc, a screenshot
of the top view was taken and overlaid as a template in a layer.

Other materials

The main ‘body’ of the pinball table and the triangular buffers were textured using a Metal material
from the set of Mental Ray materials. The rails and the pinball were textured using the ‘standard’
material within Max, with basic reflection maps.

The bunny models and the flippers were textured with the Car Paint material from the Mental Ray
library, with the colours supplied using the ‘gradient’ material in the standard library. The Car Paint
material makes the Bunny and flipper meshes look like polished metal, which was the desired
effect.

The pinball table material was originally just applied to a ‘standard’ map with basic reflection,
however this made the table look flat and didn’t match the other objects in the scene. A similar
material to the Car Paint material was used in the end, called Metal Paint that provided a realistic
set of reflections and ‘fleck’ effects to the table, taking away the flat appearance.

Using the Car Paint and Metal Paint materials dramatically increased the overall rendering time,
however their quality and level of detail enhance the idea that they could be made from real-world
materials.

Final design that appears on the pinball table in the renderings

Enjoy

All the frames are present now.  The next step is to do some more editing in After Effects and whack on some nice music…

This is just a low-quality preview at 576 x 324.  The actual rendering is at 1280 x 720 (16:9 ratio) at 25 fps.  Each frame was rendered to a lossless *.png file in 3dsMax, imported into Adobe After Effects as individual frames, and exported as a Apple Quicktime *.mov file.

The advantage of rendering this way is that if 3dsMax happens to crash, or there is a problem with a single or small sequence of frames then they can be rendered on their own and placed back into the final animation in After Effects.  This is far better than rendering straight to video format from 3dsMax as there is more control over the compression settings of the animation, and as mentioned before – if the software does crash, the rendering process doesn’t have to begin from the start of the animation, rather, just from the frame that the crash occured.

Here’s my project proposal – it’s not the greatest prose in the history of English but it sort of does the job!

My project will centre around researching intuitive methods of interacting with a computer – be it a workstation, laptop or another bespoke computer system such as a games console or installation-art.

The first element of my project will be made up of research into the existing intuitive control methods or user interfaces that are available on the market today, and several from the past. Many user interfaces or methods of control aren’t intuitive or natural and may require training to use. I shall be finding out why these methods of control have been successful, or not.

The bulk of the research will involve finding methods of interacting with the computer system that feel more ‘human’ or natural.

Over the course of the overall research into user interfaces, I shall also be investigating the many possibilities there are for capturing motion information onto a computer and then using it in a meaningful way. For example, the Nintendo Wii remote controller can be linked to a computer via Bluetooth and used with a variety of programming environments ranging from Flash, Director all the way through to many open-source developments.

The second part of the project will involve using the research to produce an application based in a 3D environment.

The control device that I will be using is the Nintendo Wii remote. This is due to the fact that it has a whole array of sensors (accelerometers) that send a continuous stream of information to be interpreted by the computer.

The aim is to give the user the ability to traverse the 3D environment without using any button presses, but rather using a series of different movements or gestures – the latter being much more natural. There have been many inventive uses for the sensors in the Wii remote, which is apparent from looking at the choice of games that are available for the Wii. Another of my aims when creating this application is to create a series of gestures that need to be carried out to move through the world (such as waving the remote in a circular motion or moving it very quickly, miming the swinging motion of a baseball bat). There may also be a game-playing element to this application.

That’s it but it will be revised shortly…!

At the moment my ideas are still coming together for my project. I’ll be focussing on the following topics over the next few weeks:

1. The way computer games utilise music.
2. Unconventional user interfaces in – a. Computer games, b. Professional music software, c. Studio/Live artist performances.
3. Various programming langauges that support such interfaces.

4. …whilst all the time creating/programming experiments, which demostrate some findings of the above points!

Just thought a small bit of clarification was needed before I plunge ahead (for me as much as you, the reader!)

MA