ZDoom

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

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.

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.

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.

Nash wrote: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.

Nash wrote: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.

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

@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?

axredneck wrote: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.

Nash wrote: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.

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

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

@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.

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

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.

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

ahhh the blender monkey head

I am learning blender and looking forward to use this exporter to export models for use in gzdoom

as much as I love maverick, it is still limited compared to blender.. even the most recent version that is only available for those who downloads the latest sourcecode and compiles it (it supports attaching models to tags like adding weapons to quake 3 player models for example)

does it have an import function and can it create and attact tags to a model for weapons etc (tag_head,tag_weapon etc)

does it need to use skeleton animations and does it translate those to mesh animations when saving as md3
(it will need to translate any skeleton animations to mesh animations, since md3 does not support skeleton animations)

can it create gzdoom data files?
or could I expand it to have that functionality?
(modeldef, textures, decorate)

and what about sounds and sndinfo?

does it support animations?

what version(s) of blender does it need?

does this or blender support smooth transitions between animations? so one can cut down on the nr of req animations

in theory with an existing doom 2 monster as a template, it could export a pk3 file ready for use in gzdoom along with the regular md3 file
then modders could group the pk3 files they want in another pk3 file

ie

template monster

spawn,see,death,xdeath,missile,melee,raise, yes,greetings,no, custom anim frame start
spawn,see,death,xdeath,missile,melee,raise, yes,greetings,no, custom anim frame end

...
name
health
melee type
ranged type
flying speed
walk speed
...

if need be the sounds could just be the standard set that then could be selected based on the template maybe with customizations... ie if- a monster is based on zombieman but has a chaingun and thus needs shooting sounds from chaingundude


seems I can not postpone learning Python any longer