bead-v

MDLedit bug reporting thread

42 posts in this topic

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.darthparametric.com/files/kotor/misc/K1_Jedi_Captive_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.darthparametric.com/files/kotor/misc/K1_Dant_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?).

Share this post


Link to post
Share on other sites

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]
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. [FIXED]

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. [FIXED]
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. [FIXED]
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 :D I'll look into all of them, it's just that finding time has become tricky for me since I moved.

Edited by bead-v

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I'm slowly trying to make time to look at these things now that my exams are over. I've fixed the issue with model suffix during lyt import, but I haven't had time to look at the selfillumcolor animation problems.

 

1. The VFX issue. [MDLedit issue]

 

Have you figured out anything about what causes it, beyond that it's caused by mdledit?

 

2. The grass and roomlink issue. [KOTORmax issue]

 

Okay, so the way I see it, the problem was that kotormax wasn't importing the trimesh modifier with the aabb node, I must have deemed it unnecessary. So I fixed that now, but I'm not getting the lightmap texture name, because of the way the walkmesh material is set up. I think I may be able to exceptionally save the name with the walkmesh modifier and retrieve it from there when necessary, though this might be problematic for export. Anyway, the fix for this is on the horizon.

 

3. Detonate. [KOTORmax issue]

Since there is not a single detonate controller in either game, I'm considering simply removing it.

 

While I'm at it, I've analyzed all the possible (non-animated) emitter controller combinations in the game. It seems that at all times, all the available controllers were exported to ascii. However, it seems there are different sets, which I assume are the result of the different stages in the development of the tools, because the differences are always in the newer controllers, sometimes even by a single controller. There are two larger orderings, but the following, the newer one, is the commonest in both games (and should therefore probably be followed by our tools):

 

 

 

position orientation fps birthrate m_fRandomBirthRate velocity randvel mass particleRot spread lifeExp xsize ysize colorStart colorMid colorEnd percentStart percentMid percentEnd alphaStart alphaMid alphaEnd sizeStart sizeMid sizeEnd sizeStart_y sizeMid_y sizeEnd_y frameStart frameEnd bounce_co lightningDelay lightningRadius lightningSubDiv lightningScale lightningzigzag targetsize combinetime p2p_bezier2 p2p_bezier3 numcontrolpts controlptradius controlptdelay tangentspread tangentlength drag grav threshold blurlength

 

 

 

 

Share this post


Link to post
Share on other sites

Here is an updated mdledit and some fixes to kotormax.

 

1. The VFX issue

Not tested, but maybe resolved? I will test it when I have time, or somebody else can do it.

 

2. The grass and roomlink issue

