[BETA] Blender MD3 exporter rewrite

[Talon1024]

I wasn't happy with any of the MD3 export plugins available for Blender. All of them were lacking in some way, or frustrating to use in some way, and none of them could tailor the exported MD3 for GZDoom, except Nash's MD3 exporter for Blender.

I decided to partially rewrite Nash's MD3 exporter plugin (which is based on another MD3 exporter) to be easier to use, more accurate, and hopefully, export things faster.

As for the changes:

• If you have multiple models selected, my MD3 exporter plugin tries to mash them all together into one MD3 model.
• Only one shader is exported per surface. I don't know of any instance where multiple shaders are applied to one surface, or even where having multiple shaders on one surface would be practical.
• As a result of that, there is no need to split objects by material any more.
• Does not use bpy.ops, so it should not damage your work.

Basically, you can select any objects you want to export to an MD3, and leave the rest to the exporter.

You can download the rewritten MD3 export plugin from my Nash's GitHub repo here. EDIT 2020/08/01: Updated GitHub repo URL

[Nash]

I haven't look at this fully yet but, the circled 3 commits are bad and should not be inherited. The resulting MD3s are usually broken (especially when multiple objects are concerned) because of these 3 commits.

Admittedly this was a very short sighted duct tape to get rid of having to put AngleOffset 90 in the MODELDEFS - the idea is good but the implementation is terrible. :P

I have been meaning to revert them but I just didn't find the time to do so.

The proper way to do this is to apply rotation math to the encoded vertices.

If you did not inherit this part, however, and went with your own solution - then disregard this message.

[Talon1024]

No need to worry. How I handled that was by creating a transformation matrix that "fixes" the model rotation, scale, and position, and applying it to the meshes with .transform.

The relevant lines are here, here, and here.

[Nash]

May I backport the transform matrix fix into mine?

Also, did you figure out how to lift the 512 unit limit?

Actually, how would you like to maintain the mainline script? I can add you as a contributor so you can commit it directly. No sense making several forks if your work fixes a lot of essential issues.

[Talon1024]

May I backport the transform matrix fix into mine?

Actually, how would you like to maintain the mainline script? I can add you as a contributor so you can commit it directly. No sense making several forks if your work fixes a lot of essential issues.

Sure. But if you're going to do that, you may as well merge my rewrite branch into your master branch.

Also, did you figure out how to lift the 512 unit limit?

It's a limitation with the MD3 format, and the fact that it uses 16-bit signed integers for XYZ coordinates. I suppose one workaround could be to set MD3_XYZ_SCALE in the script to a lower value. Another workaround could be to automatically scale the model so that it fits perfectly within the 512 limits.

[axredneck]

Thank You very much for this work!
Is it possible to port it to Blender 2.80 ?

[Nash]

@Talon1024: I've sent you an invite. I'll merge your master into mine soon; got a little caught up with some work. Perhaps I'll be able to do it this weekend.

I have a question about the custom 'md3shader' property. Looks like you removed its functionality. In the vanilla version of the script (the one inherited from Katsbits), there were 2 ways to assign textures to a mesh group:

1 - naming the material of each object the exact path that's used inside the PK3
2 - adding a custom 'md3shader' property to each object with a string to the exact path

These are both convenient for embedding the texture paths at export-time. I am partial to the latter one because I didn't like how long the material names appeared in the outliner.

May I know what was your motivation for getting rid of the md3shader custom property?

[Talon1024]

Thank You very much for this work!
Is it possible to port it to Blender 2.80 ?

I don't know how hard that will be.

May I know what was your motivation for getting rid of the md3shader custom property?

I must have forgot about it while I was rewriting the script. Keeping track of each surface and its material was hard enough.

[Major Cooke]

Which version of Blender? And if its 2.7x, any chance we can see a 2.8?

[Talon1024]

It's currently for Blender 2.79x. I'm doing some research on porting it to Blender 2.8x, however.

[Nash]

@Talon1024:

As a follow-up to the bugged normals of the DemonStatue in the other thread:

FYI the model was exported with an active armature rig. The neutral pose was a T-pose, I posed it to kneel down and exported it. Granted, I was using my old version of the exporter still (this thread did not exist by the time I made my demo file for Graf).

I can provide a .blend file later but in the mean time maybe you can have a look at how it's exporting normals when armatures are involved.

[Nash]

Question: what's this for (MD3 name)?

[Talon1024]

That's for the name field of the MD3 header. If you leave it blank, the exporter automatically sets it to the model filename, but without the extension.

[Nash]

Reported several issues and included an example file. :) https://github.com/nashmuhandes/io_expo ... 3/issues/4