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.

Pictures

The Engine

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 need it.
• Entire engine is designed as a framework. Both the RenderDevice (eg: OpenglRenderDevice) and the RenderProcess (eg: PortalRenderProcess) is abstracted can be changed at will.
• 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).

Download

Download (27/6/2004):

• Project.pdf (488,338 bytes): The final version of the project document. [Acrobat Reader]
• 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.