July 12

In the previous instalment of the Ten years of L3DT retrospective, we looked at L3DT releases 1.0 to 2.1, in which the whole map generation pipeline of L3DT was more or less developed. Today, we'll look at releases 2.2 and 2.3, which focussed on improving the user interface, improving calculation speed, and generally making L3DT more usable and useful.

Release 2.2 was a few steps forward with one step back. The step back was that mosaic heightfields were disabled, all on account of a pernicious bug in the mosaic water flooding algorithm, which wasn't fixed until L3DT 2.3. This bug cased the 'walls of blue jelly' bug in L3DT 2.1:

Mosaic water flooding bug, in L3DT 2.1.

Although mosaic heightmaps and water maps were disabled in v2.2, support for mosaic light maps and textures was maintained.

The steps forward were many and varied:

• Multiple climates were supported, much as they are today. This release included the familiar 'temperate' and 'arctic' climates. Alas, there was still no editor to be seen, so the climate files had to be edited manually using a text editor. A few intrepid users did master the dark art of manually editing climate files, but most were gravely injured in the attempt.
• Erosion was added, producing much more realistic heightmaps (see below).
• The water map flooding tool and water table modelling calculations were introduced. These allowed, for the first time, the ability to place mud or sand under and around lakes that weren't at sea level.
• There was a big leap in the speed of all calculations, owing to me finding the 'optimisation' option in the compiler. Previous builds of L3DT had been compiled in 'debug' mode, would you believe.
• L3DT supported its first compressed image file format (JPEG), and its first mesh file format (DirectX '.X'). Mind you, the mesh export was still a brute-force tessellation of all heightmap vertices, as the mesh decimator wouldn't be available until L3DT v2.9.
• The batch generator was included. In hindsight, this feature has rarely been used, but it did force me to develop a better model for how settings were stored and recalled, and this later influenced the design of the settings/project XML files and the plugin API.

The result of these changes was that the terrain output from L3DT started to look like it could actually be used for games:

After release 2.2 there were three revisions, 2.2a, 2.2b, and 2.2c. The only significant change from these revisions was that all map calculations were put in a worker thread, which meant that the program's user interface didn't lock up long calculations. This didn't make the program any faster, but it did at least give the user some confidence that the program hadn't hung. This change also allowed users to view the progress of calculations, and to cancel calculations, which was much appreciated and long overdue.

At this time, the very modest popularity of L3DT was too much for the truly pitiful download limits on GeoCities, so the website was moved to a new host, my then-ISP, TPG. The website was still laboriously written in static HTML though, as my subscription didn’t support PHP, ASP, or other server-side scripting. This became a bit of a limitation, and the website would soon move on to even grander digs for the next release (v2.3).

Version 2.3 introduced a few changes to the user interface that should be immediately familiar to users of 'modern' L3DT. Firstly, version 2.3 introduced the 'wizard' user interface, which replaced a set of rather clunky control dialog boxes. There were a few teething problems with the initial wizard implementation, including no support for display DPIs other than 96, but these were fixed fairly quickly. Although some wizard panes would be tweaked, they are fundamentally the same now as they were then.

Making a new map in L3DT 2.3, using the wizard.

Version 2.3 also introduced the 'next' toolbar button, which was a direct precursor to the 'calculation queue' wizard that is in modern L3DT. This button looked at which maps had and had not been generated in the project, and opened the appropriate wizard pane for the next calculation in the process.

This release also introduced the 'fancy' threaded progress window, which included a live preview of the map output as it was begin calculated:

The calculation progress window in L3DT 2.3.

There were also some changes to the way L3DT generated heightmaps and water maps:

• Thermal erosion was added to the heightmap generator. This more or less completed the 'design/inflate' heightmap generator, and there have only been tweaks since then.
• A 'Perlin' heightfield generator was added. At the time I had the expectation of adding even more heightfield generator options, like ridged multi-fractal and the like, but there wasn't much demand from the users' community, so the plans remain on the shelf.
• The speed of the water table modelling algorithm was improved by optimising the raster order. Like the height map generator, the water map generator in L3DT has changed only a little since this release.

