What could the TMAP-chunk be?

[Kaleun_Endrass]

Hi,

I´ve found out the structure of the TMAP-chunk but I could´nt figure out, what it is for.

The structure is as follows (ntris is the number of Triangles the mesh is build of):

4x char............."TMAP"
1x byte.............number of maps
....here follow the maps, each consisting of:
1x byte.................maybe a group number if you consider TMAP as a SmoothGroup
ntris * 6 * bytes.....I believe it´s actually "ntris * 3 * WORD"

So, a single TMapDatChunk (I named it that way) encapsulates 3 unsigned shortint. I named them T1, T2 and T3 because they have something todo with the triangles of the mesh. As I looked at the values, I could see that it isn´t an index to a specific triangle because the values can get higher than ntris.

Has anyone an idea what TMAP could be?

[FIREWALL]

Hi,

I´ve found out the structure of the TMAP-chunk but I could´nt figure out, what it is for.

The structure is as follows (ntris is the number of Triangles the mesh is build of):

4x char............."TMAP"
1x byte.............number of maps
....here follow the maps, each consisting of:
1x byte.................maybe a group number if you consider TMAP as a SmoothGroup
ntris * 6 * bytes.....I believe it´s actually "ntris * 3 * WORD"

So, a single TMapDatChunk (I named it that way) encapsulates 3 unsigned shortint. I named them T1, T2 and T3 because they have something todo with the triangles of the mesh. As I looked at the values, I could see that it isn´t an index to a specific triangle because the values can get higher than ntris.

Has anyone an idea what TMAP could be?

Hi K E First off Welcome Aboard.

I wish I knew what your even talking about,:-? Sorry I'm no help but,
there's alot of great people here who can answer your questions. :yep:
So hang in there and the'll be here. Good luck and sink alot of ships :up:

[Jimbuna]

Sorry mate :nope:

Welcome aboard kaleun :arrgh!:

[Kaleun_Endrass]

Thanks for the welcome...

Ok, I need to give additional information for those who doesn´t know about the TMAP-chunk but could find an explanation what it could be.

The Silent Hunter III DAT-, ZON-, VAL-, SIM-, DSD-Files consists of chunks. There are several types. One of them is Type 1. That type encapsulates a 3d model. A "normal" 3d model has Vertices, Triangles and Texture Coordinates. Some type 1 chunks have the TMAP structure (as described in my earlier post) right after the VertexArray, TriangleArray and TxCoordArray.
My first guess was, that these data stands for smoothing the mesh, but that wouldn´t make much sense because one TMAP contains one 6-byte data structure for each triangle and a SmoothingGroups contains only information of those vertices/triangles that build a smoothed surface. If you take a look at the file description for the OBJ fileformat then Smoothing could be an explanation for the TMAP but still, why are information stored for each and every triangle - that doesn´t make sense?!
My second guess was, that the TMAP has something todo with multi-texturing but that doesn´t make sense either because you can find 3d models that uses three different materials but have only one TMAP. But if I´m wrong with this, what are those unsigned shortints for?

Well, I´ll keep looking... maybe someone of you have an idea.

[ref]

Thanks for the welcome...

Ok, I need to give additional information for those who doesn´t know about the TMAP-chunk but could find an explanation what it could be.

The Silent Hunter III DAT-, ZON-, VAL-, SIM-, DSD-Files consists of chunks. There are several types. One of them is Type 1. That type encapsulates a 3d model. A "normal" 3d model has Vertices, Triangles and Texture Coordinates. Some type 1 chunks have the TMAP structure (as described in my earlier post) right after the VertexArray, TriangleArray and TxCoordArray.
My first guess was, that these data stands for smoothing the mesh, but that wouldn´t make much sense because one TMAP contains one 6-byte data structure for each triangle and a SmoothingGroups contains only information of those vertices/triangles that build a smoothed surface. If you take a look at the file description for the OBJ fileformat then Smoothing could be an explanation for the TMAP but still, why are information stored for each and every triangle - that doesn´t make sense?!
My second guess was, that the TMAP has something todo with multi-texturing but that doesn´t make sense either because you can find 3d models that uses three different materials but have only one TMAP. But if I´m wrong with this, what are those unsigned shortints for?

Well, I´ll keep looking... maybe someone of you have an idea.

That's one of the few misteries remaining on dat file structures (along with the animation format), as far as I know nobody has been able to figure it out, in any case don't use obj file format as a reference, it's used by us because it's the easiest one to produce, if you look at the SH4 thread pictures you'll see that the devs use 3ds max for designing, so probably it's a 3ds feature.

Ref

[Kaleun_Endrass]

