Black Line in middle of face.

[Guest]

Yeah, it doesn't seem practical.

It isn't but better than leaving it how it is.

[DarthParametric 3,782]

The vanilla UVs look like they should have enough padding, in theory. But Mission's base face texture is only 256x256, so it's conceivable that even at the first mip things might go awry. Perhaps another test would be upping the texture resolution to 512 and then 1024 and seeing what happens.

 

Can someone with the black line issue incrementally try these textures with the vanilla head model and report back what happens: https://www.darthparametric.com/files/kotor/misc/Mission_Head_Texture_Size_Test.7z

[olnorton 3]

Can someone with the black line issue incrementally try these textures with the vanilla head model and report back what happens:

There is no apparent difference between the 4 resolutions, in that they all have a very prominent black line.

MissionLine.7z

[DarthParametric 3,782]

I'm not sure it's an issue of UV padding then, at least as far as the texture is concerned. When I get some time later, I'll try contracting the UVs a bit, see what effect that has. Although even if that does fix it, again, it's not really a practical solution.

[sELFiNDUCEDcOMA 98]

So ill reiterate:

 

If you add a TXI file for the textures in question that has a line that specifies it needs to use a specularity map, you may find that you no longer have a black line as the black is replaced by the spec map used by the shader. May not be perfect, however, it doesn't require all the head models to be re UV mapped and textured so that there isn't a (black) seam in the middle of their faces. 

 

I mention it again as I don't think anyone has tried it yet and I currently am not able to -- pretty sure it works from past experience.

[olnorton 3]

I added a TXI file to make it use the CM_SpecMap with the stock Mission TPA but it made no difference.

Is there a particular SpecMap to use?

http://i.imgur.com/Zfez0pF.jpg

[sELFiNDUCEDcOMA 98]

Try it with your TGA.

 

My brain is not working 100% due to lack of food, but, if you mean TPC (?) the KoTOR image format, it has its own TXI and the engine could be overriding it. My retextures are a combo of TGA and TXI files overriding originals in the Override folder. So far haven't bothered to convert to the native engine format due to tool / pipeline limitations affecting workflow.

 

EDIT: oh, just hit me! Most of my work is in TSL and that is actually a different engine to KoTOR -- especially when it comes to rendering. This *may* limit the effectiveness of a specmap TXI solution.

[ndix UR 218]

I ran the experiment also, and had some similar and different results.

 

Same: different resolution didn't seem to make any difference.

 

Different: with DP's textures, I don't get a black line, I get a red line, which suggests that ... w/ my setup ... the texture image is tiling and there is some bleed from the right side of the image.

 

It seemed more noticeable the further away you are.

 

Here are my test images:

 

mission-face-line.7z

 

Also, I've had a CM_SpecMap envmap TXI in place from the beginning, using all TGA texture images.

mission-face-line.7z

[DarthParametric 3,782]

Interesting. But you're still getting edge bleed with a 2K map standing right in front of her. That's some fairly significant bleed.

[sELFiNDUCEDcOMA 98]

I ran the experiment also, and had some similar and different results.

 

Same: different resolution didn't seem to make any difference.

 

Different: with DP's textures, I don't get a black line, I get a red line, which suggests that ... w/ my setup ... the texture image is tiling and there is some bleed from the right side of the image.

 

It seemed more noticeable the further away you are.

 

Here are my test images:

 

mission-face-line.7z

 

Also, I've had a CM_SpecMap envmap TXI in place from the beginning, using all TGA texture images.

 

I think in some cases I  tried to solve it by actually adding a strip of pixels to the other side of the texture -- in cases where the uv butted up against the very edge of the texture. In case it was a wrapping / bleeding issue. Believe it made some difference in various cases. Hard to recall as this is from around 2 years ago if not longer than that.

 

@ olnorton: is your new texture the same resolution as the old one, and if not, what is it?

 

When it comes to retextures of heads based on vanilla textures, I do something along the lines of 4x the original size. I think that may be 1024x1024; though I would recommend at least 2048x2048 with people playing the game at higher resolutions being the norm. When the mipmaps are generated by the video card (opengl) they should be of a larger resolution and hopefully affect whether the black line appears and how severe in effect it is if so -- if ndix UR's analysis of the issue is correct.

[olnorton 3]

 

 

 

@ olnorton: is your new texture the same resolution as the old one, and if not, what is it?

When I said TPA, I meant TPC sorry, as in adding it to try and fix the default Mission.

But the TXI file is still in there and it hasn't help my re-textured 1024x1024 Mission.

The poor girl has taken to keeping her head bowed, you know how teenagers are with anything on their faces.

 

ndix UR, That is a noticeable difference, do you have an AMD graphics card?

[ndix UR 218]

I do have an AMD card, but I'm not sure how much that is really a factor because I am playing via Wine on a non-windows platform, so I don't have the usual ATI driver packages or OpenGL extensions.

 

I tried something that, while I'm not sure it is a viable 'fix', might be an interesting experiment.

 

Try adding both these lines to your TXI file:

mipmap 0

downsamplemax 0

 

Also make sure you're using a TGA in Override or the TXI file will probably not do anything.

 

