Narve's works and learning

[Narve]

Hi everyone on this great forum! 😊

I decided to start my own little thread, even though I’m still relatively new here. I’ll be posting my work-in-progress, notes on how things are done - mainly for myself, so I can come back and refresh my memory later. If it ends up being useful to someone else as well, I’ll be happy of course. I’m sure everything I’m writing about has already been discussed countless times on this forum and is familiar to everyone. But I’m still a newcomer!

My already released mods:

• New portraits for PartyMembers
• HD Animated Computer Interface
• Saul Karath Retexture
• Narve's New High Poly Canderous Head

While working on the Canderous head I made a bit of progress learning Blender. I only knew it at a very basic level before, because I’m a 2D artist, not a 3D one. I still don’t really know what proper topology should look like, how to paint weights correctly, how to build textures with nodes, and so on. I’ll be learning all of that gradually.

For this particular head I took a high poly mesh from this mod - big thanks to the author! Of course I heavily edited it: the geometry, the UV unwrap, and the texture. I also learned a few useful texture painting tricks. Geometry-wise the hardest parts are always the eyes and the lips, because the animation has to deform them properly, and what looks fine in Blender often ends up looking completely different in the game.

Spoiler

Something I’d like to note here for myself - how to get rid of grey spots on the model after exporting from Blender to mdl/mdx:

1. The most important step - clear Custom Split Normals Data:

• Select the head mesh in Object Mode.
• Go to the Object Data Properties tab.
• Expand the Geometry Data panel.
• If the “Clear Custom Split Normals Data” button is active, click it. This removes the old broken data and forces Blender to recalculate the normals.

Spoiler

Also helpful:

2. Apply smoothing — Right-click the model → Shade Smooth.

3. Apply transforms — Use with caution and only when needed! Things can shift in unexpected ways. In Object Mode select the head and press Ctrl + A → Apply All Transforms.

Spoiler

____________________________________________

P.S. English is not my native language, so I apologise in advance if anything is phrased awkwardly.

 

____________________________________________

Then I decided to retexture the high-poly Bastila body from the TCS mod. The thing is, we started playing through BOSSR on stream, and there Shadow uses Bastila’s body. And we have this Bastila mod installed. So I made her this outfit. I didn’t touch the model or the UV unwrap, only the texture. I painted the alpha channel in the places that should be more shiny. Since I don’t know how the original model author would feel about this little “side project” of mine, of course I won’t be releasing this texture anywhere — it’s purely for personal use.

Spoiler

After that I moved on to her head. I wanted both the lekku and the face itself to have more polygons. So I simply applied a Subdivide, then worked on the mesh — editing vertices, sculpting, and so on. Then I started texturing, and at that point I really wanted to add a bump map so the lekku would look bumpy the way vanilla Twi’leks do (even if the vanilla ones are very low quality). I dove deep into the problem — I remember spending entire weekends glued to this forum reading everything people wrote about adding bump.

Nothing was working for me.

I tried every piece of advice, converted the poor bump map to TPC every which way, opened the model files in ASCII and searched for tangent vectors… I even started recalling university calculus about quaternions and how I used to redefine matrix multiplication in C++ practicals…🤣

It turned out the problem was completely different. The BOSSR mod authors used the "Twilek05" head model, but in heads.2da they assigned it the texture name "matilda_headd". Meanwhile the model itself is linked to the texture "Twilek05". And even though the engine can pull the main (diffuse) texture information from a texture that isn’t the one specified in the model, it cannot pull bump map information (and apparently txi info as well) from a texture with a different name! I don’t know why it works this way — maybe some internal script.

Anyway, once I renamed the main texture to "Twilek05.tga", the bump map to "Twilek05b.tpc", wrote this in the "Twilek05.txi":

bumpyshinytexture CM_SpecMap
bumpmaptexture Twilek_F05b

and also put "Twilek05" as the texture in heads.2da — miracle of miracles, the game finally saw the bump map!

 

 

Spoiler

Spoiler

Spoiler

Yes, it didn’t turn out perfect — the bumps are too fine and therefore look a bit like shimmering. I probably won’t fix it, because we had to abandon that mod playthrough — it conflicted with other mods.

But I’ll write down the key points needed to add bump (even though all of this is already on the forum — huge thanks to DarthParametric and everyone else who shared advice and tutorials):

1. Before exporting, you must enable the “Tangent Space” checkbox in the KotOR Model Node plugin options for all the meshes that need it (in my case “hair” and “head”). 
   Spoiler

   

    

