[Riddle solved] Problem with replacing (some vanilla) tile textures via MTR (80.8193.9 - probably earlier)

I’m testing a bit the usage of MTR-files with normal and spec maps (game version 80.8193.9) with the aim to replace a texture on tiles here an there. I ported an existing module over to EE and now want to fancy up the textures here and there.
So my test started with the aim to replace the standard dirt road texture within the Bio-tileset ttf01. Replacing the texture itself works, but as soon as I use “renderhint NormalAndSpecMapped” in a mtr-file the road texture is rendered pretty dark and tinted (in the TS and also IG!):

“renderhint NormalAndSpecMapped” in a mtr-file alone is enough to cause this, even if I have no other texture defined. It makes no difference, if I add none, the diffuse or even normal and spec maps to the mtr-file. (Remark: The mtr is not compiled, because when I use them on creatures, it’s OK, if they’re not and the textures are tga, which also should not cause a problem.)

All I want are the standard colors/brightness of the road texture and make it look a bit more bumpy (via normal and spec maps).
I had it in the override, then moved all into a HAK and cleaned out the override. No changes in the appearance!
I checked other EEed content and they only have the according entries in a mtr-file (renderhint NormalAndSpecMapped, texture0/bitmap, texture1, texture2-defs).

This is driving me nuts! So, what am I doing wrong here?

No replies? Am I the only one with this “issue”?

Edit: I took a few pokes in the dark and found, that this is influenced by the Ambient Color setting in the environment options of the area. Setting them to white will let them appear as the non mtr textures.

BUT, do I want to roam through countless areas with their different visual settings (clear, muggy, raining, …) to get this corrected? AND setting the to white doesn’t make much sense, if the area is supposed to be dark, because then they’re not dark anymore. There must be a different solution!

There are quiet a few modules/server out there. How did you handle this, when implementing mtr-s with normal and spec maps??? (Please!)

1 Like

So you want something like this?

ShadowM! Exactly! Thanks for this shot! Could you please tell me, what you did / what I have to do to get it to work? And while your result looks promissing and it’s probably related to my torch topic: Is it influenced by torch light (Problem with torchlight NOT influencing mtr-textures)?

Sorry for the late reply. I see about getting together a little quick guide up to get you back on track.

1 Like

Thumbs up! Thank you!
Looking at custom shaders eg. by MD or Soren, I wonder, if the solution is to be found somewhere here, too. Reading their dscription hints, that different shader calls for different types (tiles, creatures, …) should be included in the mtr… Anyways, if yes, it should be doable with the EE default shaders - I hope.
Well, I’m glad you will try to get me back on track and I’m very much looking forward to it.

What program are you using to edit the mdl and what program are you using to make your normal map? I going to show you with Notepad++ and gimp. That work?

2 Likes

Don’t know about @BlackRider but it definitely works for me.

TR

1 Like

Looking at his image it might be compression tga that causing the problem.

So we grab say ttf01_g01_02.mdl from explorer

Link to latest version.

Open it with Notepad++ if we get something like this then click on the ASCII tab and outside click and export as text option. Open the text select all and copy and then select all in Notepad++ and paste.(I know there other ways of doing it, I like this way)

Now you have something like this.

You know the texture for the road is TTF01_road01 (by checking the bitmap of the mdl , or other ways) Now you export that out and open it in gimp.

  1. Select color desaturate / desaturate (choose your type, I like hsv).

  2. Select color brightness / contrast move up your contrast to at least in the 70s

  3. Select filters / generic / normal map. You should have a image similar to this.

Scale is how bumpy it will be I suggest a lower number like 4.00

The flips will flip which colors will have a cut in effect or level out effect. You can try different setting until you find something you like.

  1. Export it as ttf01_road01_n for consistency. No compression.
    Now back to Notepad++

Search bitmap until you get to TTF01_road01

tab down the row with verts 18 to make a space for the change. Paste the below and save.

renderhint NormalAndSpecMapped
texture1 ttf01_road01_n

5 Likes

THANK YOU VERY MUCH for your time! I don’t have time right now but I’ll check it out tomorrow and will report!
BTW: Gimp is OK! I have it and know may way around a bit. So that’s good. My plan is not to edit models but to use the mtr. I’ll see. Thanks again!

So I can announce some success! One mistake, I could have done, was to accidently save a tga with compression, but now, they’re not. Besides the fact, that [quote ShadowM: Select filters / generic / normal map.] I don’t have that generic filter, but I got a different GIMP normal map tool, I have working textures.
AND: It does work, if I do the edits right in the model - as ShadowM did, BUT IT DOES NOT work, if I try to do in via a mtr. I have to do some more tests and will report my results, because I would not want to edit countless mdl-files.

1 Like

Oh yeah the normal map was plug-in for gimp(sorry forgot to mention that)
From my testing with mtr is you still have to have the unedited mdl file in the hak or override, it will not alter it from the base game.
From the shader examples if they are not included that when you get the purple look.
LINK
Image with only one mdl included as you see the others are purple.

