Bump Mapping Research

[DarthParametric 3,782]

It could be values for normal, binormal, and tangent. You can extract the values via Maxscript. You probably need to do some experiments with some simple shapes and see if you can figure out the order.

 

Edit: If you want to use this simple pyramid mesh as a test - http://dpmods.wheb.org/files/kotor/misc/TEST_PYRAMID_ASCII.mdl - you can try the following values:

 

 

 

Tangent
1.0 0.0 0.0
1.0 0.0 0.0
1.0 0.0 0.0
0.0 1.0 0.0
-1.0 0.0 0.0
1.0 0.0 0.0
0.0 1.0 0.0
-1.0 0.0 0.0
0.0 -1.0 0.0
0.0 -1.0 0.0
1.0 1.77776e-007 0.0
0.0 1.0 0.0
1.0 -1.77776e-007 0.0
-1.0 0.0 0.0
1.0 -1.77776e-007 0.0
0.0 -1.0 0.0 1.0
1.0 1.77776e-007 0.0

Binormal
0.0 -0.447214 -0.894427
0.0 -0.447214 -0.894427
0.0 -0.447214 -0.894427
0.447214 0.0 -0.894427
0.0 0.447214 -0.894427
0.0 1.0 0.0
0.447214 0.0 -0.894427
0.0 0.447214 -0.894427
-0.447214 0.0 -0.894427
-0.447214 0.0 -0.894427
0.0 1.0 0.0
0.447214 0.0 -0.894427
0.0 1.0 0.0
0.0 0.447214 -0.894427
0.0 1.0 0.0
-0.447214 0.0 -0.894427
0.0 1.0 0.0

Normal
0.0 -0.894427 0.447214
0.0 -0.894427 0.447214
0.0 -0.894427 0.447214
0.894427 0.0 0.447214
0.0 0.894427 0.447214
0.0 0.0 -1.0
0.894427 0.0 0.447214
0.0 0.894427 0.447214
-0.894427 0.0 0.447214
-0.894427 0.0 0.447214
0.0 0.0 -1.0
0.894427 0.0 0.447214
0.0 0.0 -1.0
0.0 0.894427 0.447214
0.0 0.0 -1.0
-0.894427 0.0 0.447214
0.0 0.0 -1.0

 

Although I'm not 100% sure they are correct, but assuming you can get it compile and load without something exploding, we can progress to more complex shapes with shared normals across edge breaks/UV boundaries.

[ndix UR 218]

Hey all, first off I just want to say how inspiring and important everything in this thread has been. Big shout out to DarthSapiens and OldTimeRadio for their work on this in the worlds of KotOR and NWN. Also to DarthParametric and Dastardly, whose posts I wish I would have read roughly one day sooner than I did  Also sorry about this seriously massive wall of text.

TLDR I figured out the numbers, I'm working on this actively, still a *couple* kinks causing K2 to crash on certain newly-bump-mapped models, K1 yet to see any success, going to take a bit of further study it seems. Some numbers are still coming out pretty far from vanilla, but how much they are affecting things visually is TBD, I have been recompiling vanillas that originally did and didn't have bumpmapping without seeing any crashing for about a day now (6 models "tested", half originally non-bumpmapped).

The Good
I can tell you what the 9-float vertex Tangent Space is and the algorithm to calculate the 3 vectors per vertex in 95+% of cases. As DarthParametric theorized, they are the 3 components of a Tangent Space, to figure this out I used the info here: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-13-normal-mapping/  Because I used that info, I call the 'binormal' vector a 'bitangent', but either way, let's just call them T, B, and N for Tangent, Bitangent, and Normal (all are 3-space vectors). So, the 9 floats in order are [ Bx By Bz Tx Ty Tz Nx Ny Nz ]. These are vertex vectors, distinct from face vectors, with the distinction being that vertex vectors are 'averaged' with all of their adjacent face vectors.
 
I'm not going to go into details that are covered in the opengl-tutorial article, and mdlops already contains the vertex normal calculations, but I do want to write out the oddities of calculating the vertex BT vectors etc. In many ways it works just like calculating the vertex normals. Here is the abbreviated algorithm:

 

