Any utility that assists in the creation of mods, assets, etc, go here. For example: Ultimate Doom Builder, Slade, WadSmoosh, Oblige, etc.
Forum rules The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
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
Last edited by Talon1024 on Sat Apr 10, 2021 6:35 pm, edited 3 times in total.
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.
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.
@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?
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.
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.
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
...
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