LingoLand: Simple 3D Terrain Simulation in Lingo, Part 2

April 22, 2001
by Andrew M. Phelps

The first installment of this article covered the generation of a terrain mesh and the routines needed to draw the generated surface. To wrap things up, let's look at how lighting affects the coloration of the surfaces, and how things could be made faster.

Lighting

Basic Lighting Theory

Computer lighting models have been around for years, and nearly all of them start with the same first steps: ours is no exception. First, the engine calculates a normal to the surface, and then compares this normal to a vector from the same surface to the light source (see figure 3).

Figure 3: Simplistic Lighting Theory based on surface normals.

The engine then computes the color based on the distance of the surface away from the light and the angle between the two vectors described above. Most engines add in the ability to add some small percentage of color based on an ambient light value [Foley et al 1987, 1996]. Thus, the basic mathematical implementation of a lighting system (for a single light source) is relatively simple.

Lighting the Land

There are, however, some rather particular features of our Lingo engine that make the lighting calculations slightly more complicated, namely the fact that we are using quads instead of triangular surfaces. This is unfortunate in that while a triangular face can produce a single correct normal to the surface, a quad can make no such guarantee, because there is no mathematical certainty [Edgerton, Hall, 1999] that all four points lie along the same plane. Indeed, in our engine we almost would desire that they do not if we are attempting to get mountain tops that end in sharp peaks.

This engine takes the following solution: it divides a quad into two triangles, calculates the normal for each triangle, and uses the average of those vectors as the normal for the lighting calculation. This is certainly not an optimal solution the engine was attempting a smooth shaded look which involved lighting calculation within the quad, however since each quad is one and only one color, this has the visual effect of being believable, if not perfect. A more robust engine could in essence use quads to simulate triangles, thus wasting a data point, or any number of other solutions, including the notion of calculating the light color at the points and blending inward towards the center of the face.

In any event, we now have the angle of incidence between the surface normal and the vector that points to the light source, in our case the gSun object. Using this angle, we compute the color of the tile, modifying the base color we receive from elevation based on the ambient light present, and the properties of the light describing its color, intensity, and decay (see commented code for more detail on the exact calculation). The basic formula for these calculations is described in Foley's definitive work on the subject [Foley et al, 1987, 1996]. The lighting can be used to produce a variety of effects, based on placement and color (see Figure 4).

Figure 4: Land at Sunset (gSun at low Y large negative Z) at 5 subdivision.

View the terrain generator movie.

Future Optimization

Data Structures and Object Methods

This engine is not designed for speed. More to the point, it is not structured for speed. There are a variety of reasons for this, not the least of which is legibility for students experimenting with systems like this for thie first time. One of the primary bottlenecks in this application is the calling structure for the VBLF.project method. This is caused by the delay in Director's interpretation of calling methods of objects, which is greatly exaggerated by the fact that this call is placed in a double repeat loop within the RenderGround handler. The following syntax inside the repeat loop would offer a significant speed increase (see listing 1).

Listing 1: Enhanced method-calling structure using alternate Lingo syntax.

While this is a large speed increase, the optimal method to use the call syntax for multiple objects is not to use the call function directly but instead to pass to the call function a list of objects. This can offer very significant performance savings, however, it involves a complete reorganization of the data structures that we use to house the VBLF's, since it requires a flat list as an argument. Likewise, referencing properties from outside of an object is slower than referencing the same property internal to the object, much of the code could be reorganized to fit more directly within the objects and thus cut down on the number of external references. This could have significant impact with the lighting routines and the way the render functions are separated (and whether or not they should be).

Conclusions

In this article we have used a simple 3D engine to create a simple random surface, used lighting algorithms to modify the color of that surface, and used that surface to simulate a simple terrain. This engine, or any similar scale application is capable of much more, this application serves as a basis for understanding the concepts of terrain simulation, without the complexity overhead of a more traditional language or terrain-generating algorithm. This work is not highly optimized; it should instead serve as a clear, precise example for others to follow and extend to a more fully featured engine. This application is in turn only one possible extension of the engine created by this author, another more robust version of which is also planned for publication.

Future Work