• For each face, calculate a face T vector and face B vector using the geometry and UV vertices for texture0 as described in the tutorial.
• If the r factor is 0 ... you would get a divide by 0 before calculating T and B. Solving some of the vanilla systems algebraically I wound up with a number for r of ~2406.6 (1 / 0.00041552) for these cases. I have no idea where that comes from, what it means, etc.
• Normalize the T and B vectors.
• If either B or T is 0, 0, 0 ... set it to 1, 0, 0 instead. I have no idea why or how this might work.
• Now, perform the test and inversion listed under Handedness in the tutorial; but instead of forcing the system to be right handed, force it to not be right handed. So 'glm::dot(glm::cross(n, t), b ) < 0.0f' becomes 'glm::dot(glm::cross(n, t), b ) > 0.0f'.
• Also, texture mirroring and tangent space normal mapping are not friends. I resolve that here by taking the z component of a normal vector on the texture triangle. If it is positive, invert T & B (as in multiply each one by -1, not swap them).
• Ok, you have face T and B vectors now. Time to calculate vertex T and B vectors.
• For each vertex, decide what face it belongs to, start with that face's T and B vectors as your new vertex T and B.
• For each other face adjacent to the vertex, add that face's T and B to your vertex T and B.
• Normalize the vertex T and B vectors.

 

 

Put it into BTN order, and there's your data. For skinned models like c_malbeast in k2, this produces a high number of nearly exact matches compared with the vanilla numbers. I tried a number of other things that don't seem to be right (although I might try some of them again now that I have it working), such as orthogonalizing, deriving B as TxN, not normalizing everywhere, and of course making the system right handed. It all kind of makes sense in hind-sight but damned if it wasn't tricky to figure out.

 

Fun note: comparing the skinned results to the trimesh results, there seems to be a crease angle test that the vanilla compiler did, but only for non-skin.
 
The Bad
All of the droid models I have attempted this on have at least one mesh that has overlapping texture vertices in a face, which makes the r factor in the tutorial's vector calculations into a divide by zero. I have not yet figured out if/what dummy data to use in this case that will produce models that don't crash the game on load. Luckily this is true of vanilla bump-mapped models such as g0t0. But... there is definitely some kind of crease angle calculation that comes into play in a big way on droid models (sigh ... it's def not smooth group data), meaning that the vanilla normals are coming out different, and the vanilla BT vectors ... makes it tougher to track this down. This is what I am kind of side-tracked with at the moment.
 
Also, all of my testing has been in K2, the one test I attempted in K1 crashed the game on load.
 
The Ugly
The bump-mapping doesn't render (none of it, no vanilla, none of people's experiments etc.) when the game is running in wine on a mac, so I can't see whether it looks right at all.  The only ways I can tell that "it's working" are:

1. the game doesn't crash (anymore) when my model loads
2. the game doesn't give me the error message about invalid bumpmap (anymore)
3. since I know from redrob's g0t0 bump research on LF that low alpha on the main texture is necessary, I have done that on my test textures, and the meshes that have working tangent space numbers turn 'solid' or 'alpha 1.0' while the non tangent space meshes remain (mostly) transparent.
4. if the models don't have their tangent space numbers on a node, the node also loses its bumpyshinytexture, which I *can* see in k2 (but not k1).

 

So yeah, I don't have the software to actually see normal maps working, I can just sort of tell. sort of.
 
Crap. After trying every every other option ... I just realized I might have to try the steam version.
 
ALSO - Color Normal Maps as TGAs in Override
I didn't see it here, which could be a 'me' problem, but I just read this last night on OldTimeRadio's NWN thread (on forums.bioware, not here) and "tested" (see The Ugly above) it today. It seems like we can use custom (8-bit) color normal maps in KotOR! I don't know if people are largely aware of this or not, but the impression I was left with from this thread was that we were stuck with grayscale height maps rather than actual color normal maps. In case you're wondering why that's a big deal and don't want to look it up, color normal maps encode a full 3-dimensional vector at each pixel, whereas grayscale height/bump maps basically just alter the apparent height of a surface. The visual differences can be kind of subtle, definitely, but when done well and in the right gfx engine, a normal map is a much more powerful tool.
 
