[C4:AC][Programming][Graphics] Terrain textures

[wgabrie]

Can I trouble you to do it again with this second texture?

moist3test.gif (80.76 KB)

[Rubin]

Did 3 screenshots with the moist3test texture.

Temporarily uploaded here: Edit: File removed.

[wgabrie]

Rubin I did as you said. I did a search for the cache folder and found it. After deleting it I can now see the textures. One problem I see is that sometimes textures get "stuck" in the cache folder and modifications don't show up. Someone should definitly write this down.

[wgabrie]

I think I now understand what's going on with the textures. The top half portion of the DDS file is used for edges and joints. The DTXBmp program has a button under that alpha mask window that lets you view the transparencies. Basically, pure Black is transparent, White is solid, and gray is translucent. I won't be covering that here.

What I do want to add is that each "game plot" in Civ 4 is made of 4 tiles arranged in a 2x2 grid. Each tile is 64x64 pixels in dimension. When the 4 tiles are put together it makes the 128x128 pixels used for the game plots. There is some seemingly random use of the pattern on the bottom half of the file. But I'm fairy sure there is a pattern in there as well as the top's "transitions".

[Rubin]

wgabrie, I hope we can use the existing alpha masks (embedded in the .dds files) and simply modify the texture part. However, there seems to be some kind of "layers" added to the base terrain texture (the *detail.dds files). Have you been able to figure out how these are applied?

An idea for testing: Maybe use a map of "Planet" (there is a Civ4 conversion already in the game). That would give us an easy reference for comparing the new textures with the original SMACX map.

Oh, and the 2x2 grid makes good sense for "square" tile texturing. Good findings, wgabrie!

[wgabrie]

I have not tested the *details.dds files yet. But I'm almost positive that there's one gradient that is applied to all game plots of it's type. It's a height map with the lighter areas being higher.

For example, the mountain detail has white for the top and we can see how tall it appears in the game. I don't know if there's a fixed pallete or if any grayscale value will do. On the other hand I may be confusing the textures with the hightmaps in another of the art folders.

[wgabrie]

After some testing I find the files don't affect height. They only add texture details to the file. This seems like overkill, having two files, but you can do interesting effects with it. Not to mention it doesn't do random patterns like the *blend.dds files do.

Like *blend.dds, the file is broken up into 64x64 tiles, I placed a test pattern (74 KB) into the game and marked the plot boundries (13 KB). Also I put in a texture to show what you can do. Blend edit (55 KB), and, In Game (97 KB).
The file acually supports color. But I'm guessing it was ment to be more of a high-lighter than a full texture file.

[Rubin]

wgabrie, would this mean that we can leave the *details.dds files blank and try to focus solely on the *blend.dds files? If this is an option then we may later add the details.

Perhaps we can use the floodplains for the SMACX monsoon jungle (and remove the health modifier). Maybe hills could be used for rolling and rocky terrain? If nothing else, I believe this would be a step closer to creating a SMACX world.

[wgabrie]

Yes we can leave the *detail.dds files blank. As for the hills, good idea, we can do what we want. I'm hoping eventually to figure out how the hills are higher than flat terrain. Then we can create >1000m terrain effects.

But for now, we can just alter the defalt files, and define them more when the progamers have a better understanding of creating terrain file assignments in code.

[Rubin]

Excellent, wgabrie! We should try doing an overview of the files that we need to modify and perhaps try organizing the exiting terrain to match the SMACX features.

I completely forgot to address ice and tundra tiles; we may be able to use those as well.

[wgabrie]

Okay, I'm not good at organizing this but here goes: SMAC has 3 rainy settings, 3 rockyness, and 3 height settings(<1000m, 1000m, and >1000m).

Our first priority should probably be implimenting all 3 rainy settings. And some other terrain.
Desert = Arid
Plains = Moist
Grassland = Rainy
Fungus = ?
Jungle = ?
Forests= ?

I noticed that hills depend on the texture under it for display. So, as far as rockiness goes perhaps we can do:
Normal Terrain = Flat
Hills = Rolling
Mountains = Rocky

I think height (not to mention landmarks) will require digging into the programing code and creating new terrain files. We'll need some coordination between us and the programers to solve these problems. So, first lets get the other things done.

[PJayTycy]

Originally posted by wgabrie
Desert = Arid
Plains = Moist
Grassland = Rainy
...
Normal Terrain = Flat
Hills = Rolling
Mountains = Rocky

This sounds good , but we should make sure to make mountains not impassable then.

Aren't these cell-types (properties + textures) defined in XML ? It would be strange, and one of the only things they left out of the easy-to-mod box.

Height will indeed be a problem untill the SDK is available (and even then I have doubts about the possibility to display height graphically).

I believe you'd have all basic terrain then, because fungus and forest are more some kind of "improvement". ie: you can plant and remove them while retaining the underlaying terrain type.

[Senethro]

Just to offer an alternate system...

Would it be easier to have all landscape textures drawn as arid/flat, arid/rolling and arid/rocky instead and have the moist/rainy as an "improvement". This might make it easier when (if :/) we get to the point a dynamic climate affected by height can be created.

With rockiness as the texture and moisture as an overlay, that would leave hills and mountains to be changed into terrain height. I was wondering if by fudging the size of hills so that they overlapped their tile if an illusion of a flat plateau could be created. I've noticed that hills diagonally beside each other have a small ridge between them. Does anyone know how thats generated? It could be useful for smoothing out slopes.

[Andux]

The basic terrain levels allowed by the SMAC map format are:

• Ocean Trench
• Ocean
• Ocean Shelf
• Just above sea level (<1km)
• One level above sea level (>1km)
• Two levels above sea level (>2km)
• Three levels above sea level (>3km)
• Four levels above sea level (>4km)

Rockiness was implemented as a sort of overlay, but since it behaves more like a terrain type than moisture does, I would say that Senethro has the right idea.

Either way, though, you're looking at implementing 18-24 different terrains.

[wgabrie]

Looking at the directory structure I see no overlay option. Each texture has 3 or 4 files connected to it.

1) *blend - Default graphic texture
2) *grid - same texture graphic as *blend but with grid
3) *detail - Used to create the effect of highlights and contours.
4) Hightmap - Only some terrain, like Hills, store height and govern connective links, between the same terrain, in TGA format. It's in the heightmap folder.

In Civ 4 I can't create an arid tile then overlay rocky/rainyness/height. There's no implementation for that, which I know about. What can be done is create a new file-set for each implementation. I would create separate files for an Arid flat, Arid rolling, and Arid rocky. Then I'd need to copy a new set of files and assign them a heightmap for say 1000m, Then another set for 2000m, etc.

Further complicating things is this all needs to be assigned in code. Not being a programer, or having access to the language or scripting, all I can do right now is alter the existing Civ4 terrain. I can't just go and create new files and test them. The game has to be told that these are terrain types I want in the game. And, where to put them. I'm guessing there's a whole routine that needs to be written so that a tall 3000m tile won't be placed in the middle of an ocean trench.

In addition, some "improvement" type terrain like Trees are stored in 3D files. So far, no one has been able to open these yet. I am really hoping for a break from the SDK when it's released, else we'll be in a pickle.