MDLedit bug reporting thread

[bead-v 251]

This thread is for reporting any bugs you encounter while using MDLedit.

 

If you encounter a bug, then before you do anything else, try to reproduce it. If you manage to reproduce it, describe what you did that caused the bug, in steps. If there was an error message please post a screenshot or copy the text. If the bug didn't crash MDLedit you can also check MDLedit's report for any warning or error messages. Please also include in your post the file(s) that you were processing.

Open issues:

• There is a problem with the tangent space vectors on UV boundaries when the UVs are in the opposite direction as the model. Needs further research to understand what exactly is wrong and how to fix it.
• Currently, double-clicking on data won't throw you into the corresponding tree item anymore. Need to figure out how to reenable that.

[bead-v 251]

Lightsabers that go through KotORMax/MDLEdit seem to end up like this:

 

 

Fortunately this seems to resolve the issue I had with my crossguard lightsabers being extended all the time, just looks like a little UV mixup.

 

This is the unchanged default blue lightsaber, simply brought into ASCII by MDLEdit, into KotORMax, exported back out of KotORMax, and then back into binary by MDLEdit.

Fixed in the new version of MDLedit

[Sithspecter 909]

Fixed in the new version of MDLedit

 

Amazing news! Now I can fix my crossguard lightsaber bug!

[LiliArch 115]

I was running some tests, and it appears that there is still ("still", since it's been haunting me in MDLOps as well) this bizarre issue regarding certain head models (at least in TSL, haven't tested in KotOR - call me lazy if you will) that I wish someone would be able to fix. Now I don't claim to understand what is happening under the hood, but the way the symptoms appear to me is that in certain cases, something in bonemapping goes horribly wrong when decompiling and/or recompiling (can't tell which one, since I still don't understand weighting in 3D programs, ahem) - based on my tests, that happens if the "head" node (I assume it's the same for "tongue" as well, but it's hard to see the tongue when head goes haywire) is not a direct child of the root node (the [modelname]). Take n_dockof (the Peragus dock officer) for example: decompiling and recompiling the head model makes him move his eyebrows instead of lips while speaking, in addition to other weird ticks in facial animations.

 

I can keep experimenting on this if you wish. If you're not interested in the issue the slightest, please let me know, so that I won't bother you with it.

 

As a related note, I was attempting to modify "qbones" values of the recompiled model's "head" node via the "Edit values" feature to see whether that has any effect in the issue or not; trying to save the modified values gave me Visual C++ Runtime Library error "This application has requested the Runtime to terminate it in an unusual way", leading to MDLEdit crashing. Attached in the file, the compiled model and screenshots for what I did and the error message itself.

 

mdledit-testing.7z

 

I hope my text makes any sense. It's been a while since I've written on any forum.

[bead-v 251]

I hope my text makes any sense. It's been a while since I've written on any forum.

It's awesome, tells me exactly what I need to look at I'll have time to look at it later today.

[DarthParametric 3,782]

A problem with vert ID perhaps? Are they changing when recalculating smoothing? MDLEdit says that the head mesh has 501 verts/749 tris in the binary model, but Max says the ASCII model has 502 verts/750 tris.

[ndix UR 218]

I was running some tests, and it appears that there is still ("still", since it's been haunting me in MDLOps as well) this bizarre issue regarding certain head models (at least in TSL, haven't tested in KotOR - call me lazy if you will) that I wish someone would be able to fix.

 

 

TLDR: the problem is understood and a fix is in the works.

 

Thanks for the report, this was a fun problem. Skin mesh has a few structures that are equal in size to the number of nodes. Q & TBones for example. Past implementations have assumed that those nodes would be in 'name array order', the order you get by following the 'node number' read straight out of the node header. It turns out though, that those structures are in 'actual node order', which is the order you get via depth-first traversal. Most of the time, those two orderings are the same, but not always apparently. For whatever reason (my guess is something reordered the nodes in the presence of transparencyhint nodes), the models like N_DockOf have name orders that are very different from node order. The mismatch causes all the weights to to be decoded into the ASCII file with very wrong node names. The recompile operation actually works fine if you have a valid weights list (it just reorders the names list to match node order in the compiled output model).

[LiliArch 115]

Sounds like fun to isolate, indeed.
 