2. To verify — open the model in MDLEdit, save it as ASCII, open it in Notepad++ and search for the word “tangentspace”. On the relevant nodes it should say tangentspace 1, not 0. If it somehow still shows 0 even though the checkbox was enabled on export from Blender, change it to 1, save, open that ASCII file again in MDLEdit (it might complain that it can’t recalculate the vectors — hopefully that’s not a problem), and then save it back to binary mdl/mdx. 
   Spoiler

   

3. You can also just tick the corresponding checkbox in MDLEdit itself and re-save — but keep in mind that the bump will then be applied to every mesh in the model that uses that texture, not only the ones you might have wanted. 
   Spoiler

   

4. Preparing the .txi. It must have the exact same name as the main texture, and the main texture must be the one that is actually linked to the model.
   Inside the .txi you need:

bumpyshinytexture (your Cubemap)
bumpmaptexture (your bump map name)

In theory bump should work without the shiny part (only the line "bumpmaptexture " in txi), but for me it never did — because in that case the engine treated the alpha channel of the main texture as transparency. Meaning:

• if you darken the alpha to make the bump stronger → the object becomes transparent
• if you leave it white → no bump is visible.
  Maybe I’m doing something wrong?

5. Preparing the main texture. It must be named exactly as specified in the model (you can check that here).
   Spoiler

   

   It needs an alpha channel that controls both the shininess (via the Cubemap) and the strength of the bump. The darker the alpha, the stronger both effects. Yes, both at once — there’s no other way.
6. Preparing the bump map. Save the main texture as an image and throw it into this website (again, thanks for the link — found it on the forum). You can increase Strength if the texture isn’t very contrasty, and add a bit of blur (slider to the negative side). Download the result and save the texture as TGA with a pure white alpha channel.
   Then use tga2tpc with these settings.
   Spoiler

   

   You can also add extra lines or strengthen the bump with the bumpmapscaling value, as DarthParametric wrote here:
   https://deadlystream.com/topic/9353-bump-mapping-tutorial-request-for-novices/#findComment-87017
7. Final contents for the override folder: the model (mdl + mdx), the main texture (tga), the .txi with the parameters, and the bump map (tpc).

Phew. The last thing I learned on this head was adding new geometry — I wanted to model headphones and a stone on her forehead. Important points here: convert everything to triangles and weight-paint it to the head.
To check — switch to Weight Paint mode and make sure it’s painted red. If you need a piece not to move with the head, weight-paint it to the neck instead (a different vertex group).

Spoiler

If you don’t weight anything at all, those pieces of the model simply won’t appear in the game.

🙃🙃

I’ll say it again: I’m by no means an expert on KOTOR modding, so I apologize if I write or do anything incorrectly! And, of course, I’d be grateful for any advice, comments, or corrections.

Edited Sunday at 09:20 AM by Narve

[Narve]

The next big project was a retexture of the Ebon Hawk’s exterior hull. Looking at the vanilla one was genuinely painful, and the existing retextures didn’t really improve the situation.

I really wanted to bring its appearance closer to this:
https://www.artstation.com/artwork/GXwXyB

Because in my game I’ve replaced the original cutscenes with several very beautiful ones that use this model. And the model itself is just awesome!

But I immediately ran into the problem that the UV layout was completely unsuitable - a lot of overlapping, and many areas of the texture were shared between completely different parts.

And… I went down the wrong path. I found the "v_ehawk" model in the game files and started fixing the UV unwrap. I did everything properly: separated the overlaps, made the areas that are visible up close when you walk around the ship larger. Texture in 4K. I was even about to start editing vertices and adding polygons. But then I discovered that none of my changes were visible in the game at all. I spent several days scratching my head, thinking I was exporting the model incorrectly somehow.

Of course it turned out to be much more mundane - the model I was editing had nothing to do with the ones that appear on the landing pads on different planets. I have no idea where the game actually uses it - probably in some cutscenes? What we see on the landing pads and in the docks is part of the area, not a separate model. And if I want to edit it, that means editing the entire area - which automatically means incompatibility with any other mod that also edits that area.

So I sulked a bit, complained a bit, and decided for now to limit myself to pure texture work.

But then another “brilliant” idea struck me - we don’t look for easy ways, right? Realising that adding polygons wasn’t going to happen, I wanted to add a normal map, inspired by my previous experience with the Twi’lek head. I thought, at least it won’t be a flat picture stretched over polygons, there will be some relief. I also spent a long time on the texture itself, adjusting it so that the overlapping UV pieces still looked decent… It was challenging to strike a balance between the desire to match the reference and the limitations of the existing UV layout. I hope the result turned out well. I wanted to make 8K textures, but the engine was clearly starting to struggle when loading areas, so I settled on 6K.

