-
The Human: The main character is a virtual human male (henceforth
referred to as the "hero" without implying any virtue whatsoever) who was
designed in 3D Studio Max, modified
from a freely available android-like character, and extensively hierarchicalized
and re-pivoted in Alice to make the motions more realistic. Supplementary
characters planned for the future are Alice Liddell (the fair maiden to
be rescued) and plenty of monsters to make our hero's life difficult.
-
The Cave: This is a virtual environment (currently a dark cave or
tunnel) in which the scenario unfolds. The hero is led to the cave
and trapped in it, and has to find his way out. In the demo this
is very easy as there is only one path (no forks) and the direction to
go is indicated by friendly arrows. This is because it is very easy
otherwise to lose track of which way you were going (I'll come to why in
a later point). The cave is an extrusion designed in 3D Studio Max
and exported as an OBJ with textures. It has no hierarchy.
Most of the other objects in the world lie within the cave. It automatically
lights
the way for you, and will soon have hidden gems for you to find and grab.
-
Controlling and Animating the Human: Use keys
W = up, S = down, A = turn left, D = turn right, Shift = increase movement
& turning speed, Ctrl = grab, space bar = jump. The grab action
stretches out the hands to grab something. Other actions on the anvil
are: kick (to fight enemies); looking around without turning;
manual viewpoint control ; back flip. Remember to click the mouse
in the Alice window before initiating keyboard control.
As a bonus, I have designed a realistic (ah, well..:) walking animation
to go with the forward and backward movement. This is provided as
an option on two of the demos. On my computer the combination of
moving, walking, lighting and viewpoint control slows the animation down
from 10 to 4 fps :( . On a faster computer
there might be either a proportional slowdown (if we're lucky) or, if there
is a bottleneck animation which takes a certain amount of time each frame....
I don't want to think about that possibility.
-
Automatic Viewpoint Control: My engine resembles
the game Tomb Raider in that it shows the hero in a third person perspective.
But in my engine the camera attains a few fixed viewpoints with respect
to the hero and not the scene, viz. back view, front view,
left and right side views, top view and first person (eye)
view. These have been listed in order of preference, which I have
set arbitrarily, feeling that a back view is better than a front view when
both are allowed, and so on. My engine has an automatic viewpoint
controller which kicks in when the default viewpoint is blocked (say when
the human turns with his back to a wall, and the wall comes in between
human and camera in a back view) and finds the next best viewpoint.
When viewing conditions are better again, it automatically upgrades the
viewpoint. Due to technical reasons (mostly the inability of anything
other than the camera to pick() effectively) the viewpoint changes
instantaneously and not in a gradual way, and thus it can be confusing
and disorienting if you walk through a wall with similar scenery on both
sides and are not ready for the sudden change in viewpoint. Viewpoint
control was a major part of my work on this demo (working with a buggy
pick() command). It mostly worked, but twice I had to trash and rebuild
a world where the camera had irrevocably lost its ability to pick and was
giving attribute errors.
-
Position-sensitive lighting: This is another
thing I experimented with. Suppose the management of my virtual world
wants to conserve electricity (at some computational expense). They
have installed hidden switches that get tripped when the hero steps on
them, thus switching a light on when he comes near it and off when he moves
away. The trivial way to switch on and off light according to proximity
is to do a distance calculation from each light to the human, each frame.
My algorithm (visually described above as floor switches) has to monitor
only the next forward or backward switch each frame, depending on
the current direction of motion. Also, the square root calculation
is replaced by a simple z-coordinate comparison. Thus it is several
orders more efficient than the trivial algorithm (though I'm not
claiming optimality; to approach that we would need to do away with EachFrame
and introduce a new "position alarm" a bit like the time alarms that Alice
provides.
-
Collision Detection between the human and the cave
was tried very recently using the CDEngine module, and found to be too
slow because of the size of the (monolithic, non-hierarchical) cave.
I didn't feel like changing the model of the cave in 3DSMAX as I had customized
it extensively in Alice, so CD is also "coming very soon". As of
today you can escape the cave maze easily by walking out... but try not
to cheat!
-
List of known bugs - Things that aren't quite
right but could not be corrected in this demo version.
-
The walking animation once in a while gets confused (usually when you press
too many keys together) and may not start when you start moving the hero.
Note that this is a rare occurence, and its dual (walking animation when
not moving) has been fixed.
-
The walking animation plays at the same speed for walking and running.
This makes the man appear to be taking huge leaps while running.
Changing it involves parametrization & functionization of animations
over a large range of code, and I've put it off for now...
-
Occasionally the man's height increases spontaneously (he appears to be
floating). This may be the result of a failed jump. I've eliminated
this error by killing most of the causative factors, but it might resurface.
-
The lighting inside the cave isn't quite uniform. Some walls get
lit properly, while others just don't get lit. I think this has to
do with 3DSMAX's exporting of surfacenormals & texture coordinates.
I've done a calculateNormals() on the cave which improved things somewhat.
-
The human is untextured (I created him in the early days when I hadn't
found the OBJ export plugin, and texture coordinates were getting clobbered).
Since then I've repivoted him extensively in Alice and have no plans to
undo all that work by re-exporting. You'll notice the flat polygons
only when there is no point light source active nearby.
-
Automatic viewpoint control is instantaneous and does not smoothly pan
to a new view. This is because it is called each frame whenever the
current viewpoint is blocked. I'm sure I can make it pan smoothly,
but there were so many errors when I tried that I have postponed it.
-
Light control sometimes (about one in twenty times) skips a light (does
not switch it on when you cross its threshold z coordinate value).
The corresponding guiding arrows are also not lit up. When you go
back again and retrace your path, it works perfectly. <<Squished!!
- DB>>
In conclusion, thank you for reading these comments. And have
fun with the demos !!!
Deepak <debug@poboxes.com>
Page created by Deepak Bandyopadhyay on 1/30/99,
last modified on 1/14/00 at 12:50PM EST.