Created a page in the wiki:
http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/File_I-O/DirectX_Exporter

Added script to Trunk.
Thanks Chris.

Hi Chris,

when I choose to export "All Animations" only the the frames between the start frame and the end frame are exported although I have more frames afterwards and that's good this way. To reduce the unnecessary file size in my case though I'd like to export "Keyframes Only". Unfortunately if i choose this one, all frames are exported even the ones I did not intend to export. Now it's pretty exhaustive to delete all the single frames since there are a bunch of those and also I would like to keep all animations in one blender file. Is there a possibility that you could enable the "selection" feature of the "All Animations" option for the "Keyframes Only" option as well?

Kind regards, Ray

Hi Ray,

I'm glad you brought this to my attention. That's actually a bug, and it shouldn't be very hard to squash. I'll post back when I do. Thanks again!

Cheers, Chris

Hi Chris,

Sorry to say I am experiencing problems with the Exporter with Blender 2.56a beta (as expected with beta software!), on 64bt Win7 Pro.

Often, when I click 'Export DirectX' Blender crashes. The x file is written, however it is incomplete. All the sections seem to be present but it is missing the texture coordinate data:

MeshTextureCoords { //Cube_001 UV Coordinates
24;
} //End of Cube_001 UV Coordinates

Hope this helps