The recompile operation actually works fine if you have a valid weights list (it just reorders the names list to match node order in the compiled output model).

So it's in decompiling, then. Thanks for clarifying that. I was unable to verify which one it was - granted, I didn't run my full scale of tests either, the results of those tests when I run them last time (with mdlops 0.6 I guess?) were so horrifying that I almost started to believe the whole model was haunted.

 

Anyway, a minor documentation issue if I may, now that I remember. The "Head Link" button could use some explanation in "Help" section. It isn't exactly self-explanatory.

[bead-v 251]

LiliArch, all the issues you mentioned have been resolved. If anything else comes loose, let me know here. I won't be able to do anything before next thursday, however.

[Otaka 1]

 

bead-v, can you share with the source code of this excelent application? I am very interested in animation parsing

 

[ndix UR 218]

bead-v, can you share with the source code of this excelent application? I am very interested in animation parsing

 

https://bitbucket.org/bead-v/mdledit

[bead-v 251]

The link to the source is in the Readme.

[Otaka 1]

did not noticed. Thank you so much

[LiliArch 115]

Dear sirs, you are awesome.

[Otaka 1]

I think I have found a bug.

1. Open file "dor_lda01.mdl" (model from KOTOR 1).

2. In settings set Convert Bezier Controllers to Linear.

3. Try to save the model as ASCII.

 

It throws several error messages:

---------------------------
Error!
---------------------------
Missing controller data on animation controller 'position' on node 'Mesh01' in animation 'opening1'.
vector::_M_range_check: __n (which is 41) >= this->size() (which is 30)

In result file I see missing values.

Example:

 node dummy Box04
      parent DOR_LDA01
      positionkey
        0.0 -1.94879 0.0967285 0.0
        1.46667 -0.0419167 0.0967285 0.0400847
        2.0                  <-----------MISSING
      endlist

[Otaka 1]

And can you please explain how do you make conversion from bezier to linear(mathematic expression, or at least point me where in source code you do the conversion)?

 

Example of bezierposition controller:

node dummy Box04
parent DOR_LDA01
positionbezierkey
0.0 -1.94879 0.0967285 0.0 0.0 0.0 0.0 1.23964 0.0 0.0
1.46667 -0.08933 0.0967285 0.0 -1.23964 0.0 0.0 0.0316088 0.0 0.0
2.0 -0.0419167 0.0967285 0.0 0.0400847 0.0 0.0 0.0 0.0 0.0
endlist
endnode

The same controller linearized(with errors):

node dummy Box04
parent DOR_LDA01
positionkey
0.0 -1.94879 0.0967285 0.0
1.46667 -0.0419167 0.0967285 0.0400847
2.0
endlist
endnode

[bead-v 251]

Thanks for reporting this. The issue has been resolved and I will upload the new version of MDLedit when I find the time.

 

And can you please explain how do you make conversion from bezier to linear(mathematic expression, or at least point me where in source code you do the conversion)?

 

You just keep the point data and throw away the control point data. In the case of position, that means you just keep the first three values.

Edited October 29, 2017 by bead-v

[DarthParametric 3,782]

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet). On trying the old decompile/recompile trick, skin weights are being assigned random non-bone objects much like the issue with vanilla models above, like so:

 

[bead-v 251]

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet). On trying the old decompile/recompile trick, skin weights are being assigned random non-bone objects much like the issue with vanilla models above, like so:

 

 

What model is that?

[DarthParametric 3,782]

PMHC04 from TSL, but the vanilla model is fine. The problem is with a modified version of it, as described.

[bead-v 251]

PMHC04 from TSL, but the vanilla model is fine. The problem is with a modified version of it, as described.

 

I need to reproduce the problem to be able to do anything about it.

 

It seems like edited models with differing numbers of verts and texture verts may be causing the game to randomly crash (not 100% certain as yet).

 

There is an algorithm when an ascii model is loaded that combines the vert, color and all the tvert arrays into a single MDL vert array. If for example the algorithm finds two tverts sharing the same vert, then the MDL vert array will contain two verts as well as two tverts, ie. the shared vert gets split into two. This holds for all the arrays. In addition to that, smoothing also affects the algorithm. If there is supposed to be no smoothing between two faces sharing a vert, the algorithm will split that vert as well. Any stray vertices are deleted, and the option 'Minimize verts' will further reduce the number of MDL verts to the minimum necessary while still preserving all the data.

 