For me this actually seemed to clear up the issue with Mission's face. It's not generally applicable everywhere this problem arises because it looks terrible for bodies and other things that are heavy on detail (winds up looking severely aliased from a distance). If it helps you though, we might at least be able to say that it is the fault of some sloppy math somewhere in the mipmaps/downsampling algorithms (to me, it seems like both, because either one of those lines alone doesn't fix the problem, but both together did).

[olnorton 3]

Try adding both these lines to your TXI file:

mipmap 0

downsamplemax 0

Thanks, I'm going to stick with this!

It certainly removes the line.

I'd never seen Mission in the level up screen without the line before.

The over aliasizing is a fair trade off for me.

[DarthParametric 3,782]

An alternative thing to try might be adding this to the texture's TXI:

 

clamp 1

Without ndix UR's lines of course.

[olnorton 3]

An alternative thing to try might be adding this to the texture's TXI:

clamp 1

Without ndix UR's lines of course.

 

Thanks DarthParametric.

This is very good too.

It doesn't remove the line quite as completely as ndix UR's method, but it doesn't have any visible side effects.

I'll keep this one in and see how it goes.

[DarthParametric 3,782]

You could try 0 instead of 1. I'm not sure if that's a valid value, but worth a try. I would also suggest trying it in conjunction with those test textures I posted earlier, to see if resolution has any influence.

Update: Correct formatting of the clamp semantic:

Clamp

Specify which axes the texture cannot wrap on. Valid values are 0, 1, 2, or 3. 
1 clamps the X-axis, 2 clamps the Y-axis, and 3 clamps both the X and Y axes. Default is 0, allowing all axes to wrap.

e.g.

clamp 3

For our more programmatically-inclined denizens, I am wondering if a potential solution might be utilising a wrapper like GLIntercept to change GL_CLAMP calls to GL_CLAMP_TO_EDGE.

[sELFiNDUCEDcOMA 98]

You could try 0 instead of 1. I'm not sure if that's a valid value, but worth a try. I would also suggest trying it in conjunction with those test textures I posted earlier, to see if resolution has any influence.

 

For our more programmatically-inclined denizens, I am wondering if a potential solution might be utilising a wrapper like GLIntercept to change GL_CLAMP calls to GL_CLAMP_TO_EDGE.

 

You mean an injector -- API hooking -- along the lines of ReShade?

 

Something I've thought about playing with to see what could actually be added to the game beyond merely injecting post process full-screen shader effects. Never got around to trying anything myself; work took over.

[DarthParametric 3,782]

Same basic principle, yeah, but nothing quite as dramatic as ReShade/SweetFX/ENB. GLIntercept should already provide the framework for what I suggested as far as I understand.

[Guest]

So any word on this?

[LiliArch 115]

An alternative thing to try might be adding this to the texture's TXI:

clamp 1

Without ndix UR's lines of course.

 

Out of curiosity, what is this "clamp" value?

[DarthParametric 3,782]

My guess is that is a call to the OpenGL command GL_CLAMP that stops the texture shifting more than the specified amount of pixels. This is logical given that some of these textures are only 256x256, so there is basically zero tolerance for the texture wrapping around past the edges. That command is deprecated in newer versions of OpenGL though, so I am wondering if that is part of the problem. As I posted above, the modern alternative is GL_CLAMP_TO_EDGE, which should stop texture wrapping altogether (in theory).

[DarthParametric 3,782]

I hate to necro an old thread, but I found something that may be of use to this issue. I mentioned in earlier posts about the possibility of overriding the GL_CLAMP call. I discovered that something people were recommending to fix K1's grass issues also has the ability to do this.

 

GLOverride - http://www.humus.name/index.php?page=Cool&ID=5

 

If anyone with the black line issue would line to test this, grab the file from the above link, extract to your K1/TSL folder, open opengl32.ini in a text editor and change

FixClamp = 0

to

FixClamp = 1

I'm unable to test it myself. The one instance where I noticed a similar problem was on an XP machine, but the GOG version crashes on XP using that DLL.

[hannuff 0]

I hate to necro an old thread, but I found something that may be of use to this issue. I mentioned in earlier posts about the possibility of overriding the GL_CLAMP call. I discovered that something people were recommending to fix K1's grass issues also has the ability to do this.

 

GLOverride - http://www.humus.name/index.php?page=Cool&ID=5

 

If anyone with the black line issue would line to test this, grab the file from the above link, extract to your K1/TSL folder, open opengl32.ini in a text editor and change

FixClamp = 0

to

FixClamp = 1

I'm unable to test it myself. The one instance where I noticed a similar problem was on an XP machine, but the GOG version crashes on XP using that DLL.

 

 

hey, just tested it and it works for kotor 1. carth as well as most retextured heads suffered from the black line. now, in the case of carth and one reskin I tested, it's gone Thank you for your efforts. Would be interesting to make that .dll compatible with the reshade-opengl.32.dll someday in the future.

[DarthParametric 3,782]

No effort on my part. Thank the author, Humus. I'm glad it works though. I have contacted Humus about the possibility of access to the source code, which would allow merging with Reshade, and (more importantly) potential extension to fix other KOTOR problems.

[hannuff 0]

No effort on my part. Thank the author, Humus. I'm glad it works though. I have contacted Humus about the possibility of access to the source code, which would allow merging with Reshade, and (more importantly) potential extension to fix other KOTOR problems.

Yes, so I did. Not sure about it's relevance, but Humu's .dll as well helped me to reduce some "jaggies" on far away skyscrapers of Taris Upper City.

I am using Nvidea Inspector to force some Multisampling (combined with "Sparse Grid" Supersampling). But some edges on far away buildings only use to disappear with pure Supersampling, which costs a lot of performance and turns many  textures blurred.

.Ini-Entry: "ForceAlphaToCoverage" to "1" helped to reduce the edges without notable performance losses or new appearing glitches (yet).