|
Virtual CMU |
|
By Jonathan Navia and Brian Loo Core Technology: Epic Games Rendering Upgrades: Nexs Interactive |
|
Gallery |
|
Click on
the images for larger versions.
|
|
The Idea |
|
·
The
goal of the project was to develop a real time virtual tour of the Carnegie
Mellon campus using the latest rendering technology and interact with Artificial
Life forms (“Actors”) to help showcase the world. ·
A side
part of the project was to adapt gaming technology for non-gaming purposes.
Especially in the field of graphics, gaming technology is more sophisticated
than non-game targeted graphics. This project sought to remove the game from
the engine and create something entirely different. · The base technology used, especially in
the way of A.I. and rendering, was old… state of the art in 1998, but dated
in 2004. |
|
The Unreal Engine 1.0 |
|
·
The
Unreal Engine 1.0 was developed over a six year span from 1992 to 1998. In
its time, it was by far the most sophisticated engine. In 1998, most games
were just making Graphics cards optional. Unreal made them required. While
other games were doing low polygon (250+) environments with single-surface,
single texture rendering, Unreal was trailblazing with quintuple the polygon
count and surface multitexturing. ·
The
Engine was powered to do up to roughly 800 world polygons per view (30,000+
total for one world typically), and 10,000 non BSP polygons. An example of a
non-BSP polygon would be a player, a tree, a bird or a shrub. An example of a
BSP polygon would be a wall, the floor, a walk way, or a steps.
This is a picture of Unreal 1, by Epic
Games |
|
What were we going to change? |
|
·
The
Lighting engine was dated and used per planar, gourad shading lighting
techniques. This was fine for 1998, but is no longer acceptable for modern
computers or modern graphics. ·
We
adapted Nexs Interactive’s changes to the rendering engine dealing with the
horizon to make the world larger. Unreal 1 was designed for caves and
corridors, not wide open spaces. ·
The
artificial intelligence built into Unreal was typical game fare: monsters sit
around and wait for the player to find them, or walk in pre-planned area
(typically a loop of some kind). The most basic concept of the built in A.I.
were inapplicable to what we were going to do. This would have to be
completely rewritten. · Netcode – designed for a game, not for a
project. Very heavy client side. |
|
What was removed? |
|
·
We
removed everything designed just for the game itself: monsters, levels,
enemies, textures, sounds, music. There was nothing applicable in those
packages to our project. We essentially stripped a 500Mb Game down to a 125Mb
core highly modular, real time rendering technology. ·
The
Direct X rendering code. The engine was optimized for Direct X 6, not Direct
X 9, found on any computer with Windows XP. Direct X 9 runs Direct X 6 in a
slow and buggy emulation mode. This is largely unacceptable and creates
problems with end-user uniformity. Thus, we scrapped the DX9 rendering core
and are relying solely on OpenGL. ·
The old
lighting engine ·
The old
A.I. and Netcode was removed. |
|
What was added? |
|
·
We
added rewritten A.I. (the meat of the project) ·
We
added a new lighting engine based around per-vertex lighting. ·
We
added “Observer mode”, complete with vector positioning “laser” for the user to
interact with the environment. ·
We made
our slight rendering engine alterations. ·
New
textures, models, and of course, virtual CMU. |
|
The Net Code |
|
·
Unreal
was designed to be an action packed video game with humans fighting giant
lizards. The net code was designed for that purpose, and not for the sake of
a virtual tour. Since it is a video game, it is heavily client-side based.
Essentially, when there are multiple users, each client is running the game
independently, the server merely keeps server specific information (like your
position in the world with relation to others, the time, communication
protocols) distributed across the entire network. ·
The new
Net Code planned to be implemented will be heavily server side. Right
now, the client-server package is the same – about 250 Megabytes. This is
unacceptably large for any sort of virtual tour program. A maximum accepted
size for a client should be on the order of >6 Megabytes, preferably
around 2.5Mb. · Right now, the maps, observer, textures,
everything is client side. With the new server side model, everything except
a simple client program and the world geometry would be sever side. Textures,
lighting information would all be streaming. This is exceptionally ambitious
for this engine, but it has been done by a company before. |
|
The new Lighting Engine |
|
· Most common architectures of graphics
accelerators contains a processor with on-chip program memory and main memory
for data to be used. This is a cheap solution but today’s state of the art
graphics still have a lot of
triangles, textures and fill rate. So the bottle-neck problem limits
performance. In addition some effects like dynamic shadows, non-flat mirrors
and refractions can be done as simulations with many artifacts. Much of these effects require more
bandwidth. Ray tracing is potentially more progressive technology . · The Unreal Engine has built in per-planar
lighting technology. We’ve implemented ray tracing. More specifically, we
implemented a model for diffuse ray tracing based on point lighting. (Image
Credit: http://claymore.engineer.gvsu.edu/~jackh/eod/software/software-122.html#pgfId-3409).
Essentially, Brightness (in the general case, must be computed for RGB) is
based on the cosine of the angle the light source is being observed from,
multiplied by the I (Illumination) and K constants, divided from the distance
of the surface being viewed from the light. This allows the entire world of
vCMU to be lit by a single light object. Levels designed for the game
using the old lighting technology had hundreds of individual light objects.
This promotes a smoothness, even a glossiness to texture surfaces.
· This image shows differences between
floating point calculations L = I*(cos(a)/pow(r,2)) for per-planar lighting
and the integer function used in this lighting model. The green line is
floating point value. As you can see, the model we used has a higher level of
precision, translatable to more sophisticated and realistic lighting.
|
|
Artificial Intelligence |
|
·
As
previously stated, the built in A.I. was completely inapplicable to our
project. It was based around a concept that was foreign to a virtual tour,
necessitating a complete rewrite. ·
The new
model is not terribly unlike some Mobot robots or primitive path finding
robots. ·
Each
“Actor” has a list of directives, primary, secondary, tertiary, a job, and an
idle job. The directives are hierarchical in nature. For instance, a tour
guide’s primary directive may be to not “loose” the observer, its secondary
directive to take the observer on a tour, and its tertiary objective to make
“small talk”. Using the pre-laid node
network, the tour guide walks the “path” using dijkstra's algorithm to find
the path before taking the first step. ·
Each
area of interest (for example, Entropy or the Book Store) has a major
“keypoint” along the node network. Actors do not follow the node network
precisely. It acts more like a guide. They have a degree of freedom from the
nodes and don’t walk in a straight line, but along the general path.
·
Non-tour
guide Actors have the same model, with more of an emphasis on “Job” and can
wander the world along a pre-laid node network. ·
Right
now, interaction with Actors is via menu based system. The only input in your
selection and they give an output. We will soon ad a degree of randomness to make
conversation more interesting, and eventually, hope to make a non-menu driven
interaction system, possibly utilizing assigning common phrases and questions
to keyboard buttons and making the responses by the Actor dynamic. ·
Programmed
in UC, a proprietary object oriented language that is based upon a merging of
Java and C principles and some syntax, but designed specifically for this
engine. A sample of the code is below (click on the image).
·
Here is
an image of the node network (the apples) as viewed from the editor. You can
see a keypoint in front of the door to the Bookstore. Despite the fact that
the network nodes are along the center of the path, tour guides do not walk
in a straight line and have a degree of freedom on the path. |
|
How we made vCMU |
|
·
Making
vCMU, the tour-world, was not the most time consuming part (that honor
belonged to the A.I.). ·
Step 1,
Get Textures: In making CMU, we needed CMU specific textures. Despite the fact
that the campus is vast and has an millions of unique and different surfaces,
for our purposes, the campus could be viewed as having a high degree of
uniformity, for instance, white concrete walkways, yellow bricks, white
concrete trim on buildings, green room and trim, red and black signs. Still
this meant we had to take hundreds of pictures of campus, not only of
textures but of reference for building the world.
The Yellow Brick texture used for the UC
and Purnell
The face of the Bookstore. In world, the
sign portion was modeled and the texture applied to
its surfaces. Step 2, get Reference pictures. Used to help establish where things
are with respect to one and other, scaling, surface textures, and lighting.
Two reference pictures, used for figuring
out scale, and where things are. ·
Step 3,
build the world using the engine world development suite. This is something I’ve been doing for years
now, but for video games, not for non-video game related projects. Using the
development suite, we took the data gathered from the pictures and the
textures, and the new lighting and AI engines we made and built CMU. I
started with the
·
Then
the node network was laid out. |
|
And then there was… vCMU! |
|
|