DarthParametric 3,785 Posted September 4, 2018 So going back to the bone limit issue, it definitely seems like in K1 at least that 18 or more bones on a mesh is not possible. I am testing a full body model and I had split apart the head/torso/arm meshes to sidestep the bone limit but I didn't pay close attention and had some stray weights on the head and split the arms off one ring of verts too low. That meant the torso ended up with weights for the two lower biceps for a total count of 17 bones. Interestingly I noticed no problems with this mesh. However, the head had stray weights from both collar bones, resulting in 18 bones. This caused the previously described verts stretching to the model base's 0,0,0 (appeared to be verts weighted to the right brow). I went back and had a look at the vanilla Holo Vandar (C_HoloVandar) and Revan (N_DarthRevan) models, as I had previously reported that those both had meshes with more than 16 bones and yet worked fine. Vandar's head mesh has 17 bones and Revan's torso mesh has 17 bones. So it seems to me the bone limit is 17, not 16, but that is definitely the upper limit. On a different note, I noticed when loading a binary model into MDLEdit that the bones listed for a given mesh were wrong. It looked like that old index issue where it was being wrongly assigned things like dummies (camerahook, etc.) and other skinned meshes. This appears to only be a cosmetic issue inside MDLEdit however, as decompiling the model resulted in the same mesh in the ASCII having the correct bones. Quote Share this post Link to post Share on other sites
LiliArch 115 Posted September 5, 2018 On 8/30/2018 at 11:19 PM, bead-v said: In order to automate this, I could fairly easily do the following in mdledit: on decompilation, if there is a .wok file and no aabb node, generate a dummy aabb node. Could you give a sample of said dummy aabb node, in case I want to make my life more difficult? Quote Share this post Link to post Share on other sites
bead-v 251 Posted September 14, 2018 On 9/4/2018 at 8:09 AM, DarthParametric said: So going back to the bone limit issue, it definitely seems like in K1 at least that 18 or more bones on a mesh is not possible. I am testing a full body model and I had split apart the head/torso/arm meshes to sidestep the bone limit but I didn't pay close attention and had some stray weights on the head and split the arms off one ring of verts too low. That meant the torso ended up with weights for the two lower biceps for a total count of 17 bones. Interestingly I noticed no problems with this mesh. However, the head had stray weights from both collar bones, resulting in 18 bones. This caused the previously described verts stretching to the model base's 0,0,0 (appeared to be verts weighted to the right brow). I went back and had a look at the vanilla Holo Vandar (C_HoloVandar) and Revan (N_DarthRevan) models, as I had previously reported that those both had meshes with more than 16 bones and yet worked fine. Vandar's head mesh has 17 bones and Revan's torso mesh has 17 bones. So it seems to me the bone limit is 17, not 16, but that is definitely the upper limit. Okay, so there is space in the MDL for two more bones beyond 16. However, because we never found more than 16 bones (didn't look hard enough, as it seems), we assumed that was just padding (an otherwise common situation in the MDL). Anyway, I checked Vandar's model, and the first part of the padding corresonds to the index it's supposed to have, so at least that one is still a bone index and not padding. If that is the case, I'm thinking the last one must also be a bone index. It's possible that it didn't work before because mdledit was configured to only put 16 indices in there and ignore the rest. Maybe with the attached version of mdledit, 18 bones will work. On 9/4/2018 at 8:09 AM, DarthParametric said: On a different note, I noticed when loading a binary model into MDLEdit that the bones listed for a given mesh were wrong. I'll look into this some other time. On 9/5/2018 at 8:11 AM, LiliArch said: Could you give a sample of said dummy aabb node, in case I want to make my life more difficult? What I meant was that mdledit would automatically add an empty aabb node. If you want to fix the issue, you just need to add a mesh in kotormax, make it a descendant of the OdysseyBase and apply the OdysseyWalkmesh modifier with the Type set to Aabb. Mdledit crashes when compiling aabb nodes without geometry, so the mesh should have at least one face. This is already fixed and when it's released, you'll be able to add an empty aabb node via the ascii simply as: node aabb NEW_AABB parent BASE_NAME endnode mdledit_v1.0.102b.zip Quote Share this post Link to post Share on other sites
JCarter426 1,215 Posted September 23, 2018 On 9/14/2018 at 5:27 AM, bead-v said: However, because we never found more than 16 bones (didn't look hard enough, as it seems), we assumed that was just padding P_JuhaniBB has a case of 17 too. Not really helpful information now, but I happened to notice that the other day. And continuing with the tangent space calculation issue, I've encountered it with another model and I've attached more files in case they'll help. This is an MMO model, but it's the same problem as before - smoothing errors across UV islands, only with normal map enabled. (Please ignore any other problems with the model. Oh, and the binary is for K2.) Tangent Space Troubles with Ported Underwear.zip Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted October 11, 2018 Got some issues when compiling models with a Flex/danglymesh it would seem. The hood on the Revan/Star Forge robes for example: Interestingly the hood seems to "dance" even in the vanilla version: But clearly it gets mangled when MDLEdit compiles it. The version compiled by MDLOps looks the same as the vanilla version. Files attached. Revan_Robes_Danglymesh_Test.7z 1 Quote Share this post Link to post Share on other sites
ebmar 893 Posted November 24, 2018 Greetings, fellow Jedi! Hope y'all doing fine. I'm going to need an assistance on recommendation for the most stable version of MDLedit. Currently I'm using two different version, with cause: MDLedit v1.0.3: This version works well with the dangly meshes but is failed to implement the bumpyshiny semantic to the model that is working with this version [the reflection will not shown in-game]. MDLedit v1.0.102b: This version didn't work with the dangly meshes but is capable on implementing the bumpyshiny semantic to the model that is working with this version. Many thanks for considering this! Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted November 24, 2018 1 hour ago, ebmar said: failed to implement the bumpyshiny semantic That is a texture semantic. Only the tangentspace flag is enabled in the model. I would suggest for any normal mapped models with danglymeshes/OdysseyFlex that you try MDLOps until bead-v gets around to updating MDLEdit. Quote Share this post Link to post Share on other sites
ebmar 893 Posted November 24, 2018 (edited) 33 minutes ago, DarthParametric said: That is a texture semantic. Only the tangentspace flag is enabled in the model. Yes, I understand. Apologize if my words is confusing. 🙏 My point is, when a model that is bumpchecked with v1.0.3 is linked to a texture that is using a bumpyshiny on its TXI- the shine effect won't work. Sounds odd, but that is a fact; at the very least is on my end. When I load the said model again and then re-checked the tangentspace flag with v1.0.102b, the shine effect still won't work. But if, I generate a new model using KTool [untouched with v1.0.3] and bumpchecked it with v1.0.102b, the shine effect [that is applied to the texture] works. 🤔 Quote I would suggest for any normal mapped models with danglymeshes/OdysseyFlex that you try MDLOps until bead-v gets around to updating MDLEdit. Yup, that's what I'm doing recently; switching around between these two amazing tools. Thanks for the suggestion anyway! Edited November 24, 2018 by ebmar Quote Share this post Link to post Share on other sites
ebmar 893 Posted December 30, 2018 Greetings, Thread Master! Here to report a difference in result between Manual [load > convert > save] with Batch operate on compiling/decompiling model using the MDLedit: That is one out of few instances; as on my end there were some smoothing issues on using the Batch operate particularly with commoner's head. Most of player's head are not having any as far as the attempt goes. The issue mostly leaving some marks around their mouth area. Looking forwards to constructive response on this report- and many thanks for considering this. 1 Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted January 1, 2019 Got an error trying to compile Mission's head model after making some skin weight adjustments: Report: Spoiler Reading ascii files: MDL: P_MissionH-kotormax.mdl.ascii Read files in: 0.001s Indexed 36 names. Done parsing model ascii (0.022s)! Ascii post-processing... Reading supermodel: P_MissionBB.mdl Total Supermodel Nodes: 507 Found an additional adjacent face on edge 2 for face 4 on 'HairCap'... Found an additional adjacent face on edge 1 for face 109 on 'HairCap'... Found an additional adjacent face on edge 1 for face 114 on 'HairCap'... Found an additional adjacent face on edge 1 for face 118 on 'HairCap'... Found an additional adjacent face on edge 1 for face 123 on 'HairCap'... Found an additional adjacent face on edge 2 for face 179 on 'HairCap'... Found an additional adjacent face on edge 2 for face 184 on 'HairCap'... Found an additional adjacent face on edge 2 for face 188 on 'HairCap'... Found an additional adjacent face on edge 2 for face 28 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 29 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 29 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 51 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 30 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 31 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 31 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 32 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 33 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 34 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 35 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 36 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 36 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 37 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 42 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 37 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 43 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 37 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 38 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 40 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 42 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 43 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 43 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 49 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 44 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 45 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 45 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 46 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 46 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 47 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 47 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 48 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 48 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 49 on 'eyeRlid'... Found an additional adjacent face on edge 2 for face 50 on 'eyeRlid'... Found an additional adjacent face on edge 0 for face 51 on 'eyeRlid'... Found an additional adjacent face on edge 1 for face 28 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 29 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 29 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 51 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 30 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 31 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 31 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 32 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 33 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 34 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 35 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 36 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 36 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 37 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 42 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 37 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 43 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 37 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 38 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 40 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 42 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 43 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 43 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 49 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 44 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 45 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 45 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 46 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 46 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 47 on 'eyeLlid'... Found an additional adjacent face on edge 2 for face 47 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 48 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 48 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 49 on 'eyeLlid'... Found an additional adjacent face on edge 1 for face 50 on 'eyeLlid'... Found an additional adjacent face on edge 0 for face 51 on 'eyeLlid'... Building Patch array... Done creating patches in 0.040s. Found 1698 patches! Done post-processing ascii... Mdl ascii read succesfully! Processing aborted. Total processing time: 1.537s ASCII model: P_MissionH-kotormax.mdl.7z Version was 1.0.102 Beta (might want to have version info automatically added to the report). Oh and another bug - saving the report just results in an empty text file. Quote Share this post Link to post Share on other sites
Thor110 498 Posted January 1, 2019 (edited) Having individually converted them using MDLEdit piece by piece I have managed to get most of the maps across, though the following ASCII files still fail to convert / hang during the conversion and do not finish. Spoiler m38aa_03-mdledit.mdl.ascii m38aa_06-mdledit.mdl.ascii m39aa_05-mdledit.mdl.ascii m39aa_10-mdledit.mdl.ascii m39aa_13-mdledit.mdl.ascii m39aa_14-mdledit.mdl.ascii m39aa_15-mdledit.mdl.ascii m39aa_16-mdledit.mdl.ascii m39aa_17-mdledit.mdl.ascii For the moment I plan to import and re-export them using GMax / NWMax but I had trouble exporting last time I used GMax & NWMax. But hopefully this can help solve an error with the program, at first I attempted to K1 Batch > Convert to ASCII all of Korriban, which worked, I then tried to K2 Batch > Convert to Binary all of Korriban which got stuck at m38aa_03-mdledit.mdl.ascii I then individualy tried each module, which subsequently got stuck at 38aa_03 and 39aa_10 respectively, I then K2 Batch > Convert to Binary each individual file, which got me this result for the individual .ascii files that did not convert properly after deleting the original files for all maps and the .ascii files for the parts of the module which had converted successfully. Update : I think these files are actually failing to convert from K1 binary into K1 ASCII in the first place as when exported through MDLEdit the ASCII files will not open in a 3D modelling program ( I tried GMax / NWMax & Blender / Aurora Importer Plugin ) they pop an error, m38aa_03 was missing information and m38aa_06 had extra information, I will take down the results when I try again, for the moment I am trying to re-export them using a 3D modelling program but the files exported in Blender lack .mdx files and I cannot seem to export them as .mdl from GMax. Additional : Having viewed the converted ASCII files in Notepad++ I came to the conclusion they were not being ported out of K1 Binary into K1 ASCII correctly, the files appeared to be upside down / inside out compared to others ( though I did not compare that many due to their sheer content ) and this definitely seems to be the case as I solved my problem using the NeverwinterNights Model Viewer, using it to re-save the original binary .mdl's and then I tried MDLEdit's K1 ASCII Conversion again, then K2 Binary and it didn't work. But I decided after going to the effort of finding the model viewer ( which is really quite handy ) I thought I would persist and converted it into K2 ASCII after re-saving it from the model viewer, I then converted it back into K2 Binary and this seemed to do the trick, though some of this information is unlikely to help you, my problem is solved and hopefully the initial information I have provided will give you some insight as to the problem. Thor110 Edited January 3, 2019 by Thor110 Update on the problem, K1 Binary to ASCII conversion problem. Quote Share this post Link to post Share on other sites
bead-v 251 Posted November 15, 2019 I found some time to look at the reported issues with mdledit. I'm sorry it has taken such a long time to arrive. On 10/11/2018 at 1:51 PM, DarthParametric said: Got some issues when compiling models with a Flex/danglymesh it would seem. The hood on the Revan/Star Forge robes for example: This issue... On 1/1/2019 at 1:47 PM, DarthParametric said: Got an error trying to compile Mission's head model after making some skin weight adjustments: ...and this one are fixed. On 12/30/2018 at 7:29 PM, ebmar said: Here to report a difference in result between Manual [load > convert > save] with Batch operate on compiling/decompiling model using the MDLedit: This one I couldn't reproduce, my Handmaiden has correct smoothing in either case. Your result puzzles me, because both operations use the same routines, there should be no difference. On 1/1/2019 at 8:16 PM, Thor110 said: Having individually converted them using MDLEdit piece by piece I have managed to get most of the maps across, though the following ASCII files still fail to convert / hang during the conversion and do not finish. The problem here was the WOK (it hanged while calculating Adjacent Faces, Edges and Perimeters). Why it happens: The walkmesh is like a blanket, 2-dimensional if you spread it out, there aren't supposed to be parts of it hanging out of it anywhere like in the picture above. In these area models, there were these very small elongated faces not properly connected to the rest of the walkmesh that were causing the problem. The WOK structure cannot accomodate such a walkmesh. The compiler could potentially try to detect such faces by itself and exclude them, but it'd be tricky, take a lot of work and not guarantee success in all cases. I tried a shortcut by simply ignoring faces that had an area smaller than 0.05 m2 and it worked (also ingame), but it could cause problems in other cases, so I decided to remove this (take it as an idea how to find the faces in your modeling program to remove them). From now on, mdledit will throw an error explaining the issue in such a case. The problem must be fixed by the user. Unless some other issue comes up, I definitely want to release an official update to mdledit, because a lot has been added since v1.0.3 (even though there are a lot of details still needing attention (k1-to-k2 area models without aabb nodes, etc...), though I'm not sure there's much interest in this anymore). mdledit_v1.0.103b.zip 1 5 Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted November 16, 2019 8 hours ago, bead-v said: I'm not sure there's much interest in this anymore There's always interest. Progress is just gated by the tools so it gets put on the backburner. 1 Quote Share this post Link to post Share on other sites
Salk 374 Posted November 16, 2019 Thanks for releasing this new version, bead-v! 1 Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted November 24, 2019 The latest version seems to always revert to the KOTOR 2 format setting when the program restarts, unlike prior versions. Quote Share this post Link to post Share on other sites
bead-v 251 Posted November 24, 2019 Thanks for reporting that, it wasn't using the .ini file. Fixed now. mdledit_v1.0.104b.zip 3 Quote Share this post Link to post Share on other sites
bead-v 251 Posted December 3, 2019 I've been preparing a known issues list, because I want to get an official MDLedit update out as soon as possible. Posting it here in case there is something I missed. 1. MDLedit is not capable of processing some very large models (eg. the K1 DS endgame scene area models). I may be able to solve this in the future. 2. When converting area models from K1 to K2, some models lack an aabb node in the MDL. Without the aabb node, the model will not be displayed in the game (unless the VIS file is missing, but this shouldn't be the solution). In this case, first decompile the model to ASCII, then edit the file with a text editor and add the following lines in an appropriate place: node aabb NEW_AABB parent BASE_NAME endnode 3. There have been reports of smoothing not working properly if the model was converted with the batch convert function. I haven't been able to reproduce the issue so far and would be grateful if I could receive all the relevant files to examine them if it happens to you. 4. In some area models, the aabb mesh isn't properly modeled to be used for the creation of the walkmesh, which causes the compilation to fail. If that happens you have two options. You can either inspect the aabb mesh and delete all the offending faces or you can enable the 'Export WOK file' option in MDLedit, then use that mesh to replace the aabb mesh, just make sure it has all the right options afterwards. In the future, I will add an option for the WOK file to be handeled separately, so this issue won't arise anymore. 5. Smoothing will sometimes not work across boundaries where the UV is mapped in different directions. This requires an update to the vertex normal calculation and will hopefully be solved in the future. 1 Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted December 3, 2019 How about the exporting of error reports that I posted about back in January? That might be useful for providing you with more details. Quote Share this post Link to post Share on other sites
bead-v 251 Posted December 3, 2019 30 minutes ago, DarthParametric said: How about the exporting of error reports that I posted about back in January? That might be useful for providing you with more details. Fixed 1 Quote Share this post Link to post Share on other sites
ebmar 893 Posted December 3, 2019 Thank you for the latest build of mdledit, bead-v! So - On 11/16/2019 at 2:22 AM, bead-v said: This one I couldn't reproduce, my Handmaiden has correct smoothing in either case. Your result puzzles me, because both operations use the same routines, there should be no difference. 3 hours ago, bead-v said: 3. There have been reports of smoothing not working properly if the model was converted with the batch convert function. I haven't been able to reproduce the issue so far... Just recently I did the test again with MDLedit v1.0.3, and compare both binaries by using HxD's Data comparison feature the result are indeed identical [accepting that's a valid method to do], which puzzles me also. Though I ain't really sure if the in-game result would be different as I haven't tested it. Quote ...could receive all the relevant files to examine them if it happens to you. Thank you for the heads-up. I have lost the incorrect smoothing ones [as I don't feel the need to keep it back then], therefore, I'll be back with the relevant evidence when I got one in the future. May the Force be with you in your attempt on updating this wonderful program. I can't thank you enough for this. 1 Quote Share this post Link to post Share on other sites
Kexikus 995 Posted February 22, 2020 I have an issue where MDLedit chokes on a very simple skybox model. I tried both 1.0.3 and 1.0.104b and in both cases MDLedit just crashes when loading the model. MDLops 1.0.0 on the other hand can handle the model just fine. However, the ceiling of the skybox in the compiled model is rotated compared to my 3dsMax scene. That's probably a different issue but I thought I'd mention it just in case it turns out to be important. Any help here would be very much appreciated. I attached both the ASCII exported from 3dsMax and the compiled model from MDLops. 402dxnz.zip Edit: Turns out that it was an issue with the animation in the model. I exported it without animations and now everything is working fine and there were no animations in use anyway. Not sure what the issue was before so maybe it's still helpful for you to improve MDLedit. 1 Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted February 22, 2020 The problem with the animations in the attached ASCII is that the tracks are empty. MDLEdit is a primadonna. It throws a tantrum if everything isn't just right. 1 Quote Share this post Link to post Share on other sites
bead-v 251 Posted February 22, 2020 1 hour ago, Kexikus said: in both cases MDLedit just crashes when loading the model. Thanks for reporting this! This is a situation the code doesn't consider, so it crashes (unfortunately). I can reproduce the problem, but I'll have to hunt down to place where it happens when I have more time. In the mean time just make sure your animations have nodes in them if your experience another crash (or alternatively delete the animations). Sorry for the inconvenience! 2 Quote Share this post Link to post Share on other sites
Kexikus 995 Posted May 19, 2020 Found another issue with mdledit sadly. I cannot change the "affected by fog" parameter in the header of a model. When I go into the edit window of the header values, I can change it just fine but even when I save those changes, the value is not updated in the main model window. Changing other values works fine though so I think I'm doing what I'm supposed to do. Quote Share this post Link to post Share on other sites
DarthParametric 3,785 Posted May 19, 2020 Also doesn't work if you edit an ASCII? Quote Share this post Link to post Share on other sites