For anyone that wants to try this extra easily and has (kind of old but hopefully basically the same) photoshop, open a full color normal map of whatever format. Go to Image > Mode > Indexed Color. I like Local (Adaptive) for Palette, 256 color, Forced None, Dither None (when possible ... if it is creating weird banding you will have to dither) for settings. Save it as a TGA, pop it in your override (rename it to an existing bump map texture ... such as twilek_m01b like the one used in this thread), go look at a twilek (or whatever you chose to replace).
 
The thing I have no idea about is whether you need to reverse the blue & red channels (swizzle it) in these for them to work correctly (as they appear when exported by Kotor Tool). I found this technique to do the color switch in photoshop before I realized that none of it was working for me for a lot of reasons: http://i.imgur.com/nNHu7yf.jpg
 
Testing?

 

I am thinking I could post a vanilla-recompiled model or two for people that can see the bumps to test with. Suggestions? Something that's going to show the normal mapping in a potentially good way and is known to compile easily would be ideal.

I have used DarthParametric's Test Pyramid a little bit to calculate on, but I'm too noob (and busy) to attempt to get it in-game. FYI, the values he posted above are definitely for the non accumulated face vectors. Here are the numbers I get from my calculations for it (for anyone else trying to implement the calculations):

 
FACE B,T,N numbers per vertex (INITIAL VALUES)
 

0  (0.0003389, 0.4472136, 0.8944271)   (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, -0.8944272, 0.4472136)
1  (0.0003389, 0.4472136, 0.8944271)   (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, -0.8944272, 0.4472136)
2  (0.0003389, 0.4472136, 0.8944271)   (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, -0.8944272, 0.4472136)
3  (-0.4472136, 0.0003389, 0.8944271)  (0.0000000, -1.0000000, 0.0000000)  (0.8944272, 0.0000000, 0.4472136)
4  (0.0000096, -0.4472136, 0.8944272)  (1.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.8944272, 0.4472136)
5  (0.0000214, -1.0000000, 0.0000000)  (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, 0.0000000, -1.0000000)
6  (-0.4472136, 0.0003389, 0.8944271)  (0.0000000, -1.0000000, 0.0000000)  (0.8944272, 0.0000000, 0.4472136)
7  (0.0000096, -0.4472136, 0.8944272)  (1.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.8944272, 0.4472136)
8  (0.4472136, 0.0000096, 0.8944272)   (0.0000000, 1.0000000, 0.0000000)   (-0.8944272, 0.0000000, 0.4472136)
9  (0.4472136, 0.0000096, 0.8944272)   (0.0000000, 1.0000000, 0.0000000)   (-0.8944272, 0.0000000, 0.4472136)
10 (0.0000214, -1.0000000, 0.0000000)  (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, 0.0000000, -1.0000000)
11 (-0.4472136, 0.0003389, 0.8944271)  (0.0000000, -1.0000000, 0.0000000)  (0.8944272, 0.0000000, 0.4472136)
12 (0.0000214, -1.0000000, 0.0000000)  (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, 0.0000000, -1.0000000)
13 (0.0000096, -0.4472136, 0.8944272)  (1.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.8944272, 0.4472136)
14 (0.0000000, -1.0000000, 0.0000000)  (-1.0000000, -0.0000218, 0.0000000) (0.0000000, 0.0000000, -1.0000000)
15 (0.4472136, 0.0000096, 0.8944272)   (0.0000000, 1.0000000, 0.0000000)   (-0.8944272, 0.0000000, 0.4472136)
16 (-0.0000214, -1.0000000, 0.0000000) (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, 0.0000000, -1.0000000)
 
VERTEX B,T,N numbers per vertex (FINAL VALUES)
 