@Simon: Hmm, this is very strange. I just tested it out and was able to export a simple UV-mapped cube successfully on 64-bit Windows 7 Professional using Blender 2.56a Beta r34076 (which is the revision that's available from blender.org). If you'd like to email me the .blend file along with the exporter settings you used, I'd be happy to take a look.

@Ray: I think I've fixed the issue. Sorry I forgot to post back.

@Chris: Thanks Chris. Downloaded the new blender with the new version and it works nicely now. *thumbs up* Now it would be nice if you could add two features:
1. An option to split animations in blender into multiple animation sets in the .x file. At the moment I have to export the model over and over again for every animation set. Afterwards I have to edit the file manually and cut out the animationset part and paste it in the main file where all animations (+ mesh + bones etc.) are gathered. This is ok if you only have let's say two animation sets but imagine you have 5 or more of those and multiple models where you have to do this. It gets pretty exhausting.
An elegant variant would be to add the feature in Blender to have multiple animation sets. It would be useful even if you did not use the DirectX exporter. If I oversaw that there is in fact this option please correct me. A workaround would be to pop up a dialogue before exporting or implement a new dialogue in the export options menu. Would be nice if you could give those animation sets names right there so you don't have to manually edit it in the file.

2. "Wintermute Engine Compatibility". This especially means adding a template textblock at the beginning of the .x file related to AnimTicksPerSecond that in fact enables this option in the Wintermute Engine. It's this one:

template AnimTicksPerSecond {
<9e415a43-7ba6-4a73-8743-b73d47e88476>
DWORD AnimTicksPerSecond;
}

If this template does not exist in the file the AnimTicksPerSecond (Frames controlling) option does not work, at least not in the Wintermute Engine

Maybe there are other differences too that would optimize the .x file for the Wintermute Engine but I have to find those out. For the time being those two mentioned points are the more important though.

@Simon: Are you sure it crashes? Because while the exporter works Blenders appears to be frozen but that's perfectly fine. Just wait until you see the viewports again and it's completely exported. Check the "Verbose" option before you start the export and look in the console what it's doing. Depending on your model the export might take up to several minutes even on middle class PCs.

PS: The SVN Download link is dead.

svn link fixed

@Ray:
Interesting suggestion, hmmm. I think that providing this feature through the exporter might be a bit of an overstepping of the exporter's responsibilities. Perhaps I could have the exporter go through each object it plans to export and create a list of each action used in the scene. Objects that have actions with similar names (like AnimSet.001 and AnimSet.002) would export in the same animation set (AnimSet). Would that accomplish the goal?

As for your second suggestion, it should be no problem to insert that template at the beginning of the file whenever "Include Frame Rate" is selected. The engines that already know the template will ignore it, and those that don't will benefit. Thanks for bringing that to my attention. I'll get on that and post back (hopefully I'll remember this time. :P).

The crash seems to be related to trying to export objects created with Blender 2.49, even though they seem to open and render fine in 2.5. If I rebuild the mesh with 2.5, it exports fine.

Still want the 2.49 blend file?

Nope, I lied. The newly created blender model exported without any texture coords, and now it wont export at all (same crash).

Blender files coming via email

Well ironically, the 2.49 file you sent opened and exported repeatedly without any problem, UV coordinates and all. The 2.5 file was the one that crashed at first, although I have managed to get both files to export reliably. The problem is that in the 2.5 file, the UV coordinates have not been initialized; a problem that arises from unwrapping the mesh and then exporting without leaving edit mode. All I had to do was return to object mode and everything exported correctly. The 2.49 file you sent was already in object mode when I opened it, which leads me to believe you may have left edit mode, saved the file, and then sent it to me without trying it again, as it exported fine when it got here.

The python in the background that causes this problem goes something like this: When you unwrap an object, it creates a UV layer on the mesh. However, when the script tries to read the UV coordinates for each face in the layer, the list containing them is empty. You can observe this by typing len(bpy.data.meshes["Sphere"].uv_textures["UVTex"].data) into a Python Console window and pressing Enter. The result should read 0. Then, if you leave edit mode, place your mouse in the Python Console, press the Up Arrow to avoid typing all that again, and press Enter, it should read 224, which is the number of faces in the mesh.

As this is a quirk of Blender itself, there's not a whole lot I can do on the exporter's side. However, I think it would be good to add a warning to the console output in Verbose mode. I hope that helps :)

...Okay... I didn't expect that.. when I returned to edit mode and ran that line of code again, it returned 0 again... perhaps there is an issue with UV coordinates and edit mode. Everything exported correctly while in object mode, however.

Ah, thanks for illuminating that quirk. I never would've spotted that one.

@Chris
to 1. : I just discovered that there is in fact the possiblity to have multiple animations separated in one Blender file. Personally I just find it a BIT complicated to make two of them. Way too much clicking around, seriously. Why can't you just select the frames with a nice selection tool like box selection and say "Define as animation set" followed by a prompt to put in the name for the animation set? No! You have to mess around with the Timeline, the NLA editor and others and I still don't have a clue how to rename tracks and/or actions. Or why the heck I even need tracks and why actions alone aren't sufficent? When I select an action strip I can't just play that one. No, I have to mess around with the timebar. Seriously that's not what I call intuitional :X. The exporter could just pick up the names of the animations sets and either export them to one file (as needed with .x files) or multiple files where the animation sets' names can be used again. MUCH research to be done on what could have been simple...
So to return to the .x exporter: I have a character model and there are two animations I need to have at first: walk and idle. Currently those are one thing that consists of frames. Since the animations require the same body parts (or most of them) I don't suppose the object thing will do it. Now once I'm finally able to divide the keyframes into two groups, be it tracks or rather actions :S, and name those, the exporter should be able to take those and export them into two animation sets.
I'm going to do some more research here on how to achieve the division into two groups. Anyway tell me if you want to take a look at the model.

to 2.: sounds promising :D btw. the wintermute engine somehow works faster if you put the AnimTicksPerSecond declaration right at the beginning instead of before the animation set.

Hey there,

I made a model with a material name that contained a nonstandard character (!) and the export tool failed to strip the character from the .x file upon export. Upon compiling my project, visual studio spit back a parse error on the .x file. Removing the exclamation point from the material name in the .x file seemed to fix the issue.

I haven't investigated this very thoroughly, so I don't know what other disallowed characters there are, but I guess it would make sense to strip out everything but letters, numbers, and underscore in any name.

Thanks! The exporter seems to work great other than that.

~Dennis

@Chris Foster,

a bug was reported in the bf tracker: [#27263]
https://projects.blender.org/tracker/index.php?func=detail&aid=27263&group_id=9&atid=498

closed that report since it should be reported here, linked the report to this page.

Thanks Campbell.

Indeed it was a bug, and I've just committed the fix.

@Dennis: Hi there, sorry I missed your message. I'm glad you brought that to my attention. The exporter should now successfully strip "punctuation" characters out of all names inside the .x file and replace them with underscores. I hope that does the trick! :)

Hi!
Since your script is now in bf-extensions\' svn (contrib|trunk) we have deleted the current attachments to avoid that end-users could reach this page and get the wrong version of your script.
Note that your script may have api changes or small maintenence changes applied in SVN.
Please retrieve your script from SVN before updating SVN to avoid mis-versioned scripts.
Thanks!

if texture file has relative path TextureFilename {"file.jpg";} section is not writen in .x

Hi Hubert,

I just tested this and the path was exported properly. Can you give me some more info or maybe a .zip with .blend and .jpg?

it's look like I have diffrent version 2.1.1 for 2.57 i found it somewhere, probably thegamecreators.com but there is other same link as here :) i will download 2.58 and check

*but there is same link as here

in 2.58 .x exporter do the same thing as earlier, exporter from svn didn't start on my computer ;/
here is file with blend, textures, materials .x and exporter
http://www.szczuro.com/files/test.zip

Ah, I've solved it now. I had always tested the path export by simply referencing a texture that was in the same directory as the .blend file. However, when a file is relatively referenced inside a folder, as in the case of "//textures\\sword2.jpg", the "//" freaks out os.path.basename(), causing it to return an empty string. I just added a [2:] to the filepath to cut off the offending characters. It should work fine now.

As for the current svn not working, that was a weird mistake somehow on my part. My last commit appears to have reverted the exporter a ways back. It's all fixed now. You should be able to use the svn download link to get the working exporter now. Just drop it in 2.58/scripts/addons as usual. :)

Thanks for letting me know about the issue. :)

it works now and exports properly ;) thanks for fast fix ;)

