bead-v

Thanks! It looks like kotormax exported a bunch of UVs that aren't even used on one of the nodes, bumping the index so much it went into negative because the numeric variable was signed rather than unsigned. Anyway, a quick and simple fix, won't be a problem anymore. The model compiles now, but it takes its time...

Which model? Is it only the condensed version that chokes? May I get the ascii?

Could I get a test case of such a situation, JC? Maybe I could put out a warning or something...

@ndix UR Aha! I'll try to implement it tonight. This also means improved SG caluclations Thanks, ndix UR! The object space : world space comparison bit also explains why it always worked within a single mesh but only sometimes between meshes (when the spaces matched). Awesome!

Okay, so I've been banging my head over this and here are the results. I double checked the algorithms, tried a number of smoothing group configurations, tried changing weights on the relevant verts... while some attempts produced better results than others, I never could get the seam to go away. I may have fixed the algorithm at least a bit though, so you can fetch the latest BETA at the bottom of this post. So then I looked at the vanilla model. Here's the debug info for the vert in the middle of the back where the seam is (that's actually 4 verts). Their vertex normals do not correspond to any combination of the corresponding face normals. If we look at the situation from the side, we see this (sorry for the bad drawing – it's just an approximation, though I did try to get the ratio between the normals right). The arrows are vertex normals, the lines are edges ending in the relevant vert. As you can see, the vertex normals of both vertices that belong to the Cape are the same and point outwards away from the body. The vertex normal of the vert that belongs to the lower part of the torso (the part under the cape) is equal to the cape's vertex normal, except it is mirrored along the Y axis and so it points inwards. Also the vertex normal of the vert that belongs to the upper torso (the part not hidden by the cape) points inwards, but at a different angle. I don't know why this has to be so. Usually when you want smoothing between faces that share a vertex, you make sure the vertex normals in that location are all the same, pointing in the same direction. But if you try to do the same in this situations, you'll get a seam instead. I also can't see how these normals could be automatically calculated from face normals and smoothing groups (if someone can, please enlighten me). So, the only way out that I can see is to enable the export of vertex normals from max into the ascii and then direct import into the binary model. This needs to be discussed, but if we decide to go this way with all the tools, it'll take a while before everything is synced and ready. mdledit_v1.0.7b.zip

The position where the dark patch originates from is shared by four verts in the node, some of which belong to the outside of the face, while the others belong to the box inside the mouth. If you make the box inside the mouth a different smoothing group, the issue goes away. Basically, the tools are in this case not able to get the correct SGs from the normals during decompilation and assign the same SG to all the faces sharing the verts, causing smoothing between faces that are facing opposite directions, which ends up looking like a dark patch. The conversion of vertex normals to SGs is an imperfect process (basically a bunch of guesswork), so not much can be done about it on that level, besides taking a lot of time to think of another algorithm, implement it and hope it works. I still think the best solution is to start putting SGs into the model directly, so we won't need to guess them from the normals on the models that were already recompiled once. But this still requires discussion.

It will be resolved! I don't know why Visas' head didn't work for you, because it really seemed to work for me. But I think we're closer now, at least. I'll look at it again after my exam.

Uyyyy... I'll convert the warnings to error messages then!

Did you try the version with the 18 bones? I think we still don't know what happens in the game in that case. Both kotormax and mdledit should give you warnings but let you do it in the end. Nice job otherwise and thanks for writing up the notes. I hope we get the wiki soon so we can write up some kind of conversion tutorial using this info.

Thanks, xt! Nope, haven't looked into that issue yet. Next time! Here's the xp version: mdledit_v1.0.6b_xp.zip

I had some free time and decided to work a bit on mdledit. It will now calculate the tangent space vectors for all the nodes that don't have them when a binary model is loaded. This means that you'll be able to open a binary model, enable bumpmapping on one of the textures and save it, and it'll work (well, as long as mdledit produces good smoothing group results). Another thing I finally implemented is when you compare a model to the one opened in mdledit, if you highlight some bytes, it will show you the compared-to file's bytes instead, meaning you can compare the values inside mdledit. I also fixed some issues with the GUI in hex view, as well as how mdledit resizes when hex mode is entered and exited. There were some smaller improvements as well. For anyone who wants to play around with it: mdledit_v1.0.6b.zip

❤️

In the header of the binary mdl file, there is a string that represents the model name. That is probably the name that the game uses for the things you mentioned. But the same name is also used as the name of the first object. This one is stored in the name array which comes after the header. You can open any model in mdledit and you will see this immediately in hex view. So while you only have one name in max (the name of the base), in the binary it appears in two places, once as the model name, and once as the name of the first object. They are always the same. I can only change the model name without recompiling the model, and not the name of the first object. So the question is, if I only change the model name, will it work or are there instances where the game references the first object name instead. It's not likely but it's possible.

Under Header, you can only change the model name, not the name of the first object (the "aurora/odyssey" base). I don't know if that's enough for the game, or whether the mismatch between the model name and the name of the first object would cause problems. Anyway, this way of modifying data is without compilation – it changes only the relevant bytes in the binary, everything else remaining the same. Renaming any object necessitates recompilation, because the length of the name is not set and may affect the size of the binary, which messes up all the offsets, breaking the model. That's why I need to find another way to do it.

Whenever I get a new message, I also get a notification. This annoys me, so I go to the notification options to change it, and the option is there, but it says toggling it is disabled by the administrator. Why is that?

Regarding these... it's intended to work this way. Converting bezier controllers to linear is a switch for decompilation, not compilation. If you want to convert bezier controllers to linear, do it in max (the way JC did it) or change your CONTROLLERbezierkey to just CONTROLLERkey in the ascii with find/replace. To me that seems easy enough to do, so I don't think another switch is necessary in mdledit. Or am I wrong? @JCarter426 , so all the Holocron issues are clear now? Nothing that would require a change in mdledit, if I understand correctly? There has been a request for an option in mdledit to change the base name without having to convert to ascii (it can't work without recompiling because the new name may be shorter or longer than the old name). Any ideas what that would look like and where I could put it? It would be great if all bugs and suggestions are submitted in this thread, so I can see everything in one place. I will also start tracking open issues in the first message of the thread (let me know if I miss something).

Something in the patch creation algorithm seems to have been causing this. I noticed that when I applied smoothing in kmax, that part between the torso and the cape would get smoothed, so I rewrote the algorithm in mdledit based on how I wrote it for kmax, and according to my preliminary tests, the issue is gone. The new version is attached. EDIT: @DarthParametric, I also tried recompiling Visas' head, I think that issue is fixed now too. mdledit_v1.0.5b.zip

A forum like that has already been proposed a few times since the new tools started appearing. There has been mention of new forums that are supposed to be on the waiting list to be created, but I'm not sure if this one is included. A wiki is very welcome, but I think a new forum for such discussions will still be necessary. So, fingers crossed!

Permission granted.

Sony Xperia XA1, Android 8.0.0, Mozilla Firefox

I'm experiencing a problem with the reply window on my phone. Whenever I move the input cursor thingy somewhere else to edit already written text, it jumps me to the top of the reply window. If I have quoted a long message, I have to scroll down to get back to my message every time, so it's really annoying. I hope something can be done about that.

Would it be easier if the format of the values in that window would match the one in the ascii? I think that should be possible for me to do.

There is indeed a failsafe, but not always I think, in the currently released version . In the next version of mdledit, pretty much everything will either use a default value or show you a specific error message in such cases. You will also be able to see in the report all the cases where values were missing in the ASCII and mdledit used default values instead.