DarthParametric

Is it actually running on the Geforce GPU? I've heard of people unknowingly running on the integrated GPU.

I would recommend getting your head around how the Max/GMax KOTOR I/O script, NWMax, works. You can import an existing model and skin to that rig. I'm guessing your first issue is going to be aligning your body to the rig if you didn't use an existing KOTOR body as a basis. You'll also want to look into how KOTOR deals with body models. You are highly restricted because the game sets a single model per armour class, and can only use texture variants for that class. So, for example, if you wanted to use your model as Master Robes, then all other Master Robe variants would use the same model, and expect a specific numbered texture variant thereof (only for Visas though, if that's who you are assigning it to). The only way to get around the limitation for unique models is to go the disguise route (in the same vein as the space suit, Sith trooper armour, etc.), but that has issues of its own.

Never underestimate the peanut gallery's ability to complain...

It is certainly possible, but in practice it would be an absolute bastard to align if you are talking about something conforming to the buttons. I did consider it, but I would expect a lot of iteration would be required to get it right.

Unfortunately I don't know what else I can offer. I'm running the game here on Win 10 on a 120Hz monitor and don't have any of the issues you do.

You can use [spoiler] [/spoiler]Substance can bake out your normal, AO, etc., but only if you have a high poly source for it to generate from. If you are not sculpting in ZBrush or the like, you may be stuck with more rudimentary solutions. I would suggest you not get too caught up in super-fine details. They probably won't show up very well in the game. It's probably worth doing some in-game sample tests first.

The problem is you can't change GUI elements on a per-menu basis. It's universal and entirely separate from the menu models.

The [Graphics Options] section of swkotor.ini for me is FullScreen=1 AllowWindowedMode=0 RefreshRate=60 Width=1920 Height=1080

If you have used UniWS to patch the exe then you should just need to set the matching resolution in the ini file.

You don't need to touch the refresh rate of the monitor. The game's profile in the driver should cap the game to 60fps when enabling vsync anyway, but if need be you can always manually set the frame rate cap. That has nothing to do with widescreen though.

This is just a quick and dirty hack to test the principle, but extract this into your Override and see what difference it makes (I don't have an appropriate save to test it with). https://www.darthparametric.com/files/kotor/tsl/[TSL]_261TELD_Polar_Plateau.7z

Texturing has been sub-contracted out. Updates will be posted when it's done.

If you are using Substance Painter, there should be minimal need for Photoshop aside from final texture collation and the odd touch-up. I not sure why you'd be using Illustrator either way, it's not typically used for this sort of thing (and the end result will have to be rasterised anyway). While the game can use normal maps, its implementation is fairly basic, and the tools to create a functional normal map the game will accept are not yet publicly available. However, even if you are not doing a high poly bake, you'll want at least a normal map for Substance Painter to work with anyway, so I would proceed along that path. Seeing as Substance is intended for PBR, you'll also want an AO map that you can overlay on the final albedo. That may also be where you need to add a bit of manual touch-up in PS. In order to export your model in a format that can be compiled, you'll need to use one of the export scripts in either Max/GMax or Blender. I'm not sure what the current state of the Blender script is. The problem with trying to skin it in Maya is that KOTOR doesn't use a modern bone system, it uses meshes as bones. As such, if you can deal with Max then your best bet would be to skin directly to the rig in there, rather than try and deal with moving between programs.

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.

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.

You can't directly use K1 models in TSL, they are different. Bastila and Carth work because they exist in TSL's data. Also porting between the games is a taboo subject. Talking about it will summon the wrath of the moderators/admins. You should read the sticky thread - http://deadlystream.com/forum/topic/2970-porting-please-read-here-before-posting/

An alternative thing to try might be adding this to the texture's TXI: clamp 1Without ndix UR's lines of course.

There should be no insurmountable problems. You don't need to limit yourself to a measly 500 polys. The only thing the engine really freaks out over is shadow casting meshes above around ~1,000 tris. Typically you just use the skeleton as the shadow caster, so that's usually a non-issue for characters. But if you have something like a dress, you may want to make a low poly shadow caster as well (doesn't get rendered). The other thing to note is that the game does not seem to like single mesh bodies very much, so after you have your skinning finalised you'll want to split off the arms as separate meshes, so it's useful to plan for that ahead of time regarding things like UV seams. On the subject of skinning, you are restricted to only four weights per vert. If you are using Max you can set that limit in the Skin modifier. The primary issue you'll likely come up against is that the current publicly available model compiling tools are somewhat flawed. There are some new ones on the horizon that resolve pretty much all the problems though. Edit: Oh, and a note on smoothing. The game requires models have the number of texture verts equalling the number of geometry verts. The current public version of MDLOps doesn't handle this very elegantly, so you are likely going to want to manually detach all your UV islands to sub-meshes (or find a script to do it). This is going to give you a hard seam along your UV boundaries, so again, plan your UV layout accordingly.

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

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.

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

A 120Hz laptop? I am guessing that doesn't just use an integrated GPU. What does it have? Widescreen won't work without patching the EXE. The Steam version can't be patched because the EXE is protected by DRM.

It's not a super practical fix, especially if you are experiencing it on multiple different models. It completely remaps the head to remove the mirrored UVs of the original, so there is no longer a seam down the middle of the face. Possibly a less radical approach could be taken, experimenting with adjusting the vanilla UVs rather than replacing them altogether.