Jump to content


Photo

MDLedit bug reporting thread


  • Please log in to reply
28 replies to this topic

#21 bead-v

bead-v

    Evil Malachor Overlord

  • Premium Member
  • 380 posts
  • LocationSlovenia

Posted 29 October 2017 - 06:50 PM

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 by bead-v, 29 October 2017 - 06:51 PM.


#22 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 30 October 2017 - 06:48 AM

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:

MDLEdit_PMHC04_Test_01_TH.jpg

Attached File  01_PMHC04_Edit_Initial_Compile.7z   58.64KB   1 downloads

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

MDLEdit_PMHC04_Test_02_TH.jpg

Attached File  02_PMHC04_Edit_Decompile-Recompile.7z   58.58KB   1 downloads

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.

Attached File  03_PMHC04_Edit_0.5.0_Decompile-Recompile.7z   58.75KB   0 downloads

#23 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 02 November 2017 - 06:10 AM

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.

#24 bead-v

bead-v

    Evil Malachor Overlord

  • Premium Member
  • 380 posts
  • LocationSlovenia

Posted 02 November 2017 - 08:21 PM

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  :wallbash: 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.



#25 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 09 December 2017 - 04:49 PM

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.

hcLJxaH.gif

#26 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 25 December 2017 - 07:39 PM

I've struck an issue with the Star Forge Jedi captive placeables I have been working on. I tried just recompiling the vanilla version to see if that worked, but it has the same issue as well, so presumably this is something caused by either MDLEdit or KOTORMax. Specifically, one of the VFX nodes appears to fly off into space at the end of the animation. Here's the recompiled vanilla placeable in-game:



You can see the VFX around the left wrist is working as intended, but the one on the right wrist goes walkabout.

And here is the MDLEdit decompile of the vanilla binary, along with my imported and exported from KOTORMax version of the same model (untouched except to rename the base):

https://www.darthpar...ve_Placeable.7z

While I'm posting issues, I've struck two crash bugs in KOTORMax. One is when loading models via a layout file. The other is when loading a model with an ASCII walkmesh. I'll see about getting some more specific details for those when I get the chance.

Edit: Pics of the walkmesh crash

KOTORMax_Walkmesh_Import_Error_TH.jpg

Edit 2: I realise now the level model crash is (again) user-error. The same thing I did during beta testing. Mind like a sieve. The correct suffix filter should be "-mdledit" for decompiled ASCIIs exported by MDLEdit. Maybe you need to put a mouseover hint or something on that, or at least get it to ignore someone putting in ".mdl.ascii".

Edit 3: Got another issue. Trying to edit the K1 Dantooine Jedi Enclave level models is causing the grass meshes to go crazy. Video:



And here are some model samples. This is just a straight decompile, import/export via KOTORMax, recompile. Nothing touched. Didn't bother putting everything in dummies. Tried that previously but the same thing happened.

https://www.darthpar...nt_m13aa_01a.7z

Edit 4: Another thing to add to your to-do list. KOTORMax is (again? stll?) exporting VFX nodes with the Detonate 0 line, which causes crashes on XP (and I think maybe Mac as well?).

#27 bead-v

bead-v

    Evil Malachor Overlord

  • Premium Member
  • 380 posts
  • LocationSlovenia

Posted 30 December 2017 - 12:58 PM

Issue 1: The flying VFX.
From the video, it looks like it could be some rotation problem (again). But I really hope not. *sigh* I'll look at the files when I find the time.

Issue 2: Walkmesh crash.
Fixed. Let me know if you want the script immediately. Otherwise, you'll get it with the general kmax update with all these fixes.

Issue 3: Layout model import.

KotorMax should be disregarding any .ascii and .mdl extensions in the suffix field. I still need to look into why that causes a crash. So you just put in ".mdl.ascii"?

Issue 4: Crazy grass.
Wow :lol: Have you also tried to recompile it without going through kmax? If so, did that produce the same issue? Just from the video I have no idea about what might be causing this.

 

