I have been working on multiple TAW upgrade projects, however, there are two which are considered major projects. I will discuss one of them, the Surface Texture Solution Project, here.

This project started out as a simple desire to solve one of the problems of TAW, visual target acquisition and to upgrade the graphics, at least temporarily until we can get some more permanent model upgrades.
In an effort to define the problem some of you were having with the difficult target acquisitions issue, I identified one major obstacle to obtaining improved targets was the muted default textures which are often difficult to see, especially against the background of the bright new terrain colors in 2.0.

In order to accommodate for that problem I attempted to modify the code in the .3D object files but was frustrated by the inflexibility of the coding. Therefore I discovered a method to exploit the channels used for texture mapping.

In general, the .3 file determines the texture or the color of the specific object as Mikew previously explained:




In TAW Texture mapping of building textures is switched on or off in Game.cfg using the key “BUILD_TEXTURE =1” or 0. If the textures are off (0), then the indexed texture is not used, in this case, the program uses the color determinants for the vertex indices which are given after the palette index in that string. If the texture is off in options the executable will only use the colors coded. Until now, these were the only options a player was priviledged to use. Now that has changed and a great many new options are going to be made available as I have determined that, if the Textures are ON the executable calls the time appropriate Redxxxx,ini file [surface] section which is where I found a way to intercept and manipulate the process for graphically improved targets. The [surface] section will accommodate, and defaults to, texture mapping. It will now also however accommodate a total of four types of surface treatments:

1.) Textures: txtr
2.) Colors: colr
3.) Flat Shading: flat
4.) Gourard Shading: gour

I have developed a number of full Templates to facilitate the efficient import of texture shader transitions into the redxxxx.ini files. Below I have given the first few lines of several of my basic Templates.

Examples:
TAW DEFAULT TEMPLATE
[surface]
0=txtr 4,(0,0),(31,0),(31,31),(0,31);N CONCRETE
1=txtr 4,(32,0),(63,0),(63,31),(32,31) ;NE CONCRETE
2=txtr 4,(64,0),(95,0),(95,31),(64,31) ;E CONCRETE

GOURAUD SHADER TEMPLATE
[surface]
0=gour ;N CONCRETE
1=gour ;NE CONCRETE
2=gour ;E CONCRETE

COLOR TEMPLATE
[surface]
0=colr ;N CONCRETE
1=colr ;NE CONCRETE
2=colr ;E CONCRETE

FLAT SHADER TEMPLATE
[surface]
0=flat ;N CONCRETE
1=flat ;NE CONCRETE
2=flat;E CONCRETE



The colors and shades of the individual polygon (tris and quads) vertices can be individually and specifically implemented and controlled by describing the desired index value.

Example:

[surface]
0=flat 6,7,8,9 ;N CONCRETE

ie. Flat shading of polygons progressing from the palettes Dark red (index=6) to Bright light red (index=9).

Assigning vertex shading values can control the Lighting conditions within the graphics environment using the directional assignment keys (;N, NE:, etc). This is a marvelous way to simulate time of day conditions, sun, moon effects. (It must be kept in mind, however that 3D object rotational variations must be considered for proper lighting effects outcomes). Flat shading, while one of the earlier shading techniques, works well and can be advantageous for TAW because of its significant improvement when used in the modeling of boxy objects.

Example:

[surface]
0=flat 0,0,0,6 ;N CONCRETE
1=flat 0,0,0,6 ;NE CONCRETE
2=flat 0,0,0,7 ;E CONCRETE
3=flat 0,0,0,7 ;SE CONCRETE
4=flat 0,0,0,8 ;S CONCRETE
5=flat 0,0,0,8 ;SW CONCRETE
6=flat 0,0,0,9 ;W CONCRETE
7=flat 0,0,0,9 ;NW CONCRETE
8=flat 0,0,0,0 ;BOT CONCRETE
9=flat 0,0,0,0 ;TOP CONCRETE

The Gouraud Shader is the smoothest and most advanced of the shaders in this application. The volatility of the color transitions was initially difficult for me to control. Mostly as a result of the shaders color interpolations of the 3D models specular highlights. Because TAW surface objects have large polygons with low counts, Gouraud interpolates the specular highlights at the vertices and then produces the progression of the highlight across neighboring polygons with a “fade-in”, “fade-out” pattern that, with any rotation of the object or the viewers perspective, gives off an intense color barrage. I have been able to better control that volatile interpolation pattern but still working on a best solution.


