a MDX to M3 Converter, is 99% possible without editing

[BlinkBoy]

After studying the M3 format and comparing it to the MDX format, I came to a fast conclusion. The MDX format is ALMOST a subset of the M3 format. That means we could write in a team an almost perfect converter.

I think blizzard pretty much intended this to happen since they left a lot of things for backward compatibility like tags for lumber and gold animations. I wrote a half comparison of both formats. I haven't finished writting the part for Lights, Attachments, Part Emitters 1 & 2, Ribbon Emitters and collision shapes, but it's possible to convert them perfectly. There's, however, some challenges.

Challenges:

• We need to reverse enginner still some parts of the format like Particle Emitters and Ribbon Emitters. Easily done since Art Tools have been released.
• There are some things that need work arounds to work exactly as in MDX. Things like Texture Animations require that the textures be backed into flipbook textures (pretty much unite all the textures in one).
• We may need to recalculate tangents for binormals. Easily done by getting the connected vertices produce a vector fropm our target vertex to the center of each face and plussing them and normalizing.
• Materials work diffirent in both formats, some work arounds must be done to predic what could be the best representation. Normaly an smart choice system.
• Birth, Decay and Dissipate animations, should be rescaled.

Limitations on M3 that MDX doesn't have:

• Meshes with more than 4 texture maps in MDX, must be sepparated to regions and their priority of drawing should be changed. (very unlikely to find a model with 2 texture maps and with 5 or more is almost like 1 in a billion).
• Wc3 accepts linking a vertex to more than 4 bones at once, sc2 only accepts 4 bones per vertex. This can happen more likely (still a very small chance), so we may need to ignore the bones nearest to the vertex in that set. (It's hard to say which one would make the vertex lose less quality)
• Alpha Key blending mode does not exist on Sc2, but could be simulated with an emissive map with very low HDR.
• Non-Uniform scale keys must be avaraged.

Some interesting facts:

• MDX's Particle Emitters 1 & 2 are just a complete subset of Starcraft 2's particle emitter system. Both can be fully converted.
• MDX's Ribbon emitters are also a subset of Sc2 Ribbon Emitters.

What I think we should work on before an MDX to M3 inmediate converter be a reality:

• Finish Reverse Engineering the M3 format specification.
• Define a new format called M3L which will be a text format representation of M3. Using an MDL style of format. (M3 has structures which would be very confusing for people trying to understand the format, it's better not to represent in text form as it exactly is, this means a lot more work on conversion but eases the live of many people and of developers with few knowledge on binary formats).
• Make a simple, stable, multicompatible M3 to M3L/M3l to M3 converter.
• Produce an MDX to M3 converter.

How I'm adressing this in a fast way?

As some of you know, i develop a set of tools called the NeoDex toolset for 3ds max & gmax. I'm currently finishing the MDX importer for it. The idea would be to have a second toll in NeoDex which would convert a NeoDex Wc3 Scene to a Sc2 Art Tool's scene. The problem with this solution is that, one is elitist (only people with access to 3ds max 2011 can use it) and second: I'm limited to maxscript. It has it's pros, though.

So why writting this up?

I think spreading my research is part of a way to help motivate the idea of working on such a big project. The project needs many people to be achieved in few time.

Ok great so how could we organize?

For starters, we should pick a software methodology. I believe SCRUM would be the best for managing ourselves and the software developing technique should be Boehm Spiral since we research and produce at the same time (an evolutive model).

For tools and languages.

on Reverse Engineering: Any Hex Editor should do fine for looking into the M3 files and game dlls. A software dissembler is also useful but only when we want to look for undocumented/hidden feutures. 3ds max 2011 and Art Tools would be the best to generate our studying samples.

on describing formats: a metamodel defined in XML or UML. Constraints on OCL or natural language.

on developing the tools: UML should be used for design, Java would be our best bet for developingdue to portability. Documentation should be in javadoc format and also atleast a basic Software Architecture Document as well as a Software Requirements Elicitations document (could be done on wikis). For multiteam I suggest google.code or github and an SVN/Git tool. Netbeans and Eclipse should be optional (In my case I prefer doing everything with genie or notepad++ xD).

EDIT: could someone move this with a perma link to the Programming forum? I originaly intended to post it there, but I confused xD.

 

[GhostWolf]

I was wondering if I should get Art Tools just to see if I can check how the format looks, but then I figured it's probably a plugin rather than scripts, and I don't have much experience in reverse engineering.

 

[BlinkBoy]

I was wondering if I should get Art Tools just to see if I can check how the format looks, but then I figured it's probably a plugin rather than scripts, and I don't have much experience in reverse engineering.

Well I could post any models. Sadly this computer can't run Sc2, so I can't really test them.

Reverse Engineering a format like MDX or M3 is quite easy due to chunk tags. If you know the chunk tags then just compare what you were exporting to the file.

Here's the best M3 reference I've found:
https://github.com/flo/m3addon/blob/master/structures.xml

would be nice to be rewritten to be easier to read.

EDIT: added two test models of a simple triangle with a creep material. Just get a hex editor and start looking.

 

[HammerFist132]

Man you put a lot effort to make job for modelers easier. Thank you