Hi ref,

I know that the devs are using 3dsmax and as I first started working on the dat files in March 2005, I found alot of similarities between the 3d models in the dat files and the 3ds fileformat.
But none of the chunks of a 3ds file have a structure size as the TMAP has.
Based on the name I would guess it´s an additional texture map (for each triangle one RGB value - but I never heard of a game using 48bit textures)

There is really just one thing left I think the TMAP is for and that´s SmoothingGroups but I can´t figure out how the 3 unsigned shortints or 6 bytes should built such a group and futhermore why each triangle of the mesh needs to be in this group...

Did anyone tried to delete the TMAP section of an unit and compared the both visual appearances in the game? Maybe that´s one hint... (I´m asking, because I can´t test any longer - I´m nearly 1000 miles away from my copy :cry: )

[ref]

I haven't had many time myself for research in the last months, too busy with GWX, as soon as we release the january (now february) patch I'll resume the work on some tools and research of some unknown stuff in sh3 that has potential for improvement/additions.

Ref

[DivingDuck]

Moin,
...
Did anyone tried to delete the TMAP section of an unit and compared the both visual appearances in the game? Maybe that´s one hint... (I´m asking, because I can´t test any longer - I´m nearly 1000 miles away from my copy :cry: ) I did, by mistake. I´m doing the coding for Urfisch´s open hatch project. After several days of investigation I´ve found out that the self illumination seems to be controlled by this TMAP section. The problem lies with Pack3D. When importing an object this section get´s lost. Even the unchanged original command roon can´t be re-imported without loosing it. I hope I´ll get the point how to (re-)attach this section to newly imported objects soon.

As you can see in the screenie below the newly added compartment is kind of foggy.

http://img223.imageshack.us/img223/6/cr001ei8.jpg

Don´t get confused about the green ambient light. I´ve used this color for some testing purposes. And yes, the compartment is lacking of several polys. First coding, then eye candy.

Regards,
DD

[ref]

Moin,
I did, by mistake. I´m doing the coding for Urfisch´s open hatch project. After several days of investigation I´ve found out that the self illumination seems to be controlled by this TMAP section. The problem lies with Pack3D. When importing an object this section get´s lost. Even the unchanged original command roon can´t be re-imported without loosing it. I hope I´ll get the point how to (re-)attach this section to newly imported objects soon.

Maybe prelighting applied to each face?

Ref

[DivingDuck]

Moin,

Maybe prelighting applied to each face?
Ref Sorry ref, don´t know what prelighting is.
I´ve altered the illumination data for the corresponding *.tga file. Seems that there is an effect. But I think the devs wouldn´t have made it that way for no reason.

Regards,
DD

[ref]

Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref

[DivingDuck]

Hi,
Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref If so, the TMAP section is not necessary and may be skipped. That makes me hope I´ll reach the goal another way, just by overriding this chunk.

Regards,
DD

[Anvart]

Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref
What do you speak about?
Interior have Light source (Ambient Light).

[Madox58]

I'll admit, most of the files I've been into do not have the TMAP
so this is just a thought.

I read a paper quite awhile back that explained different approaches
to the 3d matrix problems as applied to game engines.

I remember what was reffered to as the "3 Magic Vertices"
as an approach to solveing certian problems while rendering
a 3d object to screen, depending on what approach the game
engine uses to render.

[ref]

Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref
What do you speak about?
Interior have Light source (Ambient Light).


Yes, but if they use prelighted scenes they can simulate shadows/bright spots to enhance the room without increasing the number of lights in the scene.

Ref

[Anvart]

Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref
What do you speak about?
Interior have Light source (Ambient Light).


Yes, but if they use prelighted scenes they can simulate shadows/bright spots to enhance the room without increasing the number of lights in the scene.

Ref
You think, that it is in SH3?
:o

[Anvart]

Most high end 3d programs have an option to prelight a scene, mostly used in games, you design the scene, add the lights and then "prelight" the scene, process which applies the light on the scene to the objects, generally on a vertex base, making them lighter or darker accordingly so when the game engine loads the object it takes into account the light you apply on your scene, and improving the light rendering quality without the need to render it in real time.

Ref
What do you speak about?
Interior have Light source (Ambient Light).


Yes, but if they use prelighted scenes they can simulate shadows/bright spots to enhance the room without increasing the number of lights in the scene.

Ref
You think, that it is in SH3?
:o

Hi, Ref.
May be you speak about Selfillumination maps?
In NSS_Uboat7_CR.dat they are LM01.tga, LM02.tga, LM03.tga, LM04.tga and others.
These maps simulate the shined and shadow spots and are in Type13 blocks.