0  (0.0000974, 0.0000974, 1.0000000)   (0.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.0000000, 1.0000000)
1  (0.1856620, -0.6441207, 0.7420500)  (-0.9486812, 0.3162340, 0.0000000)  (-0.5324074, -0.5324074, -0.6580917)
2  (-0.1853896, -0.6440765, 0.7421564) (-0.9486812, -0.3162340, 0.0000000) (0.5324074, -0.5324074, -0.6580917)
3  (-0.1459682, -0.7986262, 0.5838574) (-0.7070991, -0.7071145, 0.0000000) (0.5324074, 0.5324074, -0.6580917)
4  (0.1459481, -0.7986660, 0.5838080)  (-0.7070991, 0.7071145, 0.0000000)  (-0.5324074, 0.5324074, -0.6580917)
5  (0.0000000, -1.0000000, 0.0000000)  (-1.0000000, 0.0000000, 0.0000000)  (0.0000000, 0.0000000, -1.0000000)
6  (0.0000974, 0.0000974, 1.0000000)   (0.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.0000000, 1.0000000)
7  (0.0000974, 0.0000974, 1.0000000)   (0.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.0000000, 1.0000000)
8  (0.0000974, 0.0000974, 1.0000000)   (0.0000000, 0.0000000, 0.0000000)   (0.0000000, 0.0000000, 1.0000000)
9  (0.1856620, -0.6441207, 0.7420500)  (-0.9486812, 0.3162340, 0.0000000)  (-0.5324074, -0.5324074, -0.6580917)
10 (0.1856620, -0.6441207, 0.7420500)  (-0.9486812, 0.3162340, 0.0000000)  (-0.5324074, -0.5324074, -0.6580917)
11 (-0.1853896, -0.6440765, 0.7421564) (-0.9486812, -0.3162340, 0.0000000) (0.5324074, -0.5324074, -0.6580917)
12 (-0.1853896, -0.6440765, 0.7421564) (-0.9486812, -0.3162340, 0.0000000) (0.5324074, -0.5324074, -0.6580917)
13 (-0.1459682, -0.7986262, 0.5838574) (-0.7070991, -0.7071145, 0.0000000) (0.5324074, 0.5324074, -0.6580917)
14 (-0.1459682, -0.7986262, 0.5838574) (-0.7070991, -0.7071145, 0.0000000) (0.5324074, 0.5324074, -0.6580917)
15 (0.1459481, -0.7986660, 0.5838080)  (-0.7070991, 0.7071145, 0.0000000)  (-0.5324074, 0.5324074, -0.6580917)
16 (0.1459481, -0.7986660, 0.5838080)  (-0.7070991, 0.7071145, 0.0000000)  (-0.5324074, 0.5324074, -0.6580917)
 

 

 

Anyway ... unless the normal mapping on the new models turn out to look all messed up ... newly normal-mapped models (and compiler support) might be coming sooner rather than later.

[Malkior 476]

I can volunteer to test it, if you have specific models you want to see in-game, and post screenshots on how it looks. It shouldn't be too hard to implement, if it's just an Override drop.

[DarthParametric 3,782]

Interesting. I have some work to do today, but I'll poke through this some more when I get time tonight.

 

FYI, the values he posted above are definitely for the non accumulated face vectors. Here are the numbers I get from my calculations for it (for anyone else trying to implement the calculations)

The values I posted were derived from Eshme's Max/GMax Dragon Age Origins Import/Export script. Given that Eclipse was seemingly an evolution of Aurora/Odyssey, I was hoping there might be some similarity in how it liked its models set up. Apparently not though.

 

Edit: OK, I created a placeable version for TSL, spawned right in front of the landing pad on Nar Shaddaa. I've bundled it up as a TSLPatcher installer: http://dpmods.wheb.org/files/kotor/tsl/%5BTSL%5D_DP_Test_Pyramid_Placeable.7z

 

Unfortunately, after an initial in-game test I realised that the original model was a tad small, so I had to scale it up to something more useful:

 

 

This altered the vert positions naturally, but I left the texture co-ords untouched (despite them being fairly inefficient). I also assigned a texture. The ASCII version is included, so hopefully it isn't too painful for you to create a revised binary version with normal data. Just overwrite my version in the Override folder after you've installed it.

[ndix UR 218]

I've put together a small package of newly-bump-mappable models for people to play around with. It also includes textures and TXI's that should all just work when dropped in Override.

 

@DP thanks! That is quite a helpful little test package you've put together. I've included a normal-mappable recompiled version of the pyramid model in this test package.

 

