My role in the Ski Free 3D project was most of the scripting. This included creation of the heightArray with a C++ program the development of the movement system. The movement system that I developed works in a straightforward manner. The user can specify whatever X and Z velocities that they want using any input device that they want. The program has a variable to store the current position. The next position is then calculated by adding velocity * time to the current position. Then the program draws a line between the current position and the next position and sets the y velocity so that the avatar stays along that line. The next time the timer function is called the positions are incremented, velocities changed based on acceleration due to gravity and glove input, and the whole process is repeated. I also developed the code to have the viewing angle change based on mouse movements. To do this I inserted an invisible box in front of the camera and routed a touch sensor's hitpoint_changed field to a script node which calculated a viewing angle based on the position of the mouse. Finally I developed code to calculate the angle that the avatar is moving in each direction for gravity calculations.
I also helped to debug the glove code, collision detection, and made the ending screen and ending sound. This involved a collision node to play the sound clip and a textured box to show the snowman picture. The calculations for the next position go like this, first we define two planes. y1 = a*x1 + b*z1 and y2 = a*x2 + b*z2. x1, y1, z1 is the current position and y2, x2, z2 is the next position so everything is known except for a and b, you have two equations and two unknowns so they can be solved simultaneously. Once you have a and b you can take the partial derivative of either equation to come up with the equation dy/dt = a * dx/dt + b * dz/dt. A and B are known and dx/dt and dz/dt are specified by the user so you can solve for dy/dt, the y velocity required to stay on the line. I would now like to explain how x2, y2, z2 is caluclated. The next x and z are calculated by adding the x and z velocity (Multplied by a timefraction) to the current position, then rounding. An elevation grid is simply an array of heights based on x and z values so I imported the elevation grid array into javascript and the next height is simply the heightArray[nextx][nextz]. So what the set position function does is it determines the time that has passed since the last time it was called by saving the time fraction in a SFTime field and subracting it from the new fraction whenever it comes in, whenever the new fraction is lessed than the saved value the timer has started a new cycle and the time is then set to the new fraction and the new fraction stored as the saved value. X and Z input velocities are then read from the glove and the y velocity is called and set based on these values.
The movement system worked perfectly except when the x velocity is positive and the z velocity is positive. The line equations themselves are sound and if they work for just positive x, and negative x and positive z, they should work for positive x and positive z. But movement is jerky and out of tune for this. I spent hours looking at the code trying to find what was wrong but I couldn't, so I just put in base statements to set the y value to the nextheight if it tries to fall through the world or fly above the world but this is an imperfect solution that leads to very jerky movement not only in the positive x and positive z case but for the other cases as well. How the camera movement system works is this: The only way to physically track mouse movement that I found reliable was a touchsensor. A touchsensor keeps track of the mouse position over any object. So I put an invisible box in front of the camera linked to a touch sensor, and linked the distance coordinates to a script node that converted them into a rotation that was routed back to the avatar viewpoint. So whenever you move the mouse around the avatar looks around in the same manner. The last part of the project that I did was helping with collision and the ending animation. When the simulation ends it just sets the avatar's position to in front of the ending screen which collides with an invisible bounding box to play a sound, when the sound is played the bounding box is moved away from the avatar so that continuous collisions and continuous sound playing does not occur. How I helped with collision detection was that I routed my get next position function to the collide function so that when a collision occurs the avatar is moved to some set distance away from the collision point. Then the avatar is able to move around again freely.