KatsBits Community

[MD5] export add-on for Blender 2.63+

nemyax · 58 · 137961

0 Members and 27 Guests are viewing this topic.

Offline 222464

  • Newbie
    • Posts: 6
Ah, thank you! I re-weighted it over and over, but just couldn't get it to work. I finally got it to work by removing the vertex groups. You are my hero!  ;D

I am looking forward to the next version!



Offline motorsep

  • Jr. Member
  • *
    • Posts: 75
@nemyax: Is there any particular reason, besides perhaps limited knowledge of Blender's API, to not listen to designers and artists to create sane GUI and sane workflow for MD5 exporter ?


Offline nemyax

  • Newbie
    • Posts: 38
motorsep
Apparently the reason is a different opinion of what a "sane" workflow is. I am prepared to explain what few design decisions there are in this script. What is it you're not comfortable with?
Incidentally, who are the aggrieved designers and artists whom this exporter has inconvenienced? And why don't they look elsewhere?


Offline motorsep

  • Jr. Member
  • *
    • Posts: 75
Workflow should be simple - select meshes (models can have several surfaces), select armature, export. No need to mess with layers, or have only single mesh, etc. Just look at the old exporter from 2.49b

Yeah, as usual, programmers see sane workflow one way and artists see it another way :)

I personally not comfortable with constraints you impose in the exporter on how scene should be made, how animation should be done and how it should be exported. The workflow is fundamentally flawed.

"They" have been looking somewhere else and got all new GUI done. Just waiting on part that converts Blender matrices into MD5 format matrices. It's just taking way more time than expected.


Offline nemyax

  • Newbie
    • Posts: 38
Workflow should be simple - select meshes (models can have several surfaces), select armature, export. No need to mess with layers
Why the layers
You generally don't need all of your bones in the MD5. Much of the armature in a moderately complex setup is helper bones, which need to be filtered out. What you suggest results in all of that fluff ending up in the export result. This is not what I would want, but if you're OK with that, just put them all in layer 5. That's one keypress and one click.
The messing bit
There's a script included in the readme to help stuff the MD5 layer.

or have only single mesh
This exporter does not have the one-mesh limitation.

I personally not comfortable with constraints you impose in the exporter on how scene should be made, how animation should be done and how it should be exported.
Tough. But then, how are those constraints more severe than in other exporters?


Offline motorsep

  • Jr. Member
  • *
    • Posts: 75
Why the layers
You generally don't need all of your bones in the MD5. Much of the armature in a moderately complex setup is helper bones, which need to be filtered out. What you suggest results in all of that fluff ending up in the export result. This is not what I would want, but if you're OK with that, just put them all in layer 5. That's one keypress and one click.

Are you aware that active bones layer can be exported? Leave it up to artist to have a layer active with bones he wants to export. It can be any layer, as long as it's active. If you load MD5's from Doom 3, you will see that there are bones in them that ideally should not have been exported.

The idea that artist has to put bones into layer 5 is ridiculous, because everyone has their own habits and workflow. I might want my export bones to be in layer 1 and someone else likes to have them in layer #last.

The messing bit
There's a script included in the readme to help stuff the MD5 layer.

That's besides the point. Making awkward workflow and saying "go read docs" is not a user-friendly approach.

Tough. But then, how are those constraints more severe than in other exporters?

There are no other exporters besides one for 2.49, where you can pick out what you need to export, where you need to export, etc. etc. It's more productive, it's more intuitive, more artist friendly.


Offline nemyax

  • Newbie
    • Posts: 38
Leave it up to artist to have a layer active with bones he wants to export. It can be any layer, as long as it's active.
I, the artist, prefer to have only my control bones showing up at all times. What I don't want to do is switch layers for export.

The idea that artist has to put bones into layer 5 is ridiculous
No. It's mischievous and quaint.

I might want my export bones to be in layer 1 and someone else likes to have them in layer #last.
Put them in 1, 5 and #last. What's the problem?

one for 2.49, where you can pick out what you need to export, where you need to export
And here you can't?


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 3145
    • KatsBits
nemyax, as the script was originally geared toward Arx it's inadvertently imposing that particular workflow in places where it may be at the expense of what has been years of evolutionary incremental development which is firmly based on idtech4. If the purpose here is to produce a general MD5 script then these are valid concerns. If not, and you just want to release "Arx MD5", then you can happily ignore what's being said/requested. But, it's important to make sure potential users clearly understand this otherwise topics like this can quickly descend into flame-fests.


Offline nemyax

  • Newbie
    • Posts: 38
If the purpose here is to produce a general MD5 script then these are valid concerns. If not, and you just want to release "Arx MD5", then you can happily ignore what's being said/requested. But, it's important to make sure potential users clearly understand this otherwise topics like this can quickly descend into flame-fests.
This topic has generated a few perfectly valid requests (batch export, better vertex group handling) and useful bug reports. I am willing to work on those, and more feedback is always welcome, of course.
However, where I don't agree with a proposed implementation, I try to give my grounds for refusal; I will not be shamed into making such changes.
The exporter is essentially "Arx MD5", but can be (and apparently has been) used generically.


Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 3145
    • KatsBits
For the sake of clarity it might be worth updating the initial post to let users know the script is indeed an "Arx MD5" exporter; the workflow arrangements that cater to that seem to be the main bone of contention here so it's best to make that known to save problems with users wondering why things aren't working the way they're expecting relative to previous scripts.



Offline kat

  • Administrator
  • Hero Member
  • *
    • Posts: 3145
    • KatsBits
Cheers. Tidied the post a bit (formatting was a bit wonky) and added a link to your main project site for you.


Offline nemyax

  • Newbie
    • Posts: 38
Fixed vertex group bug
The exporter now ignores vertex groups that have nothing to do with exportable bones.

Forbade vertex weights set to zero
This may be temporary, as I'm in two minds about it. On the one hand, zero weights are garbage data probably left behind due to oversight. On the other hand, they are harmless unless a vertex has nothing but zero weights. Such vertices could be automatically declared unweighted if necessary, but MD5 doesn't support those. Which would you prefer?
  • Keep the blocking behaviour, it's a useful optimisation reminder (or I may have left something unfinished).
  • Enough with the constraints, make the script silently nuke the zeroes without bugging me (but I'll still have to clean up manually in the zeroes-only case, sigh).
  • Something else.
Readme: added note about unapplied transforms
I haven't been able to reproduce the failure that Spielkarsten reported, but keeping the armature's object transforms applied is generally the Right Thing (at least in the MD5 export context, where you can't creatively abuse armature transforms for effect). So this is advised in the readme.

Download: http://arxendofsun.solarsplace.com/downloads/io_scene_md5.zip


Offline 222464

  • Newbie
    • Posts: 6
Hmm, I think I have the same problem as Spielkarsten. When I first tried to load the animation, the frame data was all messed up and the animation was deformed. I first thought it may be a problem with my model loader, so I loaded it with AssimpView and got the same results. I then cleared all armature transformations, and was able to correctly run the animation.

It only happens with an animation, the bind positions of the bones are fine.