But with the bump I was in for a fiasco.

Actually, I could have suspected something when looking at the original game files - there was no bump specified in the .txi files at all, even though bump maps were provided for every texture. Why do they exist? I still don’t know the answer to that question.

Interestingly, the engine did react to the presence or absence of the bump map - the shaders changed and the image looked different. But the actual content of the bump map didn’t affect anything. For the experiment I tried both a completely flat solid “blue” bump map and an extremely contrasty one amplified 15× during conversion to TPC. There was zero difference.

After quite a long series of experiments with different bump settings, .txi options, and the alpha channel of the main texture, I finally found the answer — and I’m sure it has been discussed somewhere on this forum, I just never came across it. On area objects the lighting is almost completely baked into the lightmap. Dynamic bump (the kind that reacts to real-time light direction) barely shows up at all. Especially if the lightmapped flag is enabled on the mesh.

I looked into the node of the long-suffering ship, and sure enough, there it was:

Spoiler

node trimesh EbonhawkBody
  parent M13aa_01a
  position 22.17 -0.0975 11.3775
  orientation 1.0 0.0 0.0 0.0
  alpha 1.0
  scale 1.0
  selfillumcolor 0.0 0.0 0.0
  diffuse 1.0 1.0 1.0
  ambient 1.0 1.0 1.0
  transparencyhint 0
  animateuv 0
  uvdirectionx 0.0
  uvdirectiony 0.0
  uvjitter 0.0
  uvjitterspeed 0.0
  lightmapped 1
  rotatetexture 0
  m_bIsBackgroundGeometry 0
  shadow 0
  beaming 0
  render 1
  dirt_enabled 0
  dirt_texture 1
  dirt_worldspace 1
  hologram_donotdraw 0
  tangentspace 1
  inv_count 353
  bitmap LDA_EHawk01
  bitmap2 M13aa_01a_lm0
...

 

As an experiment I turned off the lightmapped flag. And to my astonished eyes this is what appeared (the bump map at that moment was the extreme one) — view with caution! 🤣

Spoiler

Of course it’s pure horror, some kind of Dark Side of the Force visions. 😁

So I don’t know whether to include these normal maps in the mod release for the textures where the ship is part of the area. Are they needed? Probably not.

For the model that isn’t part of an area - apparently the one used in some cutscenes - I will of course add the bump. Might be useful.

A few nice pictures:

All that’s left is to add the texture for the upper hull (roof) model that is used in the mini-game where you shoot down fighters, and touch up small details here and there. And then the mod can be released.

[Vriff]

Nice work, yeah, might be worth testing if Synchro's patch for Kotor Patch Manager fixes this in k1. Some of the shaders are long broken, and it's possible that on period correct hardware this actually worked differently.

 

If you port to K2, to work in the Aspyr version you'll have to have my bump map fix, otherwise bump and normal maps simply don't work.

[Narve]

On 9/25/2026 at 8:51 PM, Vriff said:

Nice work, yeah, might be worth testing if Synchro's patch for Kotor Patch Manager fixes this in k1. Some of the shaders are long broken, and it's possible that on period correct hardware this actually worked differently.

 

If you port to K2, to work in the Aspyr version you'll have to have my bump map fix, otherwise bump and normal maps simply don't work.

Thank you very much! 😊

As for the Modern Driver Compatibility Patch - I haven't tried or tested it because I’ve never encountered the issues it fixes (based on my understanding of the description): the grass, fog, energy fields, and bump maps on Twi'leks, Hutts, and other creatures always appear correctly for me. But it might be interesting to check out!

As for TSL - yes, I definitely plan to port the Ebon Hawk to it. I'll keep that fix in mind - thanks again!

[Narve]

Another work of mine that’s currently in progress is the Juhani head model. It’s high-poly and has a 2K texture. The work is actually already finished, but I’ve realised I can’t release it like this - now I need to either rework the texture or even the body model, because the difference is too noticeable at the moment.

Spoiler

Spoiler

During this process I learned a lot in Blender, but there’s no point writing about that here. The only thing really worth noting is how the game renders danglymesh with different weights. With weights greater than 0 up to roughly 0.6–0.7 the vertices get a kind of “semi-freedom”: the engine shifts them, but not as predictably as at 0 (fixed, locked to the head position) or near 1 (completely detached from the head and dangling with the set amplitude, stiffness and period). So when weight-painting the tail I used 0 near the attachment point and then jumped straight to 0.7 without a smooth transition. Toward the tips I softened it to 0.6–0.5 - the tips can dangle freely, they’re allowed to!

