Jump to content
COMBATSIM Forum
Krycztij

TAW terrain format

Recommended Posts

Thank you :)

A thought on the last 2 screenshots you posted. Both of those models, if I understand your concern correctly, call associated .3 files. The f22usa1.3 uses the f22_xx.3 series models for control surfaces. The port rudder, for example, is F22_31.3. The Dam breach uses a wake/splash file to give a unique 3D image, I believe it's one of the ian.3 files. It could possibly be a problem with the communication of the transformations between the base file and its subordinates.

Nono, these were problems with the transformation in the 0049 opcode. They're already solved in the second Beta.

Multiple .3 files in one model are not yet implemented; this will be a challenge of .SSD files, I guess.

Edit: Yet another another problem: There seem to appear complex polygons:

complexy.png

I have not yet checked the .3 bytecode, but if this is true, I have to think about new triangulatjon rules :( This is so mean of DiD!

Share this post


Link to post
Share on other sites

Multiple .3 files in one model are not yet implemented; this will be a challenge of .SSD files, I guess.

I would say yes, that has proven to be a bigger challenge.

...these were problems with the transformation in the 0049 opcode...

The issue of 0049 and your statement of the zeroes being legacy for scaling or mirroring or something, has suggested a reference to a problem no one has been able to solve for years. It just possibly relates to the 0049 zeroes and involves the red****.ini files. All of those files contain a section designated [transtxtr]. It has been suggested that the designation has to do with the transformation of textures and yet, the actual function has been elusive. It has been thought that perhaps it could relate to a transformation of certain terrain or cloud textures and yet I'm not sure what the correct translation values would be for something like, say, a dynamic water movement effect, etc..

The normal game .ini files have the following:

[transtxtr]

A=(0,0)

B=(95,0)

C=(95,95)

D=(0,95)


E=(96,0)

F=(191,0)

G=(191,95)

H=(96,95)


I=(0,96)

J=(95,96)

K=(95,191)

L=(0,191)


M=(96,96)

N=(191,96)

O=(191,191)

P=(96,191)
I discovered an unused 'hardware.ini' file which contained:
[transtxtr]

A=(0,0)

B=(47,0)

C=(95,0)

D=(143,0)

E=(191,0)

F=(0,47)

G=(47,47)

H=(95,47)

I=(143,47)

J=(191,47)

K=(0,95)

L=(47,95)

M=(95,95)

N=(143,95)

O=(191,95)

P=(0,143)

Q=(47,143)

R=(95,143)

S=(143,143)

T=(191,143)

U=(0,191)

V=(47,191)

W=(95,191)

X=(143,191)

Y=(191,191)

Incorporating the expanded values in the red****.ini files did not produce any appreciable change. As I said, I wondered if this could be related to the 0049 opcode. Any thoughts would be appreciated.

Share this post


Link to post
Share on other sites

I have not yet checked the .3 bytecode, but if this is true, I have to think about new triangulation rules :( This is so mean of DiD!

Okay, perhaps they were a very skilled but sadistic lot ;) I'll start looking to see if I can identify complex forms (intersecting, holes, etc.), is there an easy identifier?

Share this post


Link to post
Share on other sites

Any thoughts would be appreciated.

From a first glance, I don't think it has to do with 0049. There is no indication that TAW's texture coordinates are somehow linked to world coordinates (like, for example, in the Quake engine) and the set of six unused values for scaling XYZ and translation XYZ or for setting up a 3x3 rotation matrix sounds just more solid to me. I have, however, nearly no experencie with INI files and with what TAW uses them for :blink:

I'll start looking to see if I can identify complex forms (intersecting, holes, etc.), is there an easy identifier?

Oh that would be great :) Turns out I used the wrong terminus -- what I meant was actually that this seems like a concave polygon to me but I'm only prepared for convex ones.

To identify such a polygon, I would go through all of its vertices and compute the cross product of the two edges between [the n-1'th and n'th vertex] x [the n'th and n+1'th vertex]. In a convex polygon, all resulting vectors should point into nearly the same direction (their dot product should be positive). If at least two resulting vectors point into different directions (their dot product is zero or negative), the polygon is concave and we need to look into triangulation algorithms for such cases. You'd have to consider that the n+1'th vertex of the last vertex would be the first vertex again.

If that's too much for you, I can also implement it in my viewer, but we'd have to load every model and look at it from every angle then ...

Share this post


Link to post
Share on other sites

Again, 007e is a bit of a mystery, but as it has the same format as 001b, maybe we can do the brightly coloured polygon trick, then investigate later.

Investigating further, 003e also has the same format.

007e000000be001800190017001a

001b00000026000e00010012000f

003e000000b00000000100020003

Maybe I have mistaken something in my code, but I could not spot any difference anywhere, not even with bright polygons.

These have the same form as 0003, so could be drawn that way for now...

00a200040025004e004f0028