That’s not an problem with the assets only being in the bic. It happens with some custom content too. There are models where some meshes are dark with NormalAndSpecMapped enabled and others look fine.
Importing them in NeverBlender and exporting them again fixed the models, i.e. they worked with NormalAndSpecMappd only being in the mtr.

I don’t know what the problem is though. The only difference I could make out is the order of tverts.

3 Likes

Yeah, I noticed that too Symmetric. This happened with the latest patch I had a model that was fine with the dev builds up until the patch and then the dark patch popped up and had to redo some of the normal mapping. Thanks for the information. :slight_smile:

Hello fellow bughunters an Easter greetings to all!

Thanks for all your further investigations. Now I don’t feel so stupid anymore! :grinning:

I can confirm, that if you extract the model, put it UNCHANGED (as ShadowM wrote) into a HAK (or override), add the according textures (including normal and spec map) and a fitting mtr with eg. here ttf01_road01.mtr:

renderhint NormalAndSpecMapped
texture0 ttf01_roadnew1
texture1 ttf01_roadnew1_n
texture2 ttf01_roadnew1_s

then it works!

As soon as you remove the model “renderhint NormalAndSpecMapped” in the MTR will cause this purple look.

But, of course, I don’t want to extract every needed vanilla file and put it in a HAK to make it show up fancy. But it seems to be an issue, which came with the latest patch, as ShadowM observed… (BTW: Is this reported to Beamdog?)

I couldn’t resist an tinkered some more and I did get it to work without extracting/touching the mdl-file by calling shaders in the mtr!
VERY IMPORTANT: For this “renderhint NormalAndSpecMapped” must be excluded from the mtr!

I’m new with shaders and don’t really understand the difference between (in this case) Vertex and Fragment shaders (yet - maybe someone can explain this to me here or in a PM). I tested the EE default shaders and found that either “vslit_sm_nm” or “fslit_sm_nm” give a nice result! BUT it’s only the one OR the other. If you call both, the texture is dark/purple again.

Working example 1:

// Default Vertex Shader
customshaderVS vslit_sm_nm // Non-static, sphere mapped

// renderhint NormalAndSpecMapped (EXCLUDED!!!)
texture0 ttf01_roadnew1
texture1 ttf01_roadnew1_n
texture2 ttf01_roadnew1_s

Working example 2:

// Default Fragment Shader
customshaderFS fslit_sm_nm // normal/spec mapped, sphere mapped

// renderhint NormalAndSpecMapped (EXCLUDED!!!)
texture0 ttf01_roadnew1
texture1 ttf01_roadnew1_n
texture2 ttf01_roadnew1_s

As written, I have no idea, what the differences in those default shaders is and which one would be the best here (in theorie), if this way is choosen. And, as written above, I’d be happy, if someone could explain this to me.

So, what is the way from here? Wait until another patch fixes this or make use of (custom) shaders, just to find out, that this might be another rabbit hole in the future…

2 Likes

In all likelihood, this is because the models are compiled prior to EE, meaning that they lack the tangent data used for normal mapping.

The reason that the two bottom material files work are likely because you’ve specified only either a fragment shader (FS) or a vertex shader (VS). Only if both are supplied will they be used (perhaps that should be revised though, hmm).

The reason it appears to be working is that it’ll just fall back to shaders that aren’t using normal mapping.

Bottom line: you need to extract all the models in ASCII format and put them in a hak or use your override folder to allow the game to generate tangent data on load. If you then use the console command compileloadedasciimodels, the game will dump compiled model files that contain the tangent data, which you can put in haks and overrides. Given that generating tangent data can significantly increase load times, having the models precompiled is highly recommended.

3 Likes

Alright! Thanks @Soren! So that’s why the approaches of Symmetric and ShadowM made it work!

So, I had to test the “compile via console” way: I had 2 ttf01-road tiles in the OR (and yes, only 2 MDL files plus the texture for the road and the MTRs - nothing else). Entered console, did the “compileloadedasciimodels”, the console returned “Success compiled 8 models…” EIGHT!!! OK, intresting! So I was going to check out these 8 compiled outputs, but I am too blind or stupid to locate them. Not in the MyDocuments-NWN-folders nor in the installation folders of EE itself. Where are they? :roll_eyes:

But in the end, it would be great, if there would be a way in the future to fancy up vanilla content without having to extract every model first and add it again in a HAK or OR. The MTR is such a smart approach to easily fancy up things. Beamdog, please make it also work for the installed contents without the need of extracting the models. :pray: :wink:

When you ran the ingame compiler, it should have created a folder in /documents/Neverwinter Nights called /modelcompiler. The files will be in that folder.

The prerequisite to decompile and recompile then repackage all models is the reason I abandoned normal/spec mapping. The minor visual gain isn’t really worth all the work involved extracting the models and decompiling them on top of creating all the new textures and MTR files to go along with it.

@GrumpyOldGoat: Thank you for curing my blindness, because that is, what I must have been! I now see the folder! :smile:
I also see those 8 files now. Eg. PNL_CHAT_PROMPT.mdl. No idea, where the program ripped that from because it’s not in the OR.
And you’re right. That’s quiet some effort to extract, recompile needed tiles from the vanilla sets. Hopefully BD comes up with another solution some day.