As requested I have put the requirements for XNA format FBX in to the official FBX exporter. Serveral options have been added.
The main requirement was that XNA needs the armature to be output as a Limb not a null. That is now an option on the UI on this script.
Instead of adding an XNA format option I have added several options to the UI to pick and choose which bits people need to include. I thought several of the changes would be useful to people who don't use XNA.
'Enable Rotation', 'Animations Only', 'don't use Default Take as the animation name' and a few others.
I've commented the file but the enable rotation needs explanation. Even if you set the rotation in the original drop downs to be the same as Blenders defaults the animations get messed up in XNA. So I have had to change the result returned in one method as well as setting the global matrix to Identity. That's why I had to add a specific enable rotation option.
In addition I have included a validate XNA option in the UI. This is only useful for people who use XNA but as there are so many exact settings they must make for the animations to work, I thought this was useful. I will understand if you don't want that in the official exporter and I would then just include an XNA specific UI in the Blender to XNA script folder.
Regards
John
2011-07-29
Description
Event Timeline
Updated the Dev page for the Unified FBX exporter with as much information as I could find about the differences between the various formats. Ideally someone who knows UDK and Unity will add more details to those sections. I have included a long list for the XNA requirements.
http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Import-Export/UnifiedFBX
Attached a slightly updated patch, it changes...
* invert enable_rotation to use_rotate_workaround, options like this should be 'False'.
* some indentation was changed for FBX output when it only needed to be changed for the write funcs.
* move add_action_to_filepath and validate_xna_options to private class methods and addressed one of the issues in you;re comments about set usage.
Review (issues numbered from the result of having my modified patch applied).
* Would have preferred if the "takes_only" option not be apart of this patch since it seems its not essential for XNA compatibility and makes the patch harder to review, Could you split this patch? - XNA compat at first, after add features which are convenient.
* 222: Making mtx4_z90 and identity matrix seems to be needed, but does this work for XNA and break other cases?, if its not needed perhaps it can be made an identity() every time?
* 466: Setting the matrix to be ob.matrix_local does not ensure its not rotated or scaled, Im not sure what you are trying to do here.
infact because the matrix is from "matrix = ob.matrix_local * mtx4_z90", and mtx4_z90 is an identity matrix I dont think this is needed at all.
* 2257: When armature_limb is enabled, normal empty objects are not exported, is this intentional?. looks like this could be moved out of the 'if'
* 2545 -> 2618: This block of code has been duplicated and edited but seems to contain very similar code, rather not do this if possible.
- Campbell
Reply 30-07-2011:
Thanks for showing me the correct usage in the code.
* The takes_only option was the first thing I added before making any other changes. XNA only supports one animation per file so being
able to output individual takes quickly and test the import quickly is important for my use of the script.
All it does is exclude large sections of the FBX output. It should be fairly easy to follow. In most cases it is the same code indented
one level. I have also tested with and without it a lot during testing of the script.
* 222: I do not know what mtx4_z90 does. I thought it was you that had written it! As far as I am concerned it breaks armature rotation which is why I set it to indentity() and disable rotation altogether.
I have tried several times to work out the maths for the armature rotation but failed.
* 466: See line 455 which in some cases changes it to matrix = par_matrix.inverted() * matrix
That does not work for XNA so I had to have the special case. I tested this several times and always XNA needs matrix = ob.matrix_local
* 2253 (was 2257): Yes it was deliberate not to export any nulls. XNA has no concept of an empty or null object.
I have changed it to allow for other applications. Nulls are included if 'EMPTY' is selected
* 2549... (was 2545...): I agree. I have removed the prior code in this latest patch.
* 2570-2509: Please check that my thinking is correct. Armatures are already listed by ob_all_typegroups at line 2448. Adding them at line 2570 as well duplicates the same connection!
I have tried several times and the site will not let me upload a patch. I get the eroror 'Missing Parameters'. If I can't find a way round it I will e-mail you the patch file.
- JCB
I've e-mailed the file to Campbell (ideasman_42) because I do not have permission to upload the patch here!!!!!!!
fbx_xna_unified-2011-07-31b_jcbdigger.patch
The 'takes_only' option has been removed from the patch.
Bug fix included: I have now excluded some sections where they are not applicable if 'MESH' or 'CAMERA' have not been selected as output types.
I have added additional validation to the UI so that it is not possible to output animations without the armature. Campbell, thanks for the syntax help on that today.
Regards
- JCB
Committed r2205
*** Changes ***
* armature_limb is always on now. removed the option, rather then mix up NULL export with this option, I rather just rely on the fact that 'EMPTY' export opion is disabled with XNA compat mode.
* The patch clears lists that should never be set, rather then do this kind of defensive programming, do sanity checks that warn when an invalid case happens.
* bone.blenMeshes was behind "if 'MESH' in object_types:" checks, but is never set when meshes are not exported.
*** Removed ***
* removed 'use_default_take', option can be added back but was a bit mixed up in other animation changes which Id like to review separate.
* remove 'all_same_folder' sets the name to its stripped file, this can be done by setting 'Path Mode' to 'Strip Path', rather XNA sets this then add a new option.
* add_action_to_filepath, the first object in the scene is arbitrary and may not even be exported - if export selection is enabled.
* changes to ANIM_ACTION_ALL exporting logic I'd like to review separate.
* __init__.py: validate_takes_options(...), This assumes actions are only assosiated to armatures, but object animation is also supported.
Regarding takes as files: I'd rather see this as a new Batch Mode, currently we have Scene/Groups, but could also have Actions - giving each action a file.
Think this is a better workflow and doesnt change internal exporter code, This can be done by looping over all actions, finding compatible armature and exporting each in a file.
.interested to know you're opinion.
The is logic in this code which assumes animation is only for armatures which isnt the case, this is one of the reasons I didnt want to apply changes to actions just yet.
Leaving this report open, if you find time here are some things to look into.
- Test the new version in XNA, ensure it works at least on basic level.
- Make XNA validate set the stripped path option.
- Make a patch from the changes you made from changes to action exporting, giving some info on why the changes are needed, a bit better commented.
- Investigate adding an option to batch export actions as files (I could look into this too).
Excellent. Exports to XNA.
Wish I had seen Path Mode before. It does exactly as needed. I had ignored it thinking it was something to do with Batch mode. I'll change the UI and move it above Batch Mode in my next patch, I think that will help others or perhaps it's just me :-)
Sorry, I thought I had commented the code sufficiently and typed an entire wiki page of notes:
http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Import-Export/UnifiedFBX
and put a link to that in the script at the end of export_fbx.py with all the other comments :-)
I even added a litte info about Unity and UDK which I don't even use. Perhaps you could update the wiki with anything you know.
I was not aware that the script supported object animations. I was trying to be too clever. You are correct the armature validation is wrong.
Batch mode for actions is an excellent idea. Most XNA Devs would prefer that.
In my opinion, the only essential bit missing from the script is the 'use_default_take'. As requested I will submit that as a separate patch. Hopefully today but weekdays are less predictable!
XNA respects the action name. If the take is called 'Run' or 'Walk' XNA uses the string 'Run' or 'Walk' in the code. It is very easy to manage and merge all the takes and get them right. XNA can only read the first take in the file. If every single one is imported with the name 'Default_Take' it is not possible to code to separate them!
It would be necessary to use a manual process!
Thanks
- JCB
I've e-mailed the file to Campbell (ideasman_42) because I still do not have permission to upload the patch here!
fbx_xna_unified-2011-08-01b_jcbdigger.patch
Minor changes to the UI to move the order of options slightly.
Trying to keep the most frequently used options near the top.
That means the XNA compatible options are near the botton with Batch options last.
Renamed the 'Rotate Fix' to make it clearer that it is only needed to fix animations.
* 2485 -> 2551:
I have decided to REMOVE 'Default_Take' from the exporter instead of making it an option.
I can find no reason for it being there! Anyone who needs the name 'Default_Take' can add an action with that name.
Most FBX files I have looked at use the name 'Take_001' instead and the only reference to 'Default_Take' is always about Blender.
As mentioned above, in my opinion, removing 'Default_Take' is essential to the XNA pipeline.
I searched using Google and I even searched the FBX SDK.
The nearest reference to it was in a May 2010 Readme for the 2011.3 version of the FBX SDK.
http://infiniteengine.googlecode.com/svn/trunk/depends/fbx/readme.txt
In that the behaviour was changed so the 'default take and current take are no longer set.'
Other people struggling with the name 'Default_Take':
Unity user(s) (might be the same person):
http://www.blender.org/forum/viewtopic.php?p=87860&sid=274cb607a61b141a214ea15e94b02c25
http://blenderartists.org/forum/showthread.php?223123-quot-Default-Take-quot-with-unity-engine-after-fbx-export-from-blender-2.58
XNA users commenting on the work round for 'Default_Take':
http://forums.create.msdn.com/forums/t/66942.aspx
* was 2490, 2506 -> 2516: I have removed these because they were pointless.
The action_lastcompat was only set at the same time the count was incremented.
Therefore the following if condition was only ever met if action_lastcompat was also still empty!
Regards
- JCB
Reply to the last patch: fbx_xna_unified-2011-08-01b_jcbdigger.patch
* Apply changes to __init__.py with very minor edits.
* Regarding removal of "Default Take", I think this is fine as an option but default action is useful for cases where you dont necessarily have armature animations, and want to export object animations from the start frame to the end frame set in the scene.
This allows the FBX exporter to export all animations "WYSIWYG" from blender to another application and I rather not remove this.
* "2490, 2506 -> 2516", double checked this is still working in the way it was intended and it does.
To test
- add a single bone,
- animate its rotation for eg.
- remove the action.
- export the FBX
I tested this and added a print to show that action_lastcompat is set.
Could you update this patch to remove default take only?
- Thanks
I've e-mailed the patch file to Campbell (ideasman_42)
fbx_xna_unified-2011-08-02a_jcbdigger.patch
* was 2490, 2506 -> 2516: Sorry, I did not allow for that possible scenario.
That information was also important for the other changes that follow.
Added use_default_take to the UI.
* 2485 -> 2534: Use either all actions or the current action. processed the same way.
Only the 'Default_Take' option is treaded separately and only included when chosen.
* 2536, 2549: Renamed 'Default Take' to 'Default_Take' so the filename and the take name are the same.
Not important but I like things consistent.
* 2549 -> 2570: Slight changes to use the action name for the take name and the take file name.
Regards
- JCB
Applied:
fbx_xna_unified-2011-08-02a_jcbdigger.patch
With only minor changes.
- reverted the Default Take -> Default_Take part, mainly because this was written to copy the FBX SDK.
the filename just does...
file.write('\n\t\tFileName: "%s.tak"' % take_name.replace(" ", "_"))
Otherwise its basically the same.
- Do you think this is enough consider the FBX exporter XNA compatible?
- If so could you remove io_export_anim_mesh_xna?
- Is there anything else from the original patch that needs including (can the patch be closed) ?
Regards
- Campbell
Yes it is definitely XNA compatible.
Before posting this I exported and loaded a few models in to XNA using this latest version. Works well.
This patch can be closed.
I am please you have left in the XNA validation method it is so much quicker than remembering all the required options.
I will remove io_export_anim_mesh_xna.
If you get a chance to do a Batch actions export that would be a bonus. What several XNA devs do, me included, is to parse the 'All Actions' file as text and split it in to separate FBX files with one take in each. It's a bit cumbersome but works.
Regards
- JCB