MDLedit bug reporting thread

[DarthParametric 3,784]

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

 

 

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?).

[bead-v 251]

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

Edited February 18, 2018 by bead-v

[DarthParametric 3,784]

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.

[DarthParametric 3,784]

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:

 

 

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.

[bead-v 251]

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

 

 

 

 

[bead-v 251]

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 April 30, 2018 by bead-v

[DarthParametric 3,784]

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

[bead-v 251]

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.

[DarthParametric 3,784]

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.

[bead-v 251]

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?

 

 

[DarthParametric 3,784]

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).

[bead-v 251]

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 May 9, 2018 by bead-v

[Otaka 1]

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

[bead-v 251]

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!

[bead-v 251]

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 May 12, 2018 by bead-v

[bead-v 251]

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

[DarthParametric 3,784]

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?

[JCarter426 1,215]

I have a couple oddities to report. I'm not sure if MDLEdit is responsible or if it's just KOTOR being garbage, but I've tried everything I can think of on my end.

The first issue is that the cube maps on my model seems to be applied inconsistently. From one angle it's ok, but from others it looks like different faces are getting different parts of the map, resulting in odd seams. I've checked the model to make sure the UVW mapping is ok and there's no Z-fighting or anything obvious, no extra vertices to weld. I was pretty careful about that when I made the object and I'm still not seeing any problem after double checking.

The second issue is more of a problem, though. I'm working with animated transparency and the animation is bugging out. There are the standard four placeable animations: close2open, open, open2close, and close, and I also threw in default to be safe. The mesh is meant to be 0% visible in the closed state and 100% visible when open, with transitions for the others. But for the open state, rather than staying on the mesh flickers on and off. I've redone the animations from scratch twice now, first to make sure the initial key was set correctly, and the second time to add default and change the order to match one of the other placeables in the game, just to be safe. But same result. And both the binary and ASCII models look fine - the open animation is 3 seconds long and at each end the alpha value is 1.0. The only other thing I can think of is that it's playing open2close instead of open, but I can't imagine why it would be doing that.

Both issues can be seen in the video below. Binary and ASCII also attached.

 

Holocron Troubles.zip

[DarthParametric 3,784]

I'd say you have some model issues there. 40K polys seems a tad excessive. I'm not sure exactly what is going on, but decompiling the binary gives an ASCII of 6.6MB vs 2.5MB for the original. The poly/vert/edge counts seem to be the same, so maybe it is blowing out tex vert number or something. The new ASCII is 215K lines vs 75K for the original.

 

Your keys are bezier, which may be the source of the animation problem. Try converting them to linear before exporting. I thought @bead-v had added some toggle or global switch for that after I complained about it.

 

Edit: Ah, there's a toggle in MDLEdit. In the settings, convert bezier controllers to linear.

[JCarter426 1,215]

36 minutes ago, DarthParametric said:

@bead-vI'd say you have some model issues there. 40K polys seems a tad excessive. I'm not sure exactly what is going on, but decompiling the binary gives an ASCII of 6.6MB vs 2.5MB for the original. The poly/vert/edge counts seem to be the same, so maybe it is blowing out tex vert number or something. The new ASCII is 215K lines vs 75K for the original.

Damn. I'm only using this for a short video, not intended for release, so I wasn't concerned about that. It must be because I used 30- and 60-sided circles for the rings. Bah. I suppose the only way to confirm is to remodel it. KOTOR being garbage confirmed.

36 minutes ago, DarthParametric said:

Your keys are bezier, which may be the source of the animation problem. Try converting them to linear before exporting. I thought @bead-v had added some toggle or global switch for that after I complained about it.

 

Edit: Ah, there's a toggle in MDLEdit. In the settings, convert bezier controllers to linear.

Ah. Last time I worked with animations was before bezier controllers were a thing. No luck with MDLEdit, but I found them in the curve editor and that did the trick. Thanks.

[DarthParametric 3,784]

Make sure you are using the 1.0.4 beta version from a few posts up. I'm not sure if it is in older versions.

[JCarter426 1,215]

Oh, yeah, I am. I was actually having other problems with it before and then came here and saw you and bead-v had sorted that part out already and realized I was out of date. But for this, I meant I did click that and recompile it didn't seem to help. But problem solved either way. Plus, so long as it behaves, I can control which keys are bezier and which are linear in the curve editor.

[DarthParametric 3,784]

Ah, well I guess that is another bug for bead-v to fix in his spare time then. Although I thought there was also something added to KOTORMax to deal with it as well.

[ndix UR 218]

The problem I see in your model is that you've animated the 'open' animation, so everything is functioning exactly as it should. Usually, like if you look at plc_footlker for example, open is not really animated, because it is representing the 'open' state (not an opening animation, that is close2open). In your case, you just want to have alpha 0 => 1 in open2close, alpha 1 => 0 in close2open, and alpha 0 => 0 in open, and alpha 1 => 1 in close.

[JCarter426 1,215]

1 hour ago, ndix UR said:

The problem I see in your model is that you've animated the 'open' animation, so everything is functioning exactly as it should.

It's because the light is going to be animated while the holocron is on. I hadn't added it on the model I uploaded, but it seems to be behaving with linear keys now. You're right that most models only have a single key for the open and closed states, but there's no reason they have to be like that. There are some doors that are set up like this already.