Apparently, walkmeshes can also be lightmapped. Since I only have Gmax (which can't render), I can't test what the workflow would be for adding a lightmap to a walkmesh. It is non-trivial because the walkmesh has a multimaterial, while the other meshes have the basic material type. Anyway, for now, when importing a model with a walkmesh, the texture map will be saved on the walkmesh's editable_mesh, a trimesh modifier will be created which saves the 'lightmapped' property (as well as all the others), and the lightmap name is saved on the first material of the multimaterial ('Dirt'). Since the mutlimaterial is only created once per scene, in case you load several walkmeshes into a scene, they will also end up having the same lightmap texture on export. I'm leaving this as is for now, until we figure out what the workflow for adding lightmaps to a walkmesh would be. I can't do this alone, so if anyone is ready to help out, try using Quanon's tutorial to add a lightmap to a walkmesh and then report your findings in this thread.

 

3. Detonate

I have disabled the exporting of 'detonate' from kotormax as a static controller, but I left it in for when it is animated. We have no examples of this in the game, but it should be tested at some point.

 

4. Emitter, Light and Mesh animation controllers missing

 

Apparently I changed the way animated controllers are handled at some point and forgot to change some other code accordingly, so while reading an ascii, mdledit would ignore any controller except for position, orientation and scale. Fixed now.

 

+ also fixed a crash issue with mdledit I encountered that hadn't been reported.

DISCLAIMER: These files have not been tested and may be unstable. After they have been tested, they will be uploaded to the download pages. Unless you want to help with testing, you should wait for the new versions to be released there.

[there is a newer test version of mdledit further down]

kotormax_scripts.zip

Edited by bead-v

Share this post


Link to post
Share on other sites

until we figure out what the workflow for adding lightmaps to a walkmesh would be

There's nothing inherently special about a walkmesh that makes it different for lightmapping compared to any other mesh, at least as far as Max is concerned. Give it a set of lightmap UVs on channel 2, bake the shadow maps as you would for any other mesh.

 

Perhaps you could have KOTORMax export a dummy version of the mesh with the lightmap UV and texture data (perhaps even as a separate file, like you have for PWK/WOK), then merge it in MDLEdit? Assuming that solves anything.

 

I only have Gmax

If you have a university email address, you can get an educational version of Max for free - https://www.autodesk.com/education/free-software/3ds-max

Share this post


Link to post
Share on other sites

There's nothing inherently special about a walkmesh that makes it different for lightmapping compared to any other mesh, at least as far as Max is concerned.

 

There is: the material. With a regular mesh you do mesh.material and you get a material that you can add a diffuse or ambient texture to. You can't do mesh.material and then add diffuse or ambient info on a walkmesh, because it's a multimaterial, which does not accept diffuse or ambient info. It's just a collection of regular materials. So what I can do in kmax, is add the diffuse or ambient info onto the first regular material in the bundle. What I don't know is if the lightmapping workflow can do the same, or if it causes any problems. Somebody needs to try it before we can move on.

 

The problem is just with the texture name. The tvert coordinates as well as the trimesh properties are handled perfectly.

 

As for getting 3dsmax, I know I can. I use gmax because it's more light-weight, and because it's easier to keep kmax compatible with gmax if I use gmax myself. I'm in a serious lack of time, so even if I decided to install it now it would take forever for me to test this.

Share this post


Link to post
Share on other sites

If you are baking a custom layout, then you are unlikely to be doing so with any modifiers in the stack (especially if you are following Quanon's routine). In which case the eventual walkmesh would be just like any other mesh. The question is what happens when you dump a walkmesh modifier on it, which should be easy enough to test with any pre-existing lightmapped mesh. No need to bake one from scratch.

Share this post


Link to post
Share on other sites

If you are baking a custom layout, then you are unlikely to be doing so with any modifiers in the stack (especially if you are following Quanon's routine). In which case the eventual walkmesh would be just like any other mesh. The question is what happens when you dump a walkmesh modifier on it, which should be easy enough to test with any pre-existing lightmapped mesh. No need to bake one from scratch.

That's what I needed to hear! Thanks, DP! :) Okay, so I can rewrite the walkmesh modifier to take the data from the previous material before replacing it with a walk material and store the data somewhere in it.

 

I think that covers all the possiblities. Or is there any other reason why max would need the information about the lightmap texture after the walkmesh modifier is applied?

 

 

Share this post


Link to post
Share on other sites

Not that I can recall seeing firsthand, but I can't really claim to have exhaustive knowledge of level-related stuff, it has never been my thing (at least in regards to KOTOR modding).

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

This is the newest test version of mdledit.

 

In this version, the order of the nodes in the ascii will no longer cause problems with skins if it results in an order that is different from the name order in the binary.

 

[Attachment removed – there's a newer test version of mdledit available below]

Edited by bead-v
  • Like 1

Share this post


Link to post
Share on other sites

bead-v, I think it will be very usefull to be able to run mdledit from command line with some arguments like "--sourceFolder "D:/kotorExtracted/mdl/*.mdl" --convertFromBin2Ascii --skipErrors" and it will convert all mdl files in folder automatically. In this case it will be easier to write some helper scripts and not manually do the job

Share this post


Link to post
Share on other sites

bead-v, I think it will be very usefull to be able to run mdledit from command line with some arguments like "--sourceFolder "D:/kotorExtracted/mdl/*.mdl" --convertFromBin2Ascii --skipErrors" and it will convert all mdl files in folder automatically. In this case it will be easier to write some helper scripts and not manually do the job

Thanks for the suggestion. My default answer to this used to be: use mdlops, it's had that since the beginning. But considering it's not that hard to implement, I've recently been thinking about doing it anyway. We'll see, but your suggestion is noted!

Share this post


Link to post
Share on other sites
Posted (edited)

Turns out it would be complicated to have a single .exe function both as a GUI and a CLI app. So for now, the answer is the same: use MDLOps.

 

I've been working on mdledit a little, and I've added a hierarchical view of the geometry. You can toggle between the 'linear' and 'hierarchical' views from the View menu while the model is loaded. The hierarchical view shows less information, but it is easier to quickly get an overview of the structure of the model. I've also added options Expand/Collapse All, which make navigating the tree easier. Check out the attached version.

 

Any comments or suggestions are welcome!

 

[Newer test version of mdledit available below]

Edited by bead-v
  • Like 1

Share this post


Link to post
Share on other sites

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.darthparametric.com/files/kotor/misc/K1_Jedi_Captive_Placeable.7z

 

I finally managed to test this, and I do not get the same results with the latest version. Specifically, no flying into space. I do get the VFX doing small loops on both hands though, that's because of quaternion compression. We'll have to look at the compression and decompression algorithms again to fix this.

mdledit-v1.0.4b.zip

Share this post


Link to post
Share on other sites

Ah, quaternion compression. I started disabling that as a matter of course early on after various levels of screwiness. I'm curious as to why the feature seems so randomly implemented on vanilla models though. You'd think they'd all use it (I assume there must be a memory advantage on an Xbox), or why bother having the feature in the first place?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now