<- previous index next ->
Motion can be useful and impressive.
If your program must do a lot of computation for each movement,
you will need to "double buffer". With double buffering your
program is building the next screen in RAM while the previous
screen is seen by the user. Then the buffers are swapped and the
user sees the new screen and your program builds the next
screen in the other RAM buffer.
Examples to be demonstrated:
2D
single_double.c - buffers in OpenGL (motion)
(also multiple windows)
3D
split_cube.c - speed control (motion)
split_cube6.c - speed control (motion)
robot2.c - connected limbs movement (motion)
pilot.c - game, exercise (motion)
planets.c - education, more on lighting later (motion)
SphereMotion.java - moving 3D lights (motion)
trackball.c - user control of view
skyfly - game, training, demo (motion)
draw3D1.java - evolving 3D data entry (multiple windows)
threads, manual menu
draw3D2.java - evolving
solid and wireframe, flipping, read/write
draw3D3.java - evolving
test.draw3d test data
four_windows.c - display multiple windows in OpenGL four_windows.gif
Techniques for developing interactive graphics applications
robot2.c was an interesting exercise for me to develop. robot2.jpg
robot.c I considered not much to talk about robot.jpg
dynamic.c A follow-on is some way, of robot.c was hard to read. dynamic.jpg
My approach was to copy dynamic.c to robot2.c and make the following
changes, in order, compiling (fixing) and running (fixing) each change.
I could not see the lower leg from the upper leg, thus I changed the
colors for various body parts. Since this was a 'lighting' scene,
it was a matter of changing the emitted light to white and covering
the various limbs with material of various colors.
Now that I could see the motion better, I wanted to make the robot
bend, not just turn. Yuk! The code used numbers, 1, 2, 3 ... rather
than named numbers for the angles. Thus I went through and changed
all references, menu, angle[?] and a few others to names, #define's.
This really helped me understand the code because I had to look
at every section.
With menu and angles and rotations named, it was easy to add two
menu items, one to increase motion per click, another to decrease
motion per click.
Now it was easy to add bend to the torso because I had seen that
the head could both rotate and bend, just cut-and-paste with some
name changing.
When I lifted both legs, the robot did not lower itself, unreal.
Thus I added keyboard function for 'x', 'X', 'y' and 'Y' so the
robot could be moved.
Future ideas are to "fix" the upper limbs, shoulder hip, to both
rotate up and down and sideways like real limbs. Then add "hands"
with some kind of grip. Texture map the face. Change cylinders
to ellipsoids. Be able to read and save a script of a sequence
of motions. Oh! But if I did that, students could not use it
as a project.
P.S. somewhere along the way I added + and - so the "repeat" function
of the keyboard would do what the mouse clicks would do, only faster.
Thus there became a 'move' function, which now should be stripped
of the cases and all of it executed every time.
robot2.c is an example of why there are many lines in an
interactive program. Much code is repeated yet is not suitable
for putting in loops. I expect this program would become more
unreadable and unmaintainable using loops.
A possible project is to implement a "record" mode where a user
moves the robots limbs to make the robot walk, run, dance, jump etc.
Then a "play" mode where the robot performs the recorded motions.
A typical data structure for each move might have:
sequence number
delta time for move
mode (just move, interpolate, repeat sequence)
x coordinate
y coordinate
z coordinate
number of joints to move
joint angle
joint angle
...
or an optional repeat sequence
sequence number
delta time for move
mode repeat sequence
from sequence number
to sequence number
If the "record" kept an ASCII text file, the user could edit
the action and potentially have a computer program generate
the motions.
User interface buttons similar to those found on VCR or DVD
recorders would seem appropriate.
The robot could be replaced by a more human figure, an animal
or some pseudo figure like a car, truck or machine that could
do non characteristic actions. e.g. cartoon characters.
Professional movie makers use sophisticated software that has
many motions preprogrammed. A technique for getting realistic
motion is to dress a person in clothing that has colored dots
placed at "control points" on the body. The person is then
recorded doing the desired actions. The coordinates of the dots
are extracted at each time step. The coordinates are then
entered into a data file for future use in animating figures.
The result is movies such as "Toy Story" , "Madagascar" and
"Over the Hedge" to name just a few.
<- previous index next ->