Game Editing > Scripts & Support

[MD5] EXPORT script for Blender 2.6x (OPEN)

<< < (8/46) > >>

keless:
Yeah, I don't know how I'd access the other actions unless they were stored in NLA tracks. There's just no access to them through the API, unless there is some place I haven't looked.

BTW; I know bunny is somewhat low poly, but is he supposed to be that faceted, or am I exporting the normals incorrectly?

kat:
Ah yes, everything is fine, that's just the dynamic shadow volumes of the MD5 viewer doing that, the volumes don't 'blend' or 'soften' over edges (which you probably know already), so the edge of the volume tends to be hard, causing the wierd visuals - character models in idtech games generally have 'self-shadow' turned aff because of this problem.

They've moved datablock access again. In the Outliner view click the dropdown list and select "Datablocks", actions are listed in that view under "Actions" - it should be expandable with any animation Action present in the file being listed there. So the data is there, I've just no idea how you get at it to do export all of it in one go  :-\

keless:
Hrm, I thought I'd looked at that Datablocks mode of the Outliner-- guess I missed it. In my frog sample I can see the "rock" animation and the "action" (default that I though I threw away) in the data blocks. Interestingly it seems its the "action" action that has the rocking out keyframes in it, and the "rock" action is empty >.<

In python I can access it from bpy.data.actions['actionName'] so I can definitely iterate over all the actions. But in order to pull the actual animation data from it, I need a way to bind that action to the armature as the active action...

Looks like setting theArmatureObject.animation_data.action = bpy.data.actions['ActionName'] may work.
(Note: dont use theArmatureObject.data.animation_data -- seems to be an empty pointer)

I don't think there's any way to tell if an action BELONGS to an armature before you do this, so it may be error prone if you have actions that belong to other armatures in the same blend file, which may not be common for this usage anyway.

kat:
I can't see any connection either looking at the datablock info, there seems to be a lot of recursive data in each Action but nothing that identifies it as being parented to the rig. How about doing it the other way around... If you can pull the blocks, what about a checklist option type approach? That would act as a safeguard in respect to not exporting files the user didn't select? Would that work?

You'll need to go through the save >> reload >> save >> reload process to remove that dead datablock

keless:
Yeah that seems the best solution, I just gotta figure out the UI api necessary to do it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page