Is it just me, or is 2.72 now exporting with -x as forward? (2.71 had +x has forward)
Really! I think I need to download Blender in the next days…
-x forward (or +x, for that matter) seems unlikely. If I load factory settings on 2.72, the FBX exporter defaults to -Z Forward Y Up, which is, I believe, the correct translation to export in UE4’s coordinate system. I believe that’s been the default for many releases.
Yep, default settings in Blender seem to work fine for static meshes. Blender and UE4 both assume “-Y” to be forward, the only difference is “+X” direction. That might give you some issues with animated skeletal meshes from Blender. But I’ve not seen such issues yet.
Are you using the binary are ACSII exporter? And what export settings are you using? (Do you have apply transform checked?)
If you open that up in the UE4 static mesh editor, is it still aligned?
What if you add an armature to it?
Are you using 64 or 32 bit blender?
I’m asking because something odd is going on for me, if it is working like that for you.
really hope blender forgets about that one tbh, ‘game’ style controls are really bad for doing anything with models, look at ue4’s physics asset editor for example.
what should happen instead is that ue4 adopts blender style controls.
Hi, Tontow.
I use binary fbx with default export settings exept for the scale which I set to 100 (in export settings, not in the scene itself). Mesh is aligned the right way no mater if it is opened in static mesh editor or placed into the level. With armatures it’s a bit more complicated though. As I said forward axis in Blender is matching what UE4 is using so if you check “Use Time 0 Pose for Ref Pose” everything should work fine. I’ll see what else I miss and will update the info here.
There’s no difference wether you use 32 or 64-bit version of Blender regarding the export process. The only reason to use 32-bit Blender is if you’re running a 32-bit operating system.
If you’re still having issues with Blender - let me know.
Cheers.
I exported another model that had its front facing -X and when I imported it, it had it’s front facing +X. Everything is rotating 180 for some odd reason.
This started happening when I started to use the official 2.72 release. It was working fine in the 2.72 preview builds.
Here is the resulting FBX.
And here is a screen of the model in blender.
Note: I hit restore defaults in the fbx exporter and I’m using edge smoothing groups.
Tontow, why are you use using -X as your forward direction? It’s wrong for both Blender and UE4. They both assume -Y to be forward direction. You can check it in UE4 if you switch to Front view.
Because for some strange reason it ends up the correct way around. (Look at the resulting FBX file.) And I have no clue why it is doing this all of a sudden.
Does anyone know how to setup the IK bone constraints for the HeroTPP model? They aren’t setup on import.
I deleted all of the imported IK bones and applied the IK constraint to the hands/feet, set the chain length to 3, and left the target blank. Works pretty good. I can still import into unreal and use the stock skeleton/animations.
Edit: Ended up keeping the imported IK bones because the free Animation Starter Pack’s jogging blend space uses them.
The default orientation in UE4 is X+ (Forward), Y+ (Right), Z+ (Up). Open any character blueprint or any function that queries the forward vector for verification. This AnswerHub thread gives you an explanation and references to the documentation.
If you’re using any other orientation for reference in the engine, you need to fix that. It should also be noted that an imported FBX from another 3D application is not guaranteed to be the same orientation unless the application has the same coordinate system as UE4. Exporting a character from Maya will give you a 90 degree offset, which will have to be adjusted in a character blueprint. Even Epic does this with their characters, you can look at the HeroTPP mesh. The default orientation in UE4 is X+ (Forward), Y+ (Right), Z+ (Up). Open any character blueprint or any function that queries the forward vector for verification. This AnswerHub thread gives you an explanation and references to the documentation.
Now with that in mind, if you look closely at AntonBoiko’s post you will see that Blender and UE4 has two different coordinate systems. Blender is right handed, Unreal is left handed. This means that one axis in Blender either has to be inverted (-X) or to use another axis as reference for forward axis before conversion. I recommend working in the forward axis in the application of your choice, in this case Blender, and then “live with it” that there’s an offset. Trying to fix the offset in Blender will only cause severe issues down the road. I speak from experience trying to do this in Maya many years ago in UDK/UE3, which today is causing a lot of problems in a game project I was involved with. Can’t give you the details, but trying to fix this issue can cause more harm than it solves and should not be done. Just live with the fact there’s going to be an offset after conversion between coordinate systems.
It’s not that hard to set the same rotation values on every character you export, it’s only an inconvenience.
If I mixed up some facts, please correct me. 
In 4.6 we are getting a transform override in the importer https://forums.unrealengine/showthread.php?49646-Engine-Features-Preview-10-16&highlight=engine+news
coming from C4D where I get the same 90˚ rotation as from Maya, I am really looking forward to this and I agree, stick with your DCC app’s idea of Forward.
That’s going to be a great feature.
Upgrading from 2.71 to 2.72 broke the smoothing export on my computer. Meshes that were completely fine now get full-mesh smoothing as if the normals were not exported.
I tried using Edge split and autosmooth, exporting as face or as edge smoothing, no matter what I never have the normals ingame.
I’m having the same issue - were you ever able to solve it?
move to 2.73 and select faces or edges on export, remember to check every time you export as for some reason it always reverts to none