![]() |
Quote:
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 |
Quote:
|
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. Quote:
Regards, DD |
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/t...5/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: |
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...
|
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 :) |
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 |
Quote:
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. |
Quote:
|
Yes? I don't understand...
|
Moin Skwasjer,
I could need your advice. Please PM me! Regards, DD |
Moin,
I´ve compared a 3d object´s triangles data with TMAP data. Here´s my problem: http://img514.imageshack.us/img514/4...tmap002vr0.jpg Any suggestions? Regards, DD |
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). |
great! any conclusion on that?
|
All times are GMT -5. The time now is 12:31 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 1995- 2025 Subsim®
"Subsim" is a registered trademark, all rights reserved.