bead-v

MDLedit bug reporting thread

236 posts in this topic

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Got some issues when compiling models with a Flex/danglymesh it would seem. The hood on the Revan/Star Forge robes for example:

Revan_Robe_Hood_Danglymesh_MDLEdit_TH.gi

Interestingly the hood seems to "dance" even in the vanilla version:

Revan_Robe_Hood_Danglymesh_Vanilla_TH.gi

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

  • Thanks 1

Share this post


Link to post
Share on other sites

Greetings, fellow Jedi! Hope y'all doing fine. :cheers:

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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! :cheers:

Edited by ebmar

Share this post


Link to post
Share on other sites

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:

MDLedit_RsltDffrncs.jpg.fd1d903060d566a5e5b0f13a8e8684b2.jpg

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

  • Like 1

Share this post


Link to post
Share on other sites

Got an error trying to compile Mission's head model after making some skin weight adjustments:

Mission_Head_Error.jpg.04025c4366369a5d44749c71e836cfa0.jpg

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.

Share this post


Link to post
Share on other sites
Posted (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 by Thor110
Update on the problem, K1 Binary to ASCII conversion problem.

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