[Anvart]

Bump. Ref?

[Kaleun_Endrass]

Hi,

I looked again at the TMAP chunk and I found out, that the 3 unsigned shortints are indices for the elements of the TxCoordArray (as I mentioned in an earlier post). That means, each vertex that is an element of the trianlge at TriangleArray[i] gets an additional texture coordinate. In pseudo-code it would look like this:

TriangleArray[i].V1.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T1] );
TriangleArray[i].V2.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T2] );
TriangleArray[i].V3.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T3] );

So, I´m currently reconsidering the possibility that the TMAP stands for SmoothingGroups. I´m not an game engine developer but I guess that smoothing like 3dsmax renderings during runtime would be extremly slow and an easy way could be to display the same texture at the mesh several times but with some offsets each time.
What do you guys think?

[Anvart]

Hi,

I looked again at the TMAP chunk and I found out, that the 3 unsigned shortints are indices for the elements of the TxCoordArray (as I mentioned in an earlier post). That means, each vertex that is an element of the trianlge at TriangleArray[i] gets an additional texture coordinate. In pseudo-code it would look like this:

TriangleArray[i].V1.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T1] );
TriangleArray[i].V2.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T2] );
TriangleArray[i].V3.AddTxCoord( TxCoordArray[TMapDatChunkList[i].T3] );

So, Iґm currently reconsidering the possibility that the TMAP stands for SmoothingGroups. Iґm not an game engine developer but I guess that smoothing like 3dsmax renderings during runtime would be extremly slow and an easy way could be to display the same texture at the mesh several times but with some offsets each time.
What do you guys think?
I think, that smoothing of models is AI hard code.

[ref]

I think, that smoothing of models is AI hard code.

Maybe it's just one more thing to add in the unfinished features list.
They put it in the dats waiting for the programers to implement it but they didn't finish it in time, personally I've seen no difference with or without TMAP.

Ref

[Anvart]

I think, that smoothing of models is AI hard code.

Maybe it's just one more thing to add in the unfinished features list.
They put it in the dats waiting for the programers to implement it but they didn't finish it in time, personally I've seen no difference with or without TMAP.

Ref
I too.

[DivingDuck]

Moin,

as for the smoothing I remember having some problems in the past. If my remembrance is right an object appears "un"-smoothed ingame if one applies smoothing to an object and exports these smoothing groups when creating/exporting to wavefront *.obj file.

Cutting off the TMAP sections has an effect. The textures seem darker then. But it´s not that obvious since most of the interior is brought to the scene by separate objects that have their own TMAP. Take a closer look behind the handwheels.

So, I´m currently reconsidering the possibility that the TMAP stands for SmoothingGroups.Don´t think so. I suppose that it contains the value for light´s intensity for each triangle.

Regards,
DD

[skwasjer]

Ok, let me share my findings. While all of you are partially right, my -be it premature- conclusion is the following: I think the additional maps do indeed refer to the texture index array.

I've analyzed the chunk, and found that most models seem to not use all of the texture coordinates (Vector2). So, basically, we have an texture index array that does not map into each and every texture coordinate array.
Now, if you think about it, this doesn't make sense. Why would there be more texture coordinates, then are actually used/mapped to each face.

This triggered me to search further. Enter the TMAP. Many of the indexes in the TMAP array (one or more maps possible), fill those holes! They refer to many of the remaining (yet unmapped) - but not all - texture coordinates. Great, so what now?

Well, it seems like the TMAP provides additional material info. For a ship with a wooden deck, the deck will cast/reflect light differently then the hull. Makes sense? But how does SH do this...

Many of the models have more than 1 texture. Ie.: take the Yamato: it has NBB_Yamato_T01.dds as the main texture. The NBB_Yamato_N01.dds is a normal map, and is used for bumpmapping. It is similar in layout to the T01 texture and could be directly mapped using the same texture coordinates. However, when we look at the NBB_Yamato_O01.dds texture, you can see it is a crazy image where the alpha channel is completely different from the RGB channels. It's very simple though, the alpha channel looks to me like the height map, and is also used with bumpmapping. The RGB channels however looks like a specular or diffuse map or maybe even another type of map they introduced to make a big surface look more unique by blending it. But since the layout of this texture is entirely different, we need new texture coordinates! Eureka? You tell me...

In case of interiors the same idea applies, although the TMAP appears to hold even more data. I haven't investigated this fully, but from what I see, interiors also use lightmaps, and maybe also both a specular and diffuse map. I will check this out later...

