Improvements to Terrain Module

The following lines describe in more or less details what could be done to improve the terrain module. Everything is mixed up, simple patches and complex and complete modifications.

Include a mesh_p to each function so that it can handle more than one mesh at the same time.

Do a correct fill routine, in a manner similar to drawLine(). This routine, if it is sufficently fast, could be used in both the mesh creation part and the rendering part. In that case, it should be called tutl_something().

Add functions to be able to deform the terrain in some place: One, general, which recomputes lighting and normals for a given table of points somewhere in the table. This function could be done by extending the

createVertices()

to computations on rectangular zones and by extending createMesh() to computations on rectangular zones and with an initialization option only (it is, for now, mandatory). Some other functions could then be made, in order to mimic erosion, rivers beds, and so on (look the skyfly demo on SGIs for an example).

Allow recomputing of lighting, in case the world lighting has changed (see above).

terrain_type() should also return vector type when the position lies over a vector. This is basically just a call to itemInVector() at the correct moment.

Vectors are elevated over the ground of a few centimeters, but they are still parallel to the plane of elevation 0. They should be tilted (mean of the two end frames for example). Once tilted, they could lie closer to the ground (go and see the current value in VECTOR_ELEVATION!).

Add roads as vector items: it is the same as rivers, with a different color.

Vectors could be read from a file, as the items. A telephone line is also a vector; roads could contain lines. Tilting should be optional in the file (a telephone line is not normal to the ground!) and it should be possible to describe vectors in the space and what should be displayed at the keys points of the polyline and what should be displayed between those key points.

Vectors should be tested on triangular meshes!

Fog could be made also on SUNs (mimic the AIX fog).

The terrain.c code could be cut in two parts: one for the file reading and another one for mesh construction and utilities.

Extend GRASS_TO_SNOW: give an altitude for the snow, to replace the altitude of the highest point. It could be possible to extend the principle to mix any two different type of terrain.

Suppress the second color on cells, it is no longer used.

Make a nicer terrain.data reading: Reading, for each terrain type, the number of possible templates from the file. Reading, for each item, the type of terrain it corresponds to (i.e. indexing the file). Add one function which calculates the number of item types for each given terrain type.Add the terrain type in the template_t structure. Modify, finally, the makeTemplates()function.

Debug terrain_giveElevation(), it is still buggy on quad-meshes.

When giving the frame on a given terrain location, interpolates the normals instead of considering that the terrain is plain. The car would be smoothly tilting. The terrain could be locally interpolated with splaines.

Clouds could be easily rendered using textures.

Textures could also be added on vectors, items and so on... But this is a long and difficult way. Furthermore, it will only works on fast SGI machines.

To avoid the abrupt end of the world, the terrain could be surrounded by some very big plane rectangles.

Make some kind of terrain_render_data, similar to render_data, and containing all the global variables of the terrain that may be used from the renderer.

Various heights and sizes for the houses could be easily implemented by modifying terrain.data.

Simpler houses should be used when the density is high, otherwise this is too slow.

Avoid that items intersect. This can be done by testing all the vertices of a polygon against the bounding boxes of all the previously added items. There is one danger: an infinite loop if there are too many items.

Add some real water. The water should not be hilly! The water level could be some average of the surrounding edges. There could be also some elevation for the water, in that case, these elevations should describe the depth of the lake in different points.

Dealing with more than one mesh by introducing BigWorld coordinates (which index in a huge grid of several meshes) and render in those coordinates. The renderer determine on which of the 9 current meshes in memory the user is and fetch the cell and strip. The 9 meshes in memory and they are dynamically swapping from disk to memory. A last problem: How to implement AIs that need information about all the terrain (i.e. maybe hundreds of meshes)?

Make some Gouraud shading on the trees, to mimic, once again, a kind of texture.

Villages and towns should be different and have different houses types.

Saving of a mesh, currently coded in tr2tz could be implemented in a module function and one could experiment a real state transfer using the saving and loading functions on the opened sockets.

Author

Emmanuel Frécon / emmanuel@sics.se