Digital Image Design continues to impress (especially that Steve Hunt guy), with each discovery, the talent, skill and dedication they placed in this simulation. For reasons of their choosing, DID determined to use textures exclusively for their surface object solution. It was, apparently, the simplest practical solution to implement in 1997, given the state of PC power and graphics at the time.
It is important to note that truly good power resides within the TAW palette, as the colors have true functional affective capacity and can dictate events in the game experience. A part of the ongoing challenge is to discover the functional impact of all given colors, textures and shaders.

It would seem logical that a significant enhancement to TAW can now be had by implementing a hybrid solution upgrade. That is, using a combination of textures, colors and shaders.

I now submit to you the Power of the Palette…(textures colors and shaders included)

Any Questions?

Great stuff, DKD.

I noticed that the Gouraud shader uses the palette ever since I tweaked with the 4th row of the palettes for 2.0 and noticed that some of the ground targets looked kind of funny. I since move the colors that are not part of the original gradient to the top end of the row to minimize the effect on the graphical anomaly, but I was wondering if it was possible to limit the number of palette slots used in the gradient (i.e. using slots 48-56 instead of slots 48-63).

Can certainly work on a method to reduce the gradient slots. The colors you wish to eliminate are primarily for terrain textures so I'm a bit unsure of what you are refering to as "ground targets". Are you refering to ground mobiles or static targets? Are you saying that the code for those objects automatically applies the shader to the polygon colors? Do you recall which objects were effected?

for ground targets, I'm referring to mobile targets such as the M1, the T80, the trucks, as well as some of the aircraft (cargo birds come to mind).

Just go to the custom mission menu and tab through the ground and air targets to see what I mean. When they use a desert pattern, they use the full row 4 for the gradient.

Very impressive DKD, any chance of some screen shots showing this in action?

Yes, just replace the 63 with 56 in the appropriate lines.

In this example of the shaded triangle:
004CBABAC000
0080000500060004 two of the vertices have a colour of BA(186) and the other C0(192).

This can be visualised by stretching the palette into two dimensions and plotting the palette positions of the colours:

Nice. Might give this a look for 2.03 or later.

These are early trials and are designed to find a scheme that is complimentary to the 2.0 terrain. This set includes a combination of Gouraud shading and Flat shading mixed with conventional TAW Textures and weighted toward Gauraud. The addition of the Gauraud component is not well appreciated by the viewer outside of the game environment.

Wow, DKD. Great find, and these enhancements can certainly spruce up the look in TAW 2.0.

If you're interested in conforming to the 2.0 look, you can probably just as easily make them work for legacy TAW. Using the 1200 palette a base, I made major changes to the sky colors (row 9, 2nd half of row 2), water colors( row 8), and the upper half of the sand colors in row 4. Sure, I made differences in the palettes based off the 1200 palette, but the colors were adjusted in something of a linear fashion.

In other words, what you make work for 2.0 is likely to work for 1.0 as well.

Realizing that you are using the greens and blacks to illustrate your changes (rather than use them as final colors), I have some recommendations for color selection:

For Concrete/Buildings, use row 13 (colors 192-207). Row 12 can be used if necessary, since these colors are often directly related to buildings.

For ocean colors (row 8), limit yourself to colors 118-124.

For Tans, limit yourself to row 3 and row 4 only up to color 56. If you wish to use the tans in rows 12/13, have at it!

For Greens, have at it. No restrictions.


One thing also to note: with Glide there are two palettes (east/west) for sunrise and sunset timeframes (0600, 0800, 1800, 2000). In these timeframes the terrain colors or water have not changed. However, the sky colors and the colors in rows 12/13 differ between palettes in order to show sun glare. These colors are brighter on the darker sky palette, showing the sun shining on the direction you are looking if you look away from the sun.

For example, at 1800 you will see a bright orange as you look west, where the sun is setting. In this direction, the buildings will appear "normal" because you are looking at the shadow side of them. If you look east at 1800, you will see a darker sky, but the buildings will have an orange hue because you're looking at the side of the building receiving the setting sun.

I mention this because you will want to test your settings in glide and make sure the buildings look OK from both directions.

The behavior of the "colr" type seems similar if not identical to the "gour" type. That seems redundant and illogical. The switch statements for the different surface types are: txtr, colr, gour and fade. The code uses a jump table to direct the 4 switch statements:

align 10h
; jump table for switch statement