003800b000bf00be00bd00bc

Well, these DO make a difference with all tires -- the tires have black quads now (see apache.3, also appears in f22clegy.3):

apachem.png

(The nationality mark is very small, too. But I don't know if this is our fault; the apache model is by far less professional than the other models and has many other glitches.)

I'll have to look into it tomorrow (also compare it to in-game screenshots); it could have something to do with alpha transparency or AGP.

Share this post


Link to post
Share on other sites

If that's too much for you, I can also implement it in my viewer, but we'd have to load every model and look at it from every angle then ...

On the 0049 question, thanks.

Delaunay, Ear Clipping...oh my!

If you think viewer implementation is reasonably efficient, that would be reasonable. If we get to a place where implementation of new textures was being discussed, known Normals would be critical, especially as it relates to layered texture constructs. I can certainly wade in on the problem if you think that is useful :)

Share this post


Link to post
Share on other sites

If you think viewer implementation is reasonably efficient, that would be reasonable. If we get to a place where implementation of new textures was being discussed, known Normals would be critical, especially as it relates to layered texture constructs. I can certainly wade in on the problem if you think that is useful :)

Actually, the whole thing seems too costly compared to the gain for me now: F-16 UB is the only model where I suspect a concave polygon, which makes it a 1:100,000 case. Let's postpone it, there is still so much more to discover :)

Look at 00A2 (0007 flag enabled)

0007aq.png

(0007 flag disabled)

no0007.png

These could be shadow casters. In this case, I think that the wird black squares at the tires are for shadows, too. At least they have no effect in the actual game.

What shadow algorithm does TAW use? Stencil shadows?

Furthermore, 0083 and 0084 don't seem to have much to do with transparency. The issue on crain.3 is, simply put, the texture coordinates are wrong. The nontransparent parts just don't belong there.

Share this post


Link to post
Share on other sites

Been away, so will try and catch up....

I agree that 00a2 seems shadow related, but don't know how.

Shadows are handled in different ways, and the methods probably evolved over the lifetime of the engine. For buildings, the shadow is often a 0088 transparency selected by some time parameter.

We don't need to worry about that 'concave' polygon, but a question about the wireframe view. I guess the wireframe we see is after you have split TAW's quads into triangles?

What is totally awesome is the parachute deploynent sequence on things like car.3 and crate.3. I didn't realise it was so detailed! How have you interpreted the 005f and 0060 opcodes??

The dam breaking sequence on dam1 and dam2 is also amazing! Far more detailed than we see in the game. :)

Share this post


Link to post
Share on other sites

Welcome back :)

We don't need to worry about that 'concave' polygon, but a question about the wireframe view. I guess the wireframe we see is after you have split TAW's quads into triangles?

Correct. I was always planning to render the wireframe with original data, but it never had any priority and it could have unforeseen consequences because I'd have to render the wireframe as a line list and the API treats those different than wireframe'd triangles.

What is totally awesome is the parachute deploynent sequence on things like car.3 and crate.3. I didn't realise it was so detailed!

Yes, I didn't expect TAW to the cables through hundreds of points either. This is actually a huge performance problem -- and a logical, too, because I'm blending lights additively and this looks completely different than one would expect cables to look like.

How have you interpreted the 005f and 0060 opcodes??

Not (yet) at all. So, how should I? :)

Share this post


Link to post
Share on other sites

....because I'm blending lights additively and this looks completely different than one would expect cables to look like.

I've just been looking at crate.3 and see what you mean. It would appear that the 0039 opcode is a general command for a 'featured' line, which with the selection of a bright palette colour can also give a lighting effect.

Not (yet) at all. So, how should I? :)

Again looking at crate.3, the 0060,0059,005c opcodes are used early on in the parachute deployment sequence when 'Parameter 0004 < 4'.

DrKevDog has reported earlier that the 005c opcode appears to give a translucent spherical object in pomornk.3 leading to the hypothesis that:

005c00d300230001

means draw a sphere, with palette colour 00d3 at vertex 0023 with radius 0001

If this is in any way true, then 005f would give more than one sphere, and 0060 spheres with an extra attribute:

005f0002

00d200220002

00d200230001


00600006

000200d2001c0005

000200d2001d0004

000100d2001e0004

000100d2001f0003

000000d200200003

000000d200210002

...a long shot, I know. :)

Share this post


Link to post
Share on other sites

DrKevDog has reported earlier that the 005c opcode appears to give a translucent spherical object in pomornk.3 leading to the hypothesis that:

005c00d300230001

means draw a sphere, with palette colour 00d3 at vertex 0023 with radius 0001

If this is in any way true, then 005f would give more than one sphere, and 0060 spheres with an extra attribute:

DrKevDog seems to be right:

cmp.png

The sphere is missing. I'll see how I can implement these instructions.

Share this post


Link to post
Share on other sites

...and pomornk.3 might give us another clue.