bump-testing2.7z

 

Package contents:

• DP Test Pyramid recompiled (download package in above post, install, then replace model & textures w/ this package's contents)
• Darth Sion (n_darthsion)
• Gammorean Cleaver (w_waraxe_003)

I went through some excruciating difficulty to get a rig set up that lets me at least see the bump-mapping effect, so I can confirm that it should be working for at least the axe... Bump mapped weapons seem to work, and seem to have a lot of potential...

 

I was able to test the 'blue/usual' 8-bit color TGA normal maps vs. the 'red/swizzled' 8-bit color TGA normal maps, and it seems to me like the 'red/swizzled' is definitely what the game is looking for (just visual inspection, no glintercept confirmation or anything).  That said, I haven't figured out a workflow to produce color normal maps that work as well as grayscale ones yet. My color normal maps come out with artifacting around the bump features that don't happen when I use grayscale.

 

If any of the models seem busted, or people notice any visual discontinuities in them related to bump mapping, feel free to pm me or post screens or whatever. Sorry for not posting screenshots, but my bump map test machine is all kinds of terrible.

[thunder3 56]

Hey everbody here!

I have read through this thread and it´s really hard to follow all the bits of information that are scattered around this thread to put it together. First of all, I have to say that all of the research work here is very impressive and I thank all of you that you invest so much time into it.

 

My following question now is:
 

What do I have to do to get Bumpmaps / Specularmaps to work on models that don´t have them in vanilla.

 

Additional information: up to now I´m only modding KotOR1 so far. I have some good expirience in modeling and texturing and if theres a need, I am able to code some program.

 

So if one could provide me with enough information about the file structure of MDL and MDX and how the Aurora Engine handles those files and how the ascii counter part we need to work in 3DS Max / GMAX, I might be able to wright some program that is able to handle the import / export of those models better then now.

[DarthParametric 3,782]

This would probably be as good a starting place as any - http://deadlystream.com/forum/topic/4501-kotortsl-model-format-mdlmdx-technical-details/

[MaathFaselli 0]

On ‎8‎/‎14‎/‎2016 at 11:39 AM, ndix UR said:

I've put together a small package of newly-bump-mappable models for people to play around with. It also includes textures and TXI's that should all just work when dropped in Override.

 

@DP thanks! That is quite a helpful little test package you've put together. I've included a normal-mappable recompiled version of the pyramid model in this test package.

 

bump-testing2.7z

 

Package contents:

• DP Test Pyramid recompiled (download package in above post, install, then replace model & textures w/ this package's contents)
• Darth Sion (n_darthsion)
• Gammorean Cleaver (w_waraxe_003)

I went through some excruciating difficulty to get a rig set up that lets me at least see the bump-mapping effect, so I can confirm that it should be working for at least the axe... Bump mapped weapons seem to work, and seem to have a lot of potential...

 

I was able to test the 'blue/usual' 8-bit color TGA normal maps vs. the 'red/swizzled' 8-bit color TGA normal maps, and it seems to me like the 'red/swizzled' is definitely what the game is looking for (just visual inspection, no glintercept confirmation or anything).  That said, I haven't figured out a workflow to produce color normal maps that work as well as grayscale ones yet. My color normal maps come out with artifacting around the bump features that don't happen when I use grayscale.

 

If any of the models seem busted, or people notice any visual discontinuities in them related to bump mapping, feel free to pm me or post screens or whatever. Sorry for not posting screenshots, but my bump map test machine is all kinds of terrible.

Can you update the archive? It's broke

[ndix UR 218]

Nah ... Enabling bump-mapping is now a standard feature of MDLOps and MDLEdit, so anyone can enable bumpmaps on any model now by using those tools. This is a solved problem.

But while we're putting stuff in this old thread, here are a few extra caveats pertaining to bump/normal maps for KotOR models that have been discovered in the last year or so.

1. To get full-function, full-color normal maps, simply convert to TPC format. The game uses uncompressed image data, but compressed will work. It's been shown that the 8-bit color workaround I mentioned above is being interpreted by the game basically the same as an 8-bit grayscale bumpmap. If you want to use grayscale bumpmaps, that is fine, they work almost as well in some cases with this particular game engine. The only real reason to distribute 8-bit color bumpmaps at this point is probably that people who know what they're doing can convert them into full-function normal maps.
2. The lighting calculations in-game that use normal maps are per model. This means that if you normal map a protocol droid, then you put 10 protocol droids (even with different 'appearance' rows) in one area, the lighting effects would be the same on all of them. Sad but true. There are a few different phenomena that behave like that... (danglymesh, most notably)
3. Sometimes adding bumpmap/tangentspace calculations to a model, then not using a bumpmap (by changing the TXI to not use them), will cause the game to crash. So far this has only been observed in area models.
4. There's no way to use different bumpmaps via TXI when you use appearance.2da rows. For example, say you have modelA, which references textureA in the MDL file nodes, and textureA references bumpmap textureAB in its TXI file. If you add a line to appearance.2da saying model = modelA, racetex = textureB; and you have textureB referencing bumpmap textureBB in its TXI file, textureBB will not be used. The bumpmap will be textureAB. Also, this situation confuses the game when it comes time to release memory (or maybe load models), so if you are using 4K+ resolution bumpmaps, you will crash the game in certain circumstances if you do this (usually during area loading). This problem also applies to envmaps (this is the root cause for why people end up with semi-transparent HK-47 when they try to add an envmap in the TXI), but for envmaps, there is a column in the appearance.2da that lets you override the envmap that is used in each appearance row. There's nothing quite like that for bumpmaps as far as I could tell.

 

[Malkior 476]

Since you're listing the new discoveries and features of the new tools, could you list step-by-step how to add bumpmaps to any model? (Be it character or placeable) Kotor has the flattest faced characters in history, and I think it could do wonders for the visuals if we could bumpmap the lot of them.. 

[DarthParametric 3,782]

You need to enable the bumpmappable/tangentspace flag when compiling the model, then specify the normal/bump map in TXI of the diffuse map. Creating the map itself is done in the standard manner for any game engine, but as @ndix UR pointed out above, normal maps need to be converted to a RGBA TPC in order to work. TGAs will cause the game to hang/crash. There will be more detailed, step-by-step information available once @Tyvokka implements the wiki.

[JCarter426 1,214]

Here's a quick and dirty list in the meantime:

1. On your model, for each bit of geometry that you want to use a normal map, make sure the object has the OdysseyTrimesh modifier and select it to be "bumpmappable" and export. On the ASCII, this flag is "tangentspace 1". Export and convert to binary as usual.
2. Your model's diffuse texture will have to point to the bump map in its TXI data. "bumpmaptexture" and then the name of the bump map texture.
3. Make the bump map texture. You can do this in your modeling program if you have skills like DP, or you can do it the lazy way and make a greyscale height map, with white being the raised bits and black being the lowered bits. You can convert a height map into an RGB normal map with a tool such as Nvidia's plug-in for Photoshop.
4. Save the normal map as a TGA in indexed color mode.
5. For the TXI data, at minimum you need the bump map's to say "isbumpmap 1".
6. Convert your bump map TGA and TXI to TPC if you don't want to crash the game. The diffuse texture is fine as is.
7. I've attached example TXIs. Mine have a bit of extra properties too.

6 hours ago, ndix UR said:

There's no way to use different bumpmaps via TXI when you use appearance.2da rows. For example, say you have modelA, which references textureA in the MDL file nodes, and textureA references bumpmap textureAB in its TXI file. If you add a line to appearance.2da saying model = modelA, racetex = textureB; and you have textureB referencing bumpmap textureBB in its TXI file, textureBB will not be used. The bumpmap will be textureAB. Also, this situation confuses the game when it comes time to release memory (or maybe load models), so if you are using 4K+ resolution bumpmaps, you will crash the game in certain circumstances if you do this (usually during area loading). This problem also applies to envmaps (this is the root cause for why people end up with semi-transparent HK-47 when they try to add an envmap in the TXI), but for envmaps, there is a column in the appearance.2da that lets you override the envmap that is used in each appearance row. There's nothing quite like that for bumpmaps as far as I could tell.

Hmm, is this problem specific to K2? I've only just started fiddling around with maps on character models but I haven't had any issues applying them yet. But if remember correctly, the TXI issue is only a problem in K2. K1 does load it properly from the TXI when the 2DA is set to default. So if it's the same deal as that, maybe the bump maps are ok in K1 too.

Bump Map Example TXIs.zip

[ndix UR 218]

20 minutes ago, JCarter426 said:

Hmm, is this problem specific to K2? I've only just started fiddling around with maps on character models but I haven't had any issues applying them yet. But if remember correctly, the TXI issue is only a problem in K2. K1 does load it properly from the TXI when the 2DA is set to default. So if it's the same deal as that, maybe the bump maps are ok in K1 too.

So, I don't think I've personally confirmed it in K1, so I can't say. However, from ... other things ... I expect the issue to be the same. I would love to know if anyone does a conclusive test.

Just to be clear, the thing is, the engine loads the bumpmap from the TXI ... but only for the texture defined in the model. So, when you are using the appearance to specify a different texture that is not what you have for 'bitmap' in the model file, then it will only do whatever the TXI file for the original texture specifies. So if you are using the same bumpmap on multiple appearances, nothing will really seem wrong. I originally encountered this when I was trying to get different cubemaps on each protocol droid reskin I was doing, and then we actually realized what was happening when DarthParametric was experiencing some crashing issues with his outrageously high quality normal maps.

The reason this happens to HK-47 in K2 and not K1 is that the K2 version of the HK-47 model doesn't specify any diffuse textures in the model itself! All NULL. This makes it so that there is no way to get an envmap other than using the appearance.2da column. It's also the issue that makes it so the sith war droid only has a gun texture w/ its 'base' coloration, but with each of the 3+ other colors, the gun model it carries winds up textured with the droid texture and not a gun texture. My personal takeaway has been that it's probably better to remake a model for each custom texture rather than to use appearance.2da, at least until we figure out what the model loader's limitations are...

This would actually be a pretty easy/convincing test to run in K1, just NULL out all the bitmap entries for a model, compile it, put it in game (make sure appearance.2da envmap column is set to default) and try to get envmaps via TXI. Or even just recompile the K2 HK-47 model for K1 (for testing purposes) and test using that, since it already has null diffuse textures throughout.

[JCarter426 1,214]

Hmm, that's interesting. I think I'm starting to connect some dots...

Logic would tell me that if a texture can have shader info (either on a TXI or in a TPC) then the game should read that when it reads the texture but we've always known that's not the case. You can't use whatever cube map you want on a texture for PMBFM, for example - it always ends up as CM_Bright. And that's down to the shader info on PMBF01 being "envmaptexture CM_Bright". Even if you were editing PMBF02 or 03 or whatever, it wouldn't care. So we've known for a while now that the rule was you can't have different things on different texture variations. It would always default to whatever the first texture said.

For HK-47, I can guess the reason his model is lacking textures in K2 - they left them out because they knew they'd be using multiple textures on different HKs for the same model. It's the same case with the Mandalorian variants and other models that rely on race textures. They're missing shaders in K2 and editing the TXIs doesn't do anything. While I was working in K2 I was just used to that being the way things are, and then when I got back into modding K1 I was surprised when I didn't run into that problem. I figured that was down to the games being different, since there are numerous things that are broken in one and not the other. But if your theory is correct then it's nothing to do with the game, and it's not the first texture's shader info either - it's the shader info of the texture that's on the model (by coincidence, this is usually the first texture variation). Even if that texture is never being drawn.

Now, I've looked at the Mandalorian models. There's a texture in K1 and there's no texture in K2. I don't know why. But this is starting to make a lot of sense.

I feel like it can't be that simple but I don't think my memory is reliable. For so long I've been defaulting to editing appearance.2da because I knew that worked. So I can't say I had to do it every time I did it. Further testing is still needed.

1 hour ago, ndix UR said:

My personal takeaway has been that it's probably better to remake a model for each custom texture rather than to use appearance.2da, at least until we figure out what the model loader's limitations are...

Yeah, that's been my policy as well.