Issue 5: Detonate.
I've known about this for a long time, but I've been holding off on it because we need to check how the emitter controllers work. Not all controllers are always present, so I need to check all the possible combinations and see if there's some logic to it. It's just that I may need a more general solution than adding a checkbox for detonate (and possibly other emitter controllers that cause trouble).

Thanks for the error report :) I'll look into all of them, it's just that finding time has become tricky for me since I moved.



#28 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 30 December 2017 - 01:19 PM

Let me know if you want the script immediately.


No rush. I can live without it for now.

So you just put in ".mdl.ascii"?


Yep.

Have you also tried to recompile it without going through kmax? If so, did that produce the same issue?


Just tried now. No, it does not do the same. The grass is normal and where it is supposed to be.
 

I may need a more general solution than adding a checkbox for detonate (and possibly other emitter controllers that cause trouble).


That works for me if it's easy to implement. It should also serve to remind me about it.

#29 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 1,316 posts
  • LocationOz

Posted 14 January 2018 - 10:21 AM

I can't recall if I already passed this on in a PM or if it was something that only came up separately in discussions with ndix UR, so I am posting it here so it is on the record. The grass issue above is caused by the walkmesh exported by KOTORMax lacking all trimesh data. I've just struck another issue with the same root cause, but a different outcome. In a custom walkmesh for a room in TSL, I could not get the game to recognise the room link, preventing me from entering the room. However, when I changed the node in the ASCII from
  node aabb walkDP
  parent XYZ
  position -74.0866 51.3138 9.05
  orientation 1.0 0.0 0.0 0.0
  bitmap NULL
  verts 39
to
  node aabb walkDP
  parent XYZ
  position -74.0866 51.3138 9.05
  orientation 1.0 0.0 0.0 0.0
  diffuse 0.8 0.8 0.8
  ambient 0.2 0.2 0.2
  transparencyhint 0
  animateuv 0
  uvdirectionx 0.0
  uvdirectiony 0.0
  uvjitter 0.0
  uvjitterspeed 0.0
  lightmapped 0
  rotatetexture 0
  m_bIsBackgroundGeometry 0
  shadow 0
  beaming 0
  render 0
  dirt_enabled 0
  dirt_texture 1
  dirt_worldspace 1
  hologram_donotdraw 0
  tangentspace 0
  bitmap NULL
  verts 39
it worked as intended. These values were taken from the original walkmesh in the vanilla model. I guess AABB objects need the addition of a trimesh modifer in KOTORMax?

Edit: To clarify, these changes are only in the MDL ASCII, not the WOK ASCII.

New problems I have encountered:

I had MDLEdit failing to properly preserve room animations. An example is the Ebon Hawk cockpit. When I was working on the escape from Taris mod, I noticed my custom edit of the room model no longer had animations for the flashing lights and screens. I tried directly copying the animation data from the vanilla ASCII model to rule out KOTORMax, but there was no difference. I needed to use MDLOps to get the animations working. M12aa_01p was the specific model, and the animations were all selfillumcolorkey data. I've had MDLEdit work with other room animations, so I don't know if that was just a specific problem with that model. However, it could be related to the next problem.

When I was playing around with the escape pod room in the Harbinger level, plugging a gap in the geometry, I found that if I changed the hierarchy in any way, I'd get blown-out lighting, like so:

Room_Model_Lighting_Woes_Continued_TH.jp

Going back to the original hierarchy and just adding my meshes to the end, the lighting returned to the same as the vanilla model. This was in direct contrast to other room model edits I have done previously, where if you don't put everything inside dummy objects, and typically put any new objects at the top of the hierarchy, then your additions don't even show up. For example, all the issues Kexikus was having with the Ravager. In addition, I also had the room animation issue with this model, where MDLEdit did not preserver the flashing orange light animations. This model is 151HAR09, the animations again only selfillumcolorkey.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users