Hi,
Due to changes to the api including the merging of bmesh, several addons are outdated.
Please, if you are the author of an addon check your script with blender revision 44256 or newer.
That is builds made After blender 2.62 official release.
I would ask that updates be made to your addon before the Blender 2.63 release.
6-8 weeks away.
This allows time for the api to become more exposed & bmesh to stablize furthur.
If you need help, drop into irc freenode #blenderpython or #blendercoders & feel welcome to ask questions.
At the time of 2.63 release, scripts that are not repaired or in active developement will have their tracker page marked "Closed"
this will not affect your links to the tracker, similar to closing scripts in 2.49b, the page will be still availible & can be re-opened.

Thanks for your understanding & patience during these Exciting Times.
Brendon.

broken in 2.64

Seems to be working here... what exactly is broken?

hi, there seems to be anther version of this in contrib addons, could you let us know the correct version for release please.

Oh, yes, the version in contrib is a WIP. The version currently in trunk is still the correct one until the contrib version is mature enough to replace it. I'm in the process of rewriting the addon to be cleaner, more extensible, etc. Is contrib not a good place for WIPs? I'm sorry if I misunderstood the purpose of contrib and would certainly move it to a more appropriate spot. :)

Hello, I'm having problems with the exporter. A lot of faces are missing from my mesh after the export. At first I thought it had something to do with the NGons, but some parts that use NGons are displayed normally. I attached the screenshots and the final version of both the *.blend and the *. x files. I have 12 WIP copies, some of them are corrupted in the same way, some of them aren't, I can send them if you need those. I'm still new to Blender so it's completely possible that I screwed up and there is nothing wrong with the exporter. In that case I'm truly sorry and I would ask you to at least give me the direction if you have the time, because I have absolutely no idea what went wrong.

P. S. Everything worked fine with a more simple model that I used earlier.

Hi there,

My first guess is that there are normals issues that won't show up while your model is flat-shaded in Blender. The problem that you experienced later is likely the result of back-face culling done by DirectX (DirectX probably thinks certain faces are pointing away from the camera that aren't). To check, you can enter Edit mode, select everything, press W, and then select Shade Smooth to use smooth shading (W > Shade Flat will reverse this). If the normals are incorrect, you should get weird dark seams in places. Another way to check is by bringing up the side panel with N while in Edit mode and under the Mesh Display group, click the face icon under Normals. This should make all of the faces in the model show their normal with a cyan line. This line might be pointing inside the model on some faces and outside on others if there's an issue.

To fix all this, select everything in Edit mode, and press CTRL + N. Tadaa! This recalculates all face normals so that they are pointing out of the model. Very rarely does Blender get it wrong, but if it does, you can use W > Flip Normals. I hope this solves your problem!

