• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!

Java MDL lib

Status
Not open for further replies.
Level 2
Joined
Sep 29, 2015
Messages
3
Level 29
Joined
Jul 29, 2007
Messages
5,174
Can't be bothered to go through all of it, especially since it's in Java, but what I immediately tend to check is support for multiple texture coordinate sets, and your code doesn't support them (although I might be wrong, it's pretty hard to follow the code).
I have no idea how multiple sets are expressed in MDL, haven't touched the text format in years.

I also noticed you keep recompiling regexes, caching them might improve speed by a lot, depending on how many times it happens (e.g. MDLField::setName, MDLField::getTokenDelimiter, MDLString::parse, and many other places).
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,202
Where do you read binary data of the model format? I see String everywhere... Or are you incorrectly treating binary data as String?

Does this parse the third party (as far as I can tell) text version of "mdx" files called "mdl" (not to be confused in game as those mdl paths are to mdx files)? Or does this parse actual "mdx" files such as used by WC3. There is a big difference since the third party mdl files are user readable text while the game mdx files are a proprietary binary format (which some geniuses revere engineered and posted specification about).
 
Level 2
Joined
Sep 29, 2015
Messages
3
Where do you read binary data of the model format? I see String everywhere... Or are you incorrectly treating binary data as String?

Well, it's a parser for MDL (not MDX)... The file is read in a straight-forward way and then parsed using regexes...

Can't be bothered to go through all of it, especially since it's in Java, but what I immediately tend to check is support for multiple texture coordinate sets, and your code doesn't support them (although I might be wrong, it's pretty hard to follow the code).
I have no idea how multiple sets are expressed in MDL, haven't touched the text format in years.

I also noticed you keep recompiling regexes, caching them might improve speed by a lot, depending on how many times it happens (e.g. MDLField::setName, MDLField::getTokenDelimiter, MDLString::parse, and many other places).

Thanks for the feedback! Yea, keeping the compiled regexes seem wise. Also, can you provide me a model containg the multiple texture coordinate sets? The way I wrote that parser was pretty crazy. I didn't know the grammar nor anything, so I just opened some MDL files and started to create my own grammar. So I think I might have missed some things (although the lib generated exact copies for most Blizzard models).
 
Level 29
Joined
Jul 29, 2007
Messages
5,174
"Java MDL lib"
"MDLParser"
...

Thanks for the feedback! Yea, keeping the compile regexes seem wise. Also, can you provide me a model containg the multiple texture coordinate sets? The way I wrote that parser was pretty crazy. I didn't know the grammar nor anything, so I just opened some MDL files and started to create my own grammar. So I think I might have missed some things (although the lib generated exact copies for most Blizzard models).

Yeah that's what I did back in the day, and then I realized I missed all sorts of things.
Your code seems far better, but you are still bound to miss some things, like multiple coordinate sets.
I don't even know if anyone made an MDL exporter/importer that supports them, hardly anyone supports them in the MDX format either (even though it's very straight forward in binary).
BlinkBoy released a list of all of the MDL keywords he could find in game.dll, but I don't remember where it was, I'll try to find it.

/Edit
It's in this thread, I suggest you to read the whole thread and get the uploaded models, they contain more exotic features than your common model.
Granted, no one actually knows how to use some of the things there (or whether they are even usable in the game), so take it with a grain of salt.
 
I also wrote an MDL parser like this back in high school, but it was within my first year of learning Java after a life of mostly only JASS coding and the code was pretty bad.
However, with time, I believe the Matrix Eater MDL spec has gotten to the point of having the "least change" among most of the MDL-editing programs, and I specifically remember coding in multiple texture layers from the getgo in high school because of how bothered I was by other programs that would be missing parts of the specification.
https://github.com/Retera/JWC3/tree/master/JWC3/src/com/hiveworkshop/wc3/mdl

However, ever since I linked the program up with the MDX lib from here on the hive, I've been hitting some compatibility issues with the format where things like Light colors would get swapped if opened in the MDX lib via Matrix Eater, saved as MDL, manipulated in other programs, then re-saved as MDX from the Matrix Eater using the Java-based MDL-MDX conversion. As of yet, I have not burrowed back into my code-base to find out if the bug was in my in-memory converter code or in the MDX library, but I was thinking it might've been a different color ordering between MDX and MDL. There are also the issues where fan-made model converters almost always drop in insensible values having the maximum value for a Float, which seems to be a common theme among fan-made converters.

