WALK - Realtime Architectural Walkthroughs
Clients are expected to visualise large complex architectural models given
only a two-dimensional floor plan. A better approach would be to provide a three-dimensional
view of the building, as seen from a hypothetical human observer. The client
should be able to interactively control this observer, so that it is possible
for them to explore the architecture before it is built.
The architectural model must be completely dynamic. That is, the designer must
be able to make changes to the model without having to perform an expensive
pre-processing phase. The only acceptable exception is pre-calculated lighting.
Radiosity and raytracing schemes are far too slow to be performed in realtime.
As a compromise, the system should support both dynamic lights, and more realistic
pre-computed light maps.
The architectural walkthrough system described in this paper does not require
any specialty hardware. It simply requires a desktop PC equipped with a recent
graphics accelerator. To achieve interactive frame rates, the system uses a
model that is partitioned into cells and portals. These cells and portals are
stored in a cyclic scene graph. A depth-first-search starting at the viewer’s
cell calculates the visible cells. Hidden cells are quickly culled by checking
portals for visibility. If a portal is not visible, the cell behind it is also
not visible. In this manner, a large amount of geometry can be culled away.
The results show that this cell and portal approach is very effective. In wire-frame
mode, it is very clear that hidden triangles are quickly culled away. Because
the system is very scalable, this statement will hold true for architectural
models composed of millions of triangles.
This engine contains a few interresting bits you may want to know about:
- Scenes are stored as a cyclic scene graph and rendered using a depth first
search. The scene graph also allows multiple instances of the same mesh, textures,
etc. Cells and portals are nodes just like anything else in the scene graph!
- Scenes are stored in an object based file format similar to VRML (but more
generic). The source contains a proper scanner and parser to load these files.
Have a look at the scene files and it will make sense...
- The loader uses RTTI to find node constructors at runtime (a node is an
model, a light, a camera, etc). The engine was desined to parse through a
directory of DLLs containing node classes. You can then provide a scene file
with your own custom nodes along with a DLL that implements those nodes. I
had this working, but took it out of the sample application because I didnt
- Entire engine is designed as a framework. Both the RenderDevice (eg: OpenglRenderDevice)
and the RenderProcess (eg: PortalRenderProcess) is abstracted can be changed
- Scene graph nodes use quaternions to describe their transformations. This
has both advantages and disadvantages - and I'm still not sure whether this
is a good thing or not :)
- The viewer can be attached to any node. In fact, a camera is just another
node in the scene. Look at this code if you want to know how to implement
a "proper" camera system :)
- This engine was state-of-the-art back in 1999! The only two major things
lacking were animation and collision detection (ie: a physics system).
- Project.pdf (488,338 bytes): The final version
of the project document. [Acrobat
- ProjectEXE.zip (1,180,978 bytes): The compiled
application, including a sample scene. Its ready to extract & run.
- ProjectSRC.zip (3,074,538 bytes): The full
C++ source code including the MS-VC6 workspace. This archive also contains
the compiled applications and sample data files. This code is one of my first
attempts at a large C++ application. The overall design is pretty good, but
the coding could use a few tweaks here and there :)
- ProjectDOC.zip (332,689 bytes): The source
documentation generated by Doxygen.
There's not much more here than a class hierarchy diagram.