AUTO:00574F60 off_574F60......dd offset loc_575002
AUTO:00574F60......................dd offset loc_5750A3
AUTO:00574F60......................dd offset loc_5750A3
AUTO:00574F60......................dd offset loc_5750E8
AUTO:00574F70


If I am interpreting this correctly, It appears that 2 of the types jump to the same subroutine. Even so there could be some distinguishing differences.

Could someone take a look at the code in the executable and see what you come up with?

Thanks

Okay, so lets GO ARMY!

(Army green that is)















The shading for light affects is correct but better appreciated in game. These are Gouraud shaded with paletted textures. Kept it very basic, as you requested

Feedback?

Red Hot, perhaps?









Or... some new models with new colors/shading. Below you can see the new contrasted with the old.

Not sure I agree with this. The .3 format seems to be very flexible....but a lot of things need to be considered when modifying the files so that they remain 'consistent'.

From the first picture in the last post, it looks like textures have been replaced with shaded surfaces (I know that hanger well ), but in this day and age, isn't the idea to replace shaded surfaces with textures?

I haven't kept up with this, so I'm probably missing something though.

By strict definition perhaps you are correct and certainly it is not impossible to modify the .3 files, however, the process of maintaining that consistency is slow and tedious, effecting only one file at a time. For a team of individuals working together, no problem, but that is not the case here with TAW.



Actually, each of the pictures in this thread have been a combination of models using textured surfaces and shaded surfaces



I don't know about you, but I suspect one of the main reasons I have spent years working with a program that is now more than a decade old is because I have little desire to keep up with modernity for the sake of simply following the trends. Besides, I'm an optimist not an idealist

Seriously though, I have been working on new building surface textures and have provided one of the pics (below) which is appropriate for our current fall weather here in the midwest. The problems are: 1. simply substituting with 8-bit textures is complicated by the fact that a.) they are difficult to find and b.) not much is to be gained by their substitution IMHO. 2. Using the conversion process you coached Polak through on the terrain to now upgrade the surface textures to a higher color depth is also an option, however, many of the basic 3D objects for buildings in TAW are unusually non-conventional, to re-texture these with upgraded textures using what Polak seemed to suggest was a difficult and time consuming process, would be an investment. The end result would perhaps be like what you should expect to get when you put lipstick on a pig

What we need is new 3d models.

Some good points there, DKD.

I really do need to get back on the case...

Just to let you guys know that I'm paying attention and haven't been ignoring the thread.

DKD, I think your discoveries are fantastic. 3D modelling and reading hex-code just isn't my strong suit. I'll let you guys with the big brains attack this issue head on!

Since the topic of textures is appropriate, I thought I would include a few pictures of the AGP textured TAW sky. Mind you, this project was abandoned but if there is renewed interest...

Use my colors, and you could make some absolutely amazing sunrises and sunsets.

DKD, Interesting stuff.

HomeFries, I might have asked you this before, but do you have any experience with with the scripting language Python?

No Python experience, Mike, but I am a quick study.

Good, I was almost hoping you'd say that because if this is of any interest, you may want to join in.

When I've written any utility to help decipher TAW, or do any general computing task, I've lazily just used my 13 year old version of VB5. This is a computing dead end though, and I'd like to move on to something else.
I've picked Python since I really don't like the bloat of the modern .NET Microsoft stuff and I like the idea of cross platform open source software, and the active Python community is huge. Being able to put Python experience on a CV doesn't hurt either, which is why this has come up right now.

Why am I saying this here?
Well, since I will attempt any new TAW tasks in Python and I haven't a clue what I'm doing (although I've got a big book), it may be some time before anything useful appears. I have seen what Python can do though, and I predict that if I can just get over the initial learning hump, productivity should increase dramatically compared to using VB. The idea is that having something interesting like TAW to work on will accelerate this learning process.

Anyway, I'll try and write something TAW related in Python over the weekend in order to show its potential.....

DKD, apologies for hijacking your thread.

Not a problem.




Can't wait to see what you come up with.



PS: I forgot to mention that the New Parser of yours is magnificent

ditto!

Please post anything you find on the TAW Wiki and I'll try to learn from that.

One more thing: VB still has a place with development. I did all my TAW 2.0 utilities using VB6. I'd be happy to send you the source code.

VB is perfectly adequate as you've proved......but I'm trying to move away from it for various reasons. There's no problem mixing modules from different languages though.