In this version the light and texture map generators were re-written, and the alpha map generator was added. The light map generator received support for high-resolution, bump-mapped light maps with shadow anti-aliasing, which produced much more interesting results for cliffs and other rough land types (see below). The texture generator was modified to calculate the land type for every pixel when generating high-resolution textures, rather than just interpolating the land type as was done in previous releases. This resulted in much sharper transitions from one land type to the next, but was also quite a bit slower. Both the light map generator and the texture generator would be revised again in future releases (v2.4, v2.5 and v2.8), but the implementation in v2.3 was getting pretty close to the 'final' algorithms that we still use today in modern L3DT.

The high-resolution bump-mapped light maps and textures of L3DT 2.3d.

For version 2.3 I finally found and fixed the bug in the mosaic water flooding algorithm that caused the 'walls of blue jelly' problem, so I re-enabled mosaic map support for heightmaps and water maps. I also modified the design to use 64-bit addresses, which increased the size-limit for mosaic heightmaps to 128k × 128k pixels (16 Gpxls), and the size limit for texture/light maps to 4M × 4M pixels (16 Tpxls). With the return of mosaic height maps and water maps, L3DTVi2 was rebuilt by Stuart to support mosaic maps, and included a nice water texture:

The water texture in L3DTVi2 for L3DT 2.3.

In this release, file format changes weren't very significant. The PNG image format was added, as was a RAW exporter for the heightmap. Some of the historical, proprietary formats used by L3DT were removed (LMF, TNF, etc.), and were replaced by either PNG or JPEG. Some settings that were stored in the map group file (the precursor of the project file) were split out to a separate map definition file, which could be run by the batch generator to make another map with the same settings. The map definition file, appallingly enough, used a text format in which all the settings were declared in a primitive home-baked scripting language, so that the file was executed by L3DT to load the settings. This nasty kludge would be fixed in the next major release, v2.4.

I found it amusing to note that the development plan for version 2.3 listed support a scripting language. Sadly, release 2.3 did not support scripting (other than the crazy settings files), but this feature remained on the development plan until delivered in release 2.5 with the 'cdPython' plugin (by Carl Douglas) and the 'ZeoScript' (by yours truly).

L3DT was split into 'Standard' and 'Professional' versions with L3DT v2.3b. Although the Pro version was still free to use at that time, the groundwork was being laid for the commercial sale of L3DT Professional that began with L3DT v2.4.

Would you believe that version 2.3 was the first release to have an installer? Prior to v2.3, the user had to unpack the zip archive and copy the program files manually, which wasn't so flash. My memory is a bit hazy, but I seem to recall that for version 2.3 I used some installer system from Microsoft (possibly Visual Studio?) to make an MSI installer. It turned out to be a little quirky, including - if I recall correctly - requiring the same drive mappings on the user's computer as was present on the system that compiled the installer (i.e. my computer). This wasn't great, so in release 2.3a, I changed to the Nullsoft Scriptable Install System (NSIS), which I still use today, and with which I am quite satisfied.

The website was in quite a state of flux in the v2.3 era. Following v2.2, the amount of user feedback and questions I had been receiving had grown such that I needed a public forum to list questions and answers. For v2.3, I introduced the L3DT Yahoo! users group mailing list. There were a few really good discussions there, but it was not to last. Before even version 2.4 was released, I had moved the whole website to the new domain at bundysoft.com, and replaced the mailing list with the current forum, wiki, and image gallery, which have proved much more satisfactory. In other web news, the now-venerable fjord tutorial was added, giving users the first proper start-to-finish guide to using L3DT.

Well, that's it for the v2.3 story. By this point, L3DT had moved from being fairly limited, crude, and unpolished, to being much more powerful, relatively refined, and generally useful. Stay tuned for the next instalment of 10 years of L3DT, in which L3DT goes on sale, hooks up with GarageGames, gets a new 3D renderer, gets a whole host of plugins, learns how to do 8 things at once (multi-core multithreading), and generally gets pretty awesome.

Until then, ciao, Aaron.