KatsBits Community

MD5 export/import proposal Blender 2.64+

0 Members and 1 Guest are viewing this topic.

Offline meta-androcto

  • Newbie
    • Posts: 1
hi,
I'm meta-androcto,
I maintain/write/look after some Blender addons & some addons in Blender Contrib & Releases.
There's a few people looking at fixing md5 export for Blender 2.63/4
this is largely due to motorsep being persistent...

In the past, I have looked to this site & community, knowing that you guy's handle your export/imports very well & credit to you all, well done :)

I'm interested in what you guy's would like in the future.
There is a real possibility to put a working & maintained md5 toolset into blender Contrib with a view to Blender Official Release.

I notice there are a few versions "around" & a few ideas on what's right & wrong way to do this.
Currently from what I understand, which is little. ;)
keless version is prefered workflow, export md5mesh & md5animation file.
It seems to have a few issues, most easyish fix, related to Blender api Changes, not only from 2.61 to 2.62 matrix change, but more importantly, api changes related to bmesh affecting faces & uv co-ordinates.
This addon also has a specific workflow & requirements to be met by the user.
not hard, must have material, must parent to armature, must set at least 1 keyframe for static mesh export.
It seems to slot in a keyframe for whatever the animation length is, which can be a lot of keys.
Biggest problem is the wrong matrix orientation, this can be fixed & I would guess already has been by nemyax version.
nemyax version I have not tested at this point.
I do intend to test this but I'm not an expert on md5.
I can do fixes & get exports working, but if it's already been done...

What I need to know is:
What do you guy's need in the exporter?
What should the workflow be?
personally I would say general export mesh, armature, materials, uv, animation data.
What options are needed to refine the workflow?
Are there more specific options that may be needed to improve workflow in certain use cases?
Who would maintain this?
Is there a member of the community prepared to work on this?

I would consider md5 export as suitable for inclusion into Blender contrib addons.
I would put md5 export & import? (is there already an importer?) in Blender contrib svn for a trial period, then, if successful have the addon reviewed for include in Blender release.

Please, let me know what you guy's want from this & the direction you would like to take as a community.

Thanks.
Brendon Murphy
Blender addons team.


Offline motorsep

  • Jr. Member
  • *
    • Posts: 75
Alright then. Thanks for posting here :)

Here is what I've brainstormed while getting proposal to CoDEmanX (who seems to drop the ball on development of the exporter).

Here is what I posted at BlenderArtists:

The workflow for exporting animated model is as following:

User selects rigged mesh (single surface / multi-surface / several meshes) and the armature. In the menu user selects File > Export > Doom 3 MD5 exporter and the below posted GUI shows up.

If the model facing +Y (default to Blender) and Rotate model checkbox is on (not present in the GUI currently), the model will be rotated to face X+ axis as required by Doom 3. If the checkbox isn't ticked the model will be exported as-is.

If there is no camera in the scene, Camera export checkbox should be unchecked, grayed out and not available to user (maybe Camera option export shouldn't even be in the panel if there is no Camera in the scene).

If there is animated Camera in the scene and user wants to export it, (s)he should check the Camera checkbox and type in filename for the camera (extension will be added automatically upon exporting).

Technical details:
  • Filename in the Blender file browser overrides MD5Mesh name in the GUI's input field (if no filename specified, MD5Mesh name input field will be used);
  • Existing files get overwritten if user used same filenames in the input field / browser window;
  • Upon exporting material name should be written as shader name into .md5mesh file;
  • Mesh (meshes) should be UV mapped and contain vertex group with names corresponding to deforming bones;
  • The framerate set in Blender should be written into .md5anim file;
  • Besides deforming bones, only bones in currently visible/active armature layers should be exported (deforming bones must be exported always; user should never be restricted to put bones into a specific bone layer for exporting purposes);
  • Mesh can be single, multisurfaced or several separate meshes (as long as they are parented to armature and have vertex groups).
  • Only selected meshes and armature should be exported. Unselected objects should be ignored (especially true for custom shape bones).
  • Each animation suppose to be a separate Action
  • Animation length for each Action is determined either by frames where keys begin and end, or by the two markers placed for each Action, signifying beginning and end of the animation (presence of the markers overrides actual animation's length).

The GUI (which CoDEmanX already implemented and which is functional):

1. Default look of the GUI when all available actions are going to be exported (one md5anim per Action), the filename is defined in the file manager http://i.imgur.com/vmplJ.png

2. Only selected Actions will be exported into md5anim files along with the md5mesh. The filename is defined in the input field "MD5 name" and it will override filename specified in the file manager http://i.imgur.com/3wnXG.png

3. GUI when only animated camera is going to be exported (I don't recall if we decided to hide Actions list if Camera checkbox is ticked) http://i.imgur.com/gg0GZ.png

There is one option missing from the GUI which is "Rotate model" checkbox which rotates model on export around Z axis. I will elaborate on camera export later, when I go over the correspondence I had with CODEmanX.

Tech specs:

http://www.modwiki.net/wiki/MD5MESH_%28file_format%29

http://www.modwiki.net/wiki/MD5ANIM_%28file_format%29
http://www.modwiki.net/wiki/MD5CAMERA_%28file_format%29

There is more stuff I have to mention, little details that came to sight while I was designing the blueprint of the exporter, so to speak, but I will post them as the development unfolds.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
Thanks for posting and asking about this meta-androcto.

Can't really add much more to what motorsep outlined above as that pretty much covers what the scripts needs and the way the script has worked from the very beginning (BTW using timeline markers seems a more sensible way to set end and start points for animation, especially if some sort of batch export is implemented - it may be better to set this as a requirement due to the way some sequences have to be authored to prevent problems with the start/end frames not being averaged properly [no frames either side of them to average to/with]).

Anywho, generally speaking for an 'official' script it's going to be best to stick with the currently accepted workflow (outlined above by motorsep), because that's been used since the script was originally created - there are a lot of projects using the MD5 so it would seems to make more sense to continue along that line of evolutionary development (otherwise the script might end up introducing changes to already established production pipelines and workflows - the main bone of contention with the Arx script incidentally - and not be used). And yes, most issues the current script has have been introduced/left in place inadvertently because it's been 'patched' to work with whatever changes have been made to Blender, so there's probably a lot of legacy stuff in there that needs to be cleaned out :-\

A general push for maintaining the script can be taken care of from this community as it's where everything MD5 is generally posted. There unfortunately isn't a specific individual whom can be tasked for this though; the available scripts have been authored or tweaked over the years by about a dozen people that have fallen by the wayside for various reasons (usually RL) for instance. So all I can say at this point is that should MD5 be taken on-board officially, we'd do our best here to ensure it's maintained as best as can be done.

For reference



Offline salamanderrake

  • Newbie
    • Posts: 9
Has there been any progress on this? And has anyone picked up on the md5mesh importer also?


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 2692
    • KatsBits
Unfortunately no.. MD5 inclusion (export & import) is similar to MD3 inclusion of bygone days, patchy and unreliable because of the constant breakages caused by Blenders internal changes. As both formats are somewhat 'exotic' and only supported by idTech out of the box, although ironically both formats get a lot of use in custom, educational and learning programming projects, there doesn't appear to be much interest in uptake.

In order for this to happen we'd need someone willing to dedicate the necessary time to making sure the baseline scripts for MD3 & MD5 are regularly maintained going forward. I don't code myself otherwise I'd already be doing it (and paying someone to do it wouldn't necessarily mean that being a more reliable process to completion).