In the game view, the propellers look like they are made out of a mesh while in the viewer they appear solid. The props are moved with Parameter 0003, and associated with that are some 001a lines:

001a000000c30168016e0174

Share this post


Link to post
Share on other sites

...I did a mission to Aswan to spot the 001a effect at the ends of the dam in Aswan_j and a chequerboard effect can be seen, but only in software rendered mode. This mode is used to draw the vehicles in the custom Combat preview screen as well.

Share this post


Link to post
Share on other sites

Well I think it is just there to emulate transparency then. The polygon is supposed to be only 50 % opaque (which makes sense for the propellers, because they move so fast, as well as for the polygons at the ends of the dam, because they simulate dirt and dust) and the software renderer uses a chequerboard pattern (one pixel fully opaque, one fully transparent, one fully opaque, ...) because "real" transparency would be too difficult to compute in palette-oriented software mode. I've seen this a few times in old games, and some recent titles use it for order-independent transparency (with subsamples instead of whole pixels, though).

To clarify this question, we need screenshots of how it's supposed to look like, i.e. in "real" glide mode. Anyone runs TAW without a glide wrapper? :)

Share this post


Link to post
Share on other sites

To clarify this question, we need screenshots of how it's supposed to look like, i.e. in "real" glide mode. Anyone runs TAW without a glide wrapper? :)

Mikew, glad you're back.

Krycztij, That's correct, I could only get the 005c sphere in the Glide API using the Glide specific f22.dat (executable) on a Voodoo card. I'll see if I can't dig it out and re-install it.

Edit: f22.dat Clarification

Share this post


Link to post
Share on other sites

Thank you for your efford :)

The software renderer will draw the sphere and will draw the propellers semi-transparent.

My glide wrapper (dgVoodoo) does not draw the sphere and the propellers are drawn fully opaque.

I'm really curious on how it's supposed to look like.

Share this post


Link to post
Share on other sites

I guess the sphere is supposed to be a radome but they haven't got a good method for drawing this in Glide. Using psVoodoo, it is rendered as a diffuse blob.

I also had a look at the props using psVoodoo and after taking the screenshot, some of the prop blades were dark opaque polygons, and some were light coloured. Strange.

Share this post


Link to post
Share on other sites

I also had a look at the props using psVoodoo and after taking the screenshot, some of the prop blades were dark opaque polygons, and some were light coloured. Strange.

I've seen a similar effect on many other polygons. The wrappers try to apply some kind of shading; at least the colors of vertices at the edges of polygons are significandly different to those in the software renderer and in my viewer. I don't think this is desired.

Share this post


Link to post
Share on other sites

Maybe, but I would think that this shading is coming from a process in TAW that we don't understand yet.

Regarding wrappers, while dgVoodoo is the wrapper with the most features, I use psVoodoo for this investigative stuff since it's open source and thus the Glide commands can be intercepted and the resulting DX9 shaders examined.

Share this post


Link to post
Share on other sites

Maybe, but I would think that this shading is coming from a process in TAW that we don't understand yet.

Regarding wrappers, while dgVoodoo is the wrapper with the most features, I use psVoodoo for this investigative stuff since it's open source and thus the Glide commands can be intercepted and the resulting DX9 shaders examined.

When I took a look at the shading processes in TAW, it lists three: "Flat", "Gour" and "Colr". These can be implemented for buildings by direct modifications of the red****.ini file. We suspect this "Colr" may be some additional form of shading.

Share this post


Link to post
Share on other sites

...and there's the 'coltab' files, which may mean 'colour table'. Haven't started with those yet.

Here's a couple of pictures flying over the ship with Glide. Note that the sphere doesn't appear at all with D3D.

pom1.jpg

pom2.jpg

Not big issues, but always nice to understand what's going on.....

Share this post


Link to post
Share on other sites

Not big issues, but always nice to understand what's going on.....

The magnitude of this issue remains to be determined, IMHO. Considering the fact that this issue is related to the different treatments of TAW toward Glide versus D3D, I would wonder if the acquisition of understanding would apply toward a solution for the moving map problem which also only exists in D3D :popcornsmilie:

Share this post


Link to post
Share on other sites

I still have that code for that proxy d3d dll we were looking at some months ago, so with some time and effort could probably track down that moving map problem...but is there any particular reason to persevere with d3d?

As I understand it, the only big advantage with d3d is the 1024x768 patch. With dgVoodoo being able to upscale to any resolution, this doesn't seem relevant anymore.

I realise that the wrapper affects performance, but that's going to become less of an issue over time.

Share this post


Link to post
Share on other sites

I still have that code for that proxy d3d dll we were looking at some months ago, so with some time and effort could probably track down that moving map problem...but is there any particular reason to persevere with d3d?

Perhaps I've missed something, has there been real success in implementing the 24/32 bit (AGP) textures outside of the D3D API?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...