IGHTC (In-Game Huge Terrain Creator) Part 2

So, the lesson learned is to wait until GG approves a resource before announcing it :-)

Here's just a quick update on the IGHTC project:

What I've Been Up To
All original pattern-layer code was successfully ported into TGE 1.4 HEAD, tested, and got a screenshot up. The test harness system will no longer be updated, and I'll be working strictly in TGE from this point forward.

I decided that it was going to be critical to have this as a wholly separate class, and so began development of the patternManager class, from which various other classes (like patternTerrain, for example) can be derived. For many of you out there, the Good Thing (tm) about this is that you'll be able to just drop a couple files into the /core directory and the /terrain directory, make a couple edits to some of the terrain classes and call it a day -- none of this mucking around with patch files. At least, that's my goal...

I've completed the implementation of the patternManager class, doing everything "the GG way" including figuring out how to instantiate the class without directly calling a new() method on it -- very nicely done, BTW. The first rendition of the patternManager has only these console variables available (since they are most critical): patternTerrainSeedX, patternTerrainSeedY, and patternTerrainLayers.

Currently, the system uses 5 terrain pattern layers by default, but you can go as high as 20 with minimal impact on performance. The vast majority of the getTerrainHeight() function uses bitwise operators and shift functions, so it's very fast -- it's about as close to Assembly code, I think, as possible. And is it ugly :-)

Unfortunately, if I want it to be possible to edit layer heights via the console, I'll have to create a separate variable for each ... it's either that or implement an ArrayType in the consoleTypes class, which I'm just not up for this year :-) So, you'll probably be seeing ugly variables like this patternTerrainLayerHeight1, patternTerrainLayerHeight2, patternTerrainLayerHeight3... etc :P ick

I've now got 3 slope functions that (a) work well in TGE and (b) create slopes that actually look nice in TGE. I was surprised at how much the rendering engine affects the look of the terrain being rendered. An identical terrain rendered as a mesh in DirectX 9.0c SDK looks a lot different than it does in TGE. Ideally, this will lead to something that will allow a developer to choose the types of slopes to use at the various layers. So, for example, you'll be able to select nice rounded hills for the lower layers, induction lines for the middle layers and jagged peaks for the top layers. No code behind this bit yet, but that's where I'm going with it. Of course, this means uglier console variables like patternTerrainLayerSlope1, patternTerrainLayerSlope2, patternTerrainLayerSlope3... ah well.

What's Soon
Re-building all the hooks to the various patternTerrain functions from a clean set of terrain source code files.

Clean up all the slope code.

Adding in the 20 patternTerrainLayerHeightX console variables (for now, I'll just use the same slope formulae for all layers).

Once I have the layer heights available to the console, it'll make it really easy to being tweaking the heights and the number of layers I'm using to make some better screenshots.

Posting and updated Development Screenshot, this time with more than 1 screenshot :-)

What's Next
Start working on the GUI to allow editing of the patterns and the layer heights. Dev Screenshot of that once it looks nice and is easy to use (and works).

Start digging into the process of "repurposing" the original heightMap array. My "crazy idea" at this point is to simply expand the size of the heightMap array (change BlockSize) so that it is equal to (viewDistance x 2) +1 so that only 1 rep of the texture is ever seen and then using setHeight to dynamically change the current heightMap to exactly match whatever happens to currently be on the screen. Then the various and sundry texturing, blending and lighting functions can do what they'd normally do -- not knowing that they are performing their functions on a heightMap that was just dynamically generated. That should get texturing, blending and lighting to work with IGHTC just like it works now with stock TGE -- at least, that's the theory.

Record a movie of flying across the terrain and another movie of doing standard height- and slope-based texturing to show how those editing functions now work normally with IGHTC.

... that's probably as far as I want to plan for now.


Thanks again everyone for your interest and support!