My students have already extended this project to include a variety of functions: namely saving and loading terrain files, using a bitmap as an elevation map to create the terrain (using imaging Lingo's getPixel function), and massaging the engine to perform up to 6 times as fast. Additionally, some of them allowed the creation of 'terrain worlds' on cubes, rectangles, spheres, etc., and at least two of them managed to implement a simple texture mapping system across multiple quads. Most all of them created control panels external to the original window to avoid the clipping problems present in this demo.

One area in which this application could be extended would be in multiuser functionality. Currently there is no support in the engine for this capability, but it is high on the list of desired functionality that most people seem to want out of graphics engines. If the user has the ability to control light placement, tile size, etc, then this present a technical issue in synching the two. Additional support for displaying real time graphics (which would most likely break the 'trails' solution) is inherent to the engine, however as discussed significant portions of the code would need to be reworked.

A sample Director 8 movie is available for download in Mac or Windows format.

Acknowledgments

I would like to acknowledge my colleagues at the Rochester Institute of Technology, and in particular Professor Steve Kurtz, who shares my interest and passion for writing graphics programs and extending Lingo into this arena. I would like to publicly acknowledge all the support that this author has received on the DirGames-L mailing list, and thank the University of Georgia for hosting the list. Many thanks to Barry Swan, NoiseCrime, and others who have inspired us all to push Director to its limits: code long, code late, code happy.

References

P.A. Edgerton and W. S. Hall. Computer Graphics: Mathematical First Steps. (1999). Prentice Hall Europe:Essex, England.

James D. Foley, Andries van Dam, Steven K. Feiner, John F. Hughes. (1987, 1996 2nd revised printing).Computer Graphics Principles and Practice - 2nd Edition in C. The Systems Programming Series. Washington, DC: Spartan Books.

MIT Epistomology Group, Media Lab, Massachusetts Institute of Technology. Introduction to StarLogo. (2001) Online: http://el.www.media.mit.edu/groups/el/ Projects/starlogo/index.html.

Steven Kurtz. Turtle World. Forthcoming. Featured Article in Using Director Ð Director Online. Online:

Steven Kurtz and Andrew M Phelps. Vector Based Life Forms, a 3D Engine Based on Turtles. Forthcoming. Featured Article in Using Director - Director Online. Online:

Andrew M. Phelps, Daniel R. Kunkle. Teaching Old Turtles New Tricks: Artificial Life Simulations in Lingo. Forthcoming. Featured Article in Using Director - Director Online. Online:

Andrew M. Phelps. Perspective Based Lingo Mazes: The Director Dungeon Crawl. February 2001. Featured Article in Using Director - Director Online. Online: buildArticle.php?id=958.

Annotated Bibliography

[L] Lingo based 3D Code; [M] Mathematics; [R] Rendering.

1. Cole, David. (2000) Dave's 3D Engine v. 7. Online. http://www.dubbus.com/devnull/3D/. [M][L]

2. Edgerton, P.A & W.S. Hall. (1999) Computer Graphics: Mathematical First Steps Essex, England: Prentice Hall. [M]

3. Lithium. (1999-2001) Three Dimensional Rotations. Online. http://www.gamedev.net/ [M]

4. McNally, Seumas. (1999-2001) 3D Matrix Math Demystified. Online. http://www.gamedev.net/ [M]

5. Perez, Adrian, Dan Royer. Advanced 3-D Game Programming Using Direct X 7.0. Plano, Texas: Wordware Publishing. [M][R]

6. Rodgers, David F. And J.Alan Adams. (1976, 1990) Mathematical Elements for Computer Graphics 2nd Ed. New York, New York: McGraw Hill. [M]

7. Rodgers, David F. (1985) Procedural Elements for Computer Graphics. New York, New York: McGraw Hill. [M]

8. Swan, Barry. (2000) T3D Engine. Online. http://www.theburrow.co.uk/t3dtesters/. [L]

9. Tamahori, Che. (1999) How to Cook 3D in Director. Online. http://www.sfx.co.nz/tamahori/thought/shock_3d_howto.htmll. [L][M]

10. Watt, Alan and Fabio Policarpo. (2001) 3D Games: Real Time Rendering and Software Technology. New York, New York: Addison-Wesley ACM Press. [M][R]

11. Zavatone, Alex. Inside Zavs Brain: 3D Director. Online. buildArticle.php?id=286. [L]

Copyright 1997-2024, Director Online. Article content copyright by respective authors.