Mismatches in vert and tverts counts are therefore expected, and tell me very little about what might be wrong.

Edited October 29, 2017 by bead-v

[DarthParametric 3,782]

OK so upon further testing, it appears that I am suffering from a random crash on loading character creation that is unrelated to this issue, as I can induce it independently. So scratch that off the list.

 

Additionally, I have also established that the problem is unrelated to UV changes/vert count. Basically the changes you introduced to fix the skin weight/node assignment issues in certain vanilla models now appears to cause that very same problem to occur in other models. To expound, take a vanilla model and simply decompile it, then recompile it. It should work fine, like so:

 

 

01_PMHC04_Edit_Initial_Compile.7z

 

But if you take that 2nd generation binary model, decompile it and recompile it, you get something like this:

 

 

02_PMHC04_Edit_Decompile-Recompile.7z

 

If you look at the ASCII of the 2nd one, you'll see the skin weights assigned to wrong nodes issue, as I showed in my previous post.

 

If, however, you decompile and recompile the 2nd generation binary model with one of the older builds of MDLEdit like v0.5.0, you do not get this issue. Skin weights remain intact on subsequent decompiles/recompiles.

 

03_PMHC04_Edit_0.5.0_Decompile-Recompile.7z

[DarthParametric 3,782]

There appears to be a case sensitive issue where MDLEdit will not recognise the name of a node with differing case from the first instance, as per this example.

[bead-v 251]

Both problems are fixed, the new version will be available soon. Sorry it took a while!

 

OK so upon further testing, it appears that I am suffering from a random crash on loading character creation that is unrelated to this issue, as I can induce it independently. So scratch that off the list.

Additionally, I have also established that the problem is unrelated to UV changes/vert count. Basically the changes you introduced to fix the skin weight/node assignment issues in certain vanilla models now appears to cause that very same problem to occur in other models.

 

This one caused a lot of  because its source was some code that I could have sworn I removed. Things weren't making any sense and I really had to do step-by-step debugging to find the issue. Bleh.

 

 

There appears to be a case sensitive issue where MDLEdit will not recognise the name of a node with differing case from the first instance, as per this example.

I glanced at that thread but missed your post somehow, thanks for reporting it here. The checks are now case-insensitive and the model loads properly.

[DarthParametric 3,782]

I'm not sure if this is a bug, or user-error. I tweaked the astromech animations to suit my model: clean up some clipping, add in a probe arm door, and animate the rear wheel. Testing it in game it seems like certain animations are stuck on their last frame when finished, rather than returning to the default. For example, using security to open a cylinder, when complete the probe arm will remain extended rather than retracting. Similarly, after combat the gun will remain popped up rather than returning to flush with the head. Do any potential causes spring to mind? A casual comparison of the animation section of the ASCIIs for my model and the vanilla don't reveal anything obvious.

 

Edit: If I load the vanilla animations back onto my model, they seem to function correctly. So presumably that means some error on my part.

 

Edit 2: OK, disregard. Seems like a couple of animations have bad keys at the end, causing the poses to blend into the subsequent animation. Entirely user-error.

 

Edit 3: Maybe not. Comparing the animations in question to the original again, they actually seem the same. I did notice that my model had the "compress quaternions" option turned off, unlike the vanilla model, but when I enabled that and recompiled, that seemed to screw up the animations even more, seemingly reversing things. For example, unlocking a crate, rather than rocking back and extending the probe downwards, with compressed quats he leans forwards and the probe points up in the air (like he is giving the finger - must be going through a rebellious phase). The end result is still the same, with the probe remaining extended after the animation finishes, it's just rotated 180 degrees now.

 

Edit 4: Reloading a fresh version of just that one container unlocking animation from the vanilla model and adding in some extra keyframes for the probe door, it still results in the probe arm hanging out at the end. It's kind of like that saber animation issue where the blade stays extended.

 

Edit 5: OK, the problem was user-error indeed. It seems the problem was missing keys for the default state for certain parts. So presumably the model had no return state for things like the probe arm, so it just got stuck in the last used pose until it was repositioned by another animation. Adding some keys for neutral states to the other animations appears to have sorted the problem. I guess there is nothing more to see here.