To correct Dr Super Good, the MDL model format is not actually fanmade. It was created by Blizzard Entertainment and models can be exported to it from 3D Studio Max 5.0 [They used 4.9 if I recall, my virtual image runs 5.0] using their original War3 Art Tools. However, as independent authors tried to parse the format across many programs, the format has become a horrible hodgepodge, where the further out on the fringe you go in terms of features the less likely any program is to support you. This includes things like particle emitters that emit team color, multiple texture coordinate sets, and those sorts of things. This is why, when all else fails, YobGul's File Converter is still to this day the best for MDL->MDX conversions, if I am not mistaken, because it uses a decompiled copy of Game.dll to do the converting. So it provides access to the entirety of Blizzard's MDL spec.

However, YobGul's converter has no command line interface and is generally a piece of crap program that crashes after the first fifteen uses, so I usually only use it on models that the fan-made MDLX Converter suggested on most sites does not get right. But, it's like a thorn in my soul that the Matrix Eater's current MDX library is only 95% accurate, because I think it's MDL spec holds on to a lot of values as Strings and really tries to generally never lose any original data from the file -- although it's grown to have some serious problems, such as the fact that upon saving it recalculates all GeosetAnimId values and all GeosetId values for Bones (under the assumption that nobody wants to manually remember to update those!) and this recalculation messes up like 0.1% of models if they were designed to use some uncommon setup and designed manually instead of in an automated way (so basically this is only a problem for non-Blizzard custom models, and... For the Blademaster's dissipate animation. I really should figure out what was up with that one single animation that it got wrong. Blizzard forgot to flag the Ribbon Emitter from the Attack Slam crit animation thing as NOT being visible during dissipate, but made it invisible through some other arcane GeosetId means, which the Matrix Eater accidentally wipes out upon re-saving).
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,202
To correct Dr Super Good, the MDL model format is not actually fanmade. It was created by Blizzard Entertainment and models can be exported to it from 3D Studio Max 5.0 [They used 4.9 if I recall, my virtual image runs 5.0] using their original War3 Art Tools. However, as independent authors tried to parse the format across many programs, the format has become a horrible hodgepodge, where the further out on the fringe you go in terms of features the less likely any program is to support you. This includes things like particle emitters that emit team color, multiple texture coordinate sets, and those sorts of things. This is why, when all else fails, YobGul's File Converter is still to this day the best for MDL->MDX conversions, if I am not mistaken, because it uses a decompiled copy of Game.dll to do the converting. So it provides access to the entirety of Blizzard's MDL spec.
I guess the problem was I used one of those "fan made" converters so the MDL I made was not compatible with WC3. Kind of a cheek to even call it MDL in that case since it clearly is not MDL as far as WC3 is concerned.

I can back this up by saying that there are MDL tags and other string based constants inside the WC3 program code. As such my initial statement is false. Or at least is false for true mdl, and not the nonsense fan made stuff.

If only the assembly code was more readable. I have been having similar issues with BLP1 specification where 2-3 fields have unknown or only roughly known mechanics. As such a lot of fan made tools will parse some blp files as if they looked perfect yet in game they are broken, either failing to load at all or loading wrong.
 
Level 29
Joined
Jul 29, 2007
Messages
5,174

MDX saves some colors as BGR, and some as RGB. I don't quite remember which is which, but you can check the 3d viewer's source if you really want.
I think all regular colors were BGR, and all color keyframes were RGB.

I also remember having issues with the blademaster's animations showing up when they shouldn't, and then I fixed it.
I don't remember what the actual issue was, but again, you can check the viewer's source.
It's probably something to do with keyframes.
Then again, the viewer has issues with keyframes too, as well as every other program that ever messed with MDX. If you can figure how the game handles sequences with no beginning/ending keyframes, do tell! (e.g. this, and some following messages)
 
Status
Not open for further replies.
Top