Spoiler

Spoiler

I don’t know, maybe it can be done better, but at my current level of understanding the process I think this is the maximum. Yes, the lips also had to be re-weighted - I spent two days painting them this way and that, checking every frame, but in the end I got a result without any pinching or artifacts.

[Dark Hope]

Hi. I noticed something about these weights: the 1 and 0 regions are completely locked. The 0.5 area is where the deformation is strongest and most unnatural. I try to avoid those weights (the blue and green ones) and start from 1 instead of 0 (like in the original). The animation turns out smooth and natural.

Привет. Я такую штуку заметила в весах: 1 и 0 области полностью зафиксированные. 0.5 это область с самой сильной и неестественной диформаций. Я стараюсь избегать этих весов (синие и зеленые). И начинаю не от 0 (как в оригинале), а от 1. Анимация получается плавная и естественная. 

Spoiler

 

[Narve]

Yes, for short hairstyles the best option is to start from 1. I looked at how different hairstyles are weighted in the vanilla models and noticed that on long tails and other long dangling parts the weight is 0 at the attachment point. I’m not exactly sure what causes this - maybe the length of the danglymesh, or the distance from the attachment point? Or the fact that it’s attached only in a small area rather than across the whole surface of the head?

So for now I’ve set roughly the same weights that are in the original model, because I’m afraid of accidentally triggering an unexpected bug somewhere. 😆 Although I myself haven’t noticed any particular difference between weight 0 and weight 1 either.

Spoiler

Да, для коротких причесок лучший вариант начинать от 1. Я смотрела, как разные прически развесованы в ванильных моделях, и заметила, что в длинных хвостах и других длинных развевающихся деталях вес равен 0 в месте крепления. Не знаю точно, с чем это связано - может, с длиной данглимеша или с удаленностью от точки привязки? Или с тем, что он крепится в небольшой области, а не по всей поверхности головы? 
В общем, пока поставила примерно такие веса, которые стоят в оригинальной модели, потому что боюсь случайно словить где-нибудь неожиданный баг.)) Хотя сама тоже не заметила особой разницы между весом 0 и весом 1.

Когда (если?) буду делать тело, заодно потестирую и поведение хвоста в разных положениях и анимациях.

 

[Synchro]

Hi @Narve, great write-up!

I’m the author of the modern driver compatibility patch @Vriff mentioned, and I dug into the engine side of what you ran into. It’s the renderer’s design, not due to an authoring or tooling issue as far as I can tell.

There are two different kinds of “bump” in K1, and the .txi chooses between them:

• bumpyshinytexture + bumpmaptexture is environment-mapped bump. The bump map only distorts the cube map reflection; it never affects lighting. The reflection is weighted by your diffuse alpha: dark alpha shows it, white alpha hides it. That’s why you found alpha controls shine and bump together. In this mode they’re the same effect.
   
• bumpmaptexture alone is real lit bump, but only from a dynamic light. The engine picks the single strongest light that isn’t ambient-only and has a dynamic type, and bump-lights against that. Without that kind of light nearby, you see no bump at all. The wet highlight is masked by dark alpha, and without an env map, dark alpha also reads as transparency, which is probably the issue you hit.
   
• For the Ebon Hawk: with bumpyshinytexture in its .txi and a mostly white alpha, the bump has nothing to show through, so its content can’t matter. Without that line, a lightmapped mesh with tangent space gets lit bump on top of the lightmap, but only near a dynamic light. Adding renderbmlmtype 0 makes it diffuse only; otherwise it also adds a specular highlight.

One catch worth mentioning: in the unmodified game, the lit-bump paths only ever ran on NVIDIA cards. Are you on NVIDIA? If so, you’re seeing what the game was built to show.

PS: I wouldn’t use the patch to test bump on heads quite yet. After investigating this I found it currently skips lit bump on skinned meshes that use bumpmaptexture without bumpyshinytexture, and I’m fixing that. Lightmapped lit bump also isn’t implemented in the patch yet; it’s next on my list.

The game has two shading backends, one for NVIDIA and one for ATI. The patch is built on the ATI one so it runs on every card, and the ATI backend never had these modes. The NVIDIA one did, so I’m porting them from it.The ATI path handled most of these rendering modes differently, and the patch was built off of them instead of replicating the NV_register_combiners implementation.

If you’d like to experiment with the shading itself, every shader the patch generates can be overridden by dropping an ARB fragment program into override/shaders
The lightmapped bump modes will become overridable the same way once they exist.