MDLedit bug reporting thread

[DarthParametric 3,790]

There'd be no point using an Edit Normals modifier currently. KOTORMax makes no use of Max's normal data. It only takes the smoothing groups.

[JCarter426 1,216]

It certainly did something - probably because I forgot to reset Xform. But it wasn't that that solved it. I just rotated the pivot point. Such a simple thing, yet such a big problem.

[bead-v 251]

Could I get a test case of such a situation, JC? Maybe I could put out a warning or something...

[JCarter426 1,216]

Before and after attached. Only thing different should be the pivot of the Torso object. Changed its orientation from 180 to 0.

PFBIM-kotormax_v4.mdl.ascii

PFBIM-kotormax_v8.mdl.ascii

[xtprojects 13]

On 7/1/2018 at 3:21 AM, bead-v said:

Thanks, xt!

Nope, haven't looked into that issue yet. Next time!

Here's the xp version:

mdledit_v1.0.6b_xp.zip

Nice! I can do a lot more testing with model conversions for xbox when you get that sorted. Can't wait! And thanks for all that you do beadv!

[DarthParametric 3,790]

I've encountered some odd behaviour with the area tools. When loading K1's STUNT_57 layout it is duplicating most of the room models. It moves the empty duplicates to the correct layout positions and leaves the actual room models at world zero. Here are the relevant files:

STUNT_57 - Rakatan Temple (LS End Scene).7z

[bead-v 251]

Sorry bout that!

kotormax_fix_20180718.zip

[DarthParametric 3,790]

It would be good to get some formal updates for both KMax and MDLEdit on their respective release pages. I can't keep track of all these informal updates.

[bead-v 251]

Yeah, it's planned for mdledit after we finish the new vertex normal implementation. There are actually quite a few new features at this point.

As for kmax, that'll take a little longer, there are some new functionalities I (may) want to implement, but that'll be after I'm done with mdledit.

[JCarter426 1,216]

I don't have a bug to report this time but more of a feature request. I just figured out the solution to a problem that has perplexed me for a while. I know how to fix it, but it's a little time consuming so it would be handy if the fix were built in.

One of the hack ways I edit models is by copying text from one ASCII file to another in Notepad, so I can import meshes from different models weighted to the same set of bones. The most common situation, and what I was doing in this case, is to take hands from a player underwear model to replace the hands of an armor model either to get rid of the gloves or, in this case, to put female hands on a male armor. Editing 3D models in Notepad sounds dumb but I find it easier to edit when it's imported all together and weighted correctly. It works for the most part, though KOTORMax's import script will fail if there's a reference on a mesh node to an object that doesn't exist. A common occurrence is I copy arms from a K2 model onto a model that originally came from K1 and forget about the sleeve bones. KOTORMax understandably freaks out if it's told a skin has a bone that doesn't exist. But in the past, it would give the same error even when I knew everything should check out. And I just realized it's because the import script is case sensitive. So it doesn't know that lhand_g is the same thing as Lhand_g, and so on. The game doesn't seem to care; the cases are inconsistent from model and that doesn't matter. But apparently it does matter on import.

[ndix UR 218]

Definitely a good thing to fix. I recently fixed that in kotorblender for the same reason. Although in Blender, it's easier to just import model 1, save it as a blend file, start new document, import model 2, and use the 'append' function to pull in specific nodes directly from the other blend file. That bypasses the text editor part. Before that I was using a text-based approach, similar to you, then a script that did it (but that was for merging specific nodes into a vanilla ascii model file before the compilers had skills).

[DarthParametric 3,790]

How do internal engine calls to case variants work on *nix systems? I know it fails on external calls like textures and GFF files.

[bead-v 251]

38 minutes ago, JCarter426 said:

And I just realized it's because the import script is case sensitive. So it doesn't know that lhand_g is the same thing as Lhand_g, and so on. The game doesn't seem to care; the cases are inconsistent from model and that doesn't matter. But apparently it does matter on import.

It shouldn't be case sensitive, but apparently I never implemented that globally for kmax. It's on the to-do list. This was also the cause of the issue with the .lyt import DP reported.

[JCarter426 1,216]

Cool. As it is, I'm super happy just knowing what the problem is now. When it failed before I would merge the objects and redo the hand weights manually. Bleh....

[DarthParametric 3,790]

Just export the skin weights and load them back in, manually assigning the unlinked bones? Should take 30 seconds.

[JCarter426 1,216]

I've done that too, still kind of bleh. In some cases it's just been quicker to do it manually by deleting the hand bones from the model and importing it from a project I'd prepared earlier with the hands already there. Usually it's only one row of vertices and they all have the same skin values, so it doesn't make much of a difference. Still bleh no matter which path you choose, though. Would be nice to be able to make bead-v--I mean KOTORMax do it for me instead.