Anyway, I will try to use this data in my renderer (see http://forums.ubi.com/eve/forums/a/tpc/f/6421019045/m/9841082745 and http://www.subsim.com/radioroom/showthread.php?t=110392) and see what the effects are (may take a few days/weeks though). I will try to use the TMAP indexes and only texture the ship with the RGB channel (without the alpha) of the xxx_O01.dds texture to see if my findings work.

If you have other ideas, think I'm absolutely wrong or whatever is on your mind, please keep 'm coming! :up:

[skwasjer]

Oh and one other thing. Did you guys know about the NORM section that some models have trailing the TMAP? Looks like normals for each vertex, which will aid in smoothing out lighting/shadows...

[skwasjer]

Ok, well, so much for days/weeks:

The Yamato with the NBB_Yamato_T01.dds texture mapped using coordinates from the standard index array:
http://www.bodeman.nl/sh4/NBB_Yamato_T01.dds.jpg

The Yamato again, this time textured with the RGB channel of NBB_Yamato_O01.dds. Note that I ONLY used the last TMAP texture index coordinates here, and completely ignored the standard texture index coordinate array.
http://www.bodeman.nl/sh4/NBB_Yamato_O01.dds.jpg

See all the rust and deep shadows? TMAP solved... Well partially, now for interiors... Will look asap :)

[DivingDuck]

Hey Skwasjer,

that´s a pretty glamorous start. Hope there will be some more information I can use to create my own TMAP then. Good luck with your project. And in case you need someone to test it, I´m at your service.

Regards,
DD

[skwasjer]

Hi, All.
I already wrote my opinion. Repeat once again:

Description.
- TMAP – Label 4 bytes
- txtrType – 2 bytes unsigned short Textural Map Type (additional texture in Type13 chunk, for example, LightMap ...LM.tga)
- triFacesNum * (3 * Vt (unsigned short 2 bytes)) Textural Vertexes sequence for each face.



No, this is wrong. The 2 bytes after the header mean something else. Actually, Kaleun_Endrass already posted the correct structure layout in the first post of this thread. He just didn't completely interpret the data right.

TMAP - 4 bytes
mapCount - 1 byte

following this is a 'mapCount' number of structures of:

type - 1 byte, probably type of map. Most common value = 2 = SelfIllum map. Also found values of 3 and 4.
ushort[trisCount * 3] - 6 bytes * trisCount

If you use your structure, you would miss any additional texture coordinate maps. Most models only have one map so you wouldn't have a problem, but hey, we're after the correct data structure here...
It's good that you already had a close understanding of the layout of this data section, but from all the info I have gathered, everybody was a bit wrong along the line or hadn't been able to fully prove what the data was there for. Alot of guesses were in the right direction, which was great help for me to be able to prove it.

I will determine what the other types are for asap, specifically for interiors.

[Anvart]

No, this is wrong. The 2 bytes after the header mean something else. Actually, Kaleun_Endrass already posted the correct structure layout in the first post of this thread. He just didn't completely interpret the data right.

TMAP - 4 bytes
mapCount - 1 byte

following this is a 'mapCount' number of structures of:

type - 1 byte, probably type of map. Most common value = 2 = SelfIllum map. Also found values of 3 and 4.
ushort[trisCount * 3] - 6 bytes * trisCount

If you use your structure, you would miss any additional texture coordinate maps. Most models only have one map so you wouldn't have a problem, but hey, we're after the correct data structure here...
It's good that you already had a close understanding of the layout of this data section, but from all the info I have gathered, everybody was a bit wrong along the line or hadn't been able to fully prove what the data was there for. Alot of guesses were in the right direction, which was great help for me to be able to prove it.

I will determine what the other types are for asap, specifically for interiors.
:rotfl: :damn:

[skwasjer]

Yes? I don't understand...

[DivingDuck]

Moin Skwasjer,

I could need your advice. Please PM me!

Regards,
DD

[DivingDuck]

Moin,

I´ve compared a 3d object´s triangles data with TMAP data. Here´s my problem:

http://img514.imageshack.us/img514/4799/hexeditingtmap002vr0.jpg
Any suggestions?

Regards,
DD

[skwasjer]

See my e-mail to you yesterday. They are 3 ushorts, and represent indexes. These indexes refer to the array of UV's (texture coordinates). The TMAP is exactly the same, also 3 ushorts (per face) with indexes refering to the array of UV's.

[edit] The reason you encounter values that are 'higher' than the number of vertices is because each model (99% of them anyway) has more texture coordinates than vertices. Check the UV array for it's length and values, then check the TMAP section and see that they share indexes, but can also have unique ones (which may result in index values exceeding the vertex count).

[urfisch]

great! any conclusion on that?