So there are indeed normals issues, but the automatic recalculation isn't working to fix them. I've never actually seen Blender fail like this. There are a few problems with the model though, possibly problems that are keeping Blender from successful recalculation. For instance, there's an extra vertex on the shoulders and there are a couple of loose edges and vertices scattered throughout the model. Even after fixing those it still didn't work for me, so I'm not sure what the problem is. It might be best to get a clean start on this model, or maybe researching some more conventional modeling techniques. In any case, you can still correct the normals manually by selecting the inverted face and using W > Flip Normals. Feel free to send me an email if you need more help. We've all been new to Blender once! :)

Hi,

I'm trying to export some meshes into a .x file, but the file seems to be corrupt.
I can't load it neither with the D3DX-Method D3DXLoadMeshFromX neither with the Direct-X Utility-Tool "MeshView".
However it did actually work fine with a prior version of the exporter.
I can't really tell what's wrong, because I don't have any clue about the file format. (I'm quite new to DirectX ;))

Hope you can help!

Hi there,

Sorry about the problem, it's nothing you're doing wrong! I accidentally introduced a bug a little while ago that caused files not to load. I have since fixed this bug, but in a bit of awful timing, it seems the package maintainer had already grabbed the bugged version of the script to be added to the release. Sorry about that! If you can get your hands on a more up-to-date version of the exporter, you can just replace the files and everything should work fine. You can find a link to the exporter inside Blender's extensions repository above. Let me know if you need more help!

Hi,

there are some problems here :D
As a starting note, to test i'm using an x importer i've written in C#, like a year ago.
I do alot of integry checking/postprocessing on the data and bones stripping: i only keep true skin bones and their parents.
So, to animate, i'm truly only using positions/rotations as they are exported by your script (i verify that scale is always 1.0).

The major problem:

1)
The major problem is when i export full animation (i always had this problem, i'm using your exporter since Blender 2.60).
Test file: http://www.2shared.com/file/z9OHnlNY/rig.html
I bake action first, with clear constrains options checked (this option seems needed to export the legs animation correctly) (((***Curiosity: if i remember correctly i never needed to bake action on older Blender versions, is it something that changed recently?))).
When i check the exported file, the head is following the torso in the animation (it should not).
I had those sort of problems when i was writing/testing my importer (with Blender 2.60, that's why my ***Curiosity).
I solved those problems exporting keyframes only (the animation is perfect in this case).
Since Blender 2.67 this option is no more here, and this is a major problem for me :D W
Would be nice if you manage to fix full export or, better, readd export keyframes only option, or even better, tell me if i'm doing something wrong :D.
As a side note, i don't think it's a problem related to my importer, i'm sure you can anyway easly verify this in your testing pipeline.

Minor problems:

2)
Exporting full animation write alot of keyframes that i don't want/need (i prefer to set my keyframes and handle interpolation between them in my code).

3)
Exporting full animation include the mesh as an animation bone (not critical, i can strip that with code).

4) (Blender 2.67+)
Right handed system option, i was using this (not critical, i can fix this with code).

5) (Blender 2.67+)
All the materials are exported now, even if not used (not critical, i can fix this with code).

6)
Better data roundtrip: i usually modify your script adding "!r" everywhere (instead of ":9f" / ":8f"), plus some changes in the materials output (i can share my code if you are interested, updated for 2.66a).

Thank you for your time!

This task was automatically closed as archived as part of migration, because it was determined to be no longer active.

The authoritative list of addons is on the wiki, we no longer have a report for each addon to track bugs and updates. Bugs can be reported individually and assigned to the addon developers. See the Addons project page for more information on the workflow.

The left/right handed coordinate system option and y-up/z-up option seem to be missing when I go to export.

On most models it handles these the way I want them to, but on certain ones, for whatever reason, it refuses to switch to the proper coordinate system on its own.

I've also had issues with the left/right-handed coordinate system option. On models without armatures, it seems to have the right effect. However, when I export models with an armature and animations, not only does it not have an effect, but the model is sideways (Blender's z-up is pointing in the y-up direction in my software), and it's mirrored on the x-axis. Any ideas there?