[bead-v 251]

This is intended to be the last beta, if everything checks out I'm uploading it as mdledit v1.1.0. This version has a completely redone vertex normal and tangent space vector calculation algorithm, which also affects smoothing group calculations. Generally, mdledit will calculate the intra-mesh normals correctly, it will calculate those inter-mesh normals where only two vertices overlap correctly, but where more vertices overlap, it's more likely to fail. I can't spend more time on figuring out how to calculate those right now, but there will probably be improvements in the future, just like this was an improvement now. When compiling models there should be no issues however, inter-mesh smoothing really does work now. Some crash issues are also fixed, one that I found myself and one that DP encountered with the K1 endgame area models.

mdledit_v1.0.9b.zip

mdledit_v1.0.9b_xp.zip

[DarthParametric 3,790]

19 hours ago, bead-v said:

inter-mesh smoothing really does work now

Just tested with the Visas head and it does indeed appear to work. Hurrah!

[bead-v 251]

41 minutes ago, DarthParametric said:

Just tested with the Visas head and it does indeed appear to work. Hurrah!

Hallelujah!

[DarthParametric 3,790]

On further examination it seems like the problem still exists, but that it also apparently exists in vanilla models as well:

So I guess it is fixed in the sense of working in the same way as the game does, but the question is can it be truly fixed to work better than the game does with averaged normals along mesh boundaries to eliminate seams altogether?

Edit: Seems like an error on my part? See below.

[JCarter426 1,216]

I took a look at it, just did some haphazard adjustments to make sure the model's different, then fiddled with the smoothing. It's hard to judge from the screenshots, but I think my results with the seam were a little better, though still not perfect:

Looks like it's fine on one side but not the other. There may be some faces or some issues with the vertex positions or weighting that I've overlooked. Since there's no seam at all on the other side of her head, my guess is it's some problem on the model like that rather than MDLEdit's calculations.

Also, unrelated problem, but it amused me:

 

P_VisasH-kotormax_v3.mdl.ascii

[DarthParametric 3,790]

2 hours ago, JCarter426 said:

There may be some faces or some issues with the vertex positions or weighting that I've overlooked.

I'd hazard a guess that it's tied to mirrored UVs. Might need to try a fully unmirrored head and see what happens.

Edit: OK, it seems like this might be an artefact of using GLIntercept? If I turn on solo mode and just run around using the standard game 1st person camera it seems to be smoothing across meshes properly on all sides. But when using the GLI FreeCam you get the weird shading issue. I guess it's related to how it doesn't re-render culled offscreen elements?

Edit 2: Yes, my bad, it was GLIntercept. I didn't realise it previously, but by default it has a lighting adjustment function and that seems to have been screwing the shading up. By setting:

AdjustGLLighting      = False;

in GLIntercept\Plugins\GLFreeCam\config.ini it is disabled and the shading in the game remains working properly. Apologies for besmirching your honour @bead-v.

[ebmar 893]

4 hours ago, DarthParametric said:

By setting:

AdjustGLLighting      = False;

in GLIntercept\Plugins\GLFreeCam\config.ini it is disabled and the shading in the game remains working properly.

Amazing! Can't really say if it's working but I do feel the difference when moving around with the freecam while there are lights emitting, in my case; swords clashes. It is like every angle from the cam had their own depth of light, from what I see. Thank you, for sharing this amazing finding!

[bead-v 251]

6 hours ago, JCarter426 said:

Also, unrelated problem, but it amused me:

 

P_VisasH-kotormax_v3.mdl.ascii

Is that a bug report or just user error that amused you? (fingers crossed)

 

5 hours ago, DarthParametric said:

Apologies for besmirching your honour @bead-v. 

No biggie, I'm just glad it works!

[JCarter426 1,216]

6 hours ago, DarthParametric said:

Yes, my bad, it was GLIntercept. I didn't realise it previously, but by default it has a lighting adjustment function and that seems to have been screwing the shading up. By setting:

AdjustGLLighting      = False;

in GLIntercept\Plugins\GLFreeCam\config.ini it is disabled and the shading in the game remains working properly. Apologies for besmirching your honour @bead-v.

Huh, I didn't realize it affected that. I turned it off because I noticed it did weird things to the lighting on the eyes and teeth. Well, that explains it.

39 minutes ago, bead-v said:

Is that a bug report or just user error that amused you? (fingers crossed)

Not sure yet. That particular model was a failed attempt anyway, so I'm not worried yet. Probably going to put it on hold for a while as it was annoying me.