Rawalanche, can you please make sure you are on the latest versions. This was addressed a couple months ago. Also the official documentation should all be updated, so there shouldn’t be anything recommending a 0.01 scene scale anymore. There might be some unofficial tutorials floating around recommending the 0.01 scene scale, because that is what was recommended at the release, but now 1 or 0.01 should work just fine…
The official documentation is here
If you see anything in there that is outdated feel free to submit a PR to change the documentation. After you have completely removed both addons, restarted blender, and installed the latest versions, and are still experiencing issues feel free to report the bug as an issue to the github with step by step instructions/images/files on how we can reproduce the problem and we will take a look
I should have the latest version if the latest version is 1.4.13. I did the most rudimentary test possible. I have just installed the addon and did not change any default settings. I have just selected a single static mesh in Blender, and exported it to Unreal using the tool. The mesh is a building which has 4775x3460x2385 centimeters in Blender, and ends up being size of 47x34x23 centimeters in Unreal. I do not understand how this could pass any QA testing.
Blender interprets its internal system units as meters while UE4 as centimeters. So the conversion here is necessary. You can’t just tell Blender users “Well, ignore what Blender tells you and interpret meters in Blender as centimeters”.
Here’s a video:
Aside from incorrect scale, also the forward axis is incorrect. Blender’s forward axis is -Y where as Unreal’s is +X. This is absolutely crucial to get right as well, because Blueprint and C++ functions like “GetActorForwardVector” rely on it. You don’t want to get a forward vector of your car actor just to get the left or right side of the car mesh.
And of course, any ugly workaround like parenting a mesh under root scene node rotating in 90 degrees are not acceptable, for many reasons, one example being Unreal’s native movement components rely root component being the one which checks for collisions, and if you have something like a capsule collider as your blueprint root, you can’t really change the orientation of the capsule, as root component does not have any rotation within the blueprint component editor concept. I am writing this just in case I’d get answer that the proper forward axis is not important.
Lastly, in the video, you can see me changing units in Blender between centimeters and meters, to show you that in Blender, this setting only changes how the Blender’s internal system units are interpreted and displayed in the UI. It does not actually change scale of the scene in any way. Only the Unit Scale value does, and adjusting that one breaks big portion of Blender’s tools, as Blender simply wasn’t designed with changes of that value in mind.
The main point of having any kind of “bridge” tool is to address exactly these issues. So that user doesn’t have to mess with cryptic FBX settings to find the right combination, both on Blender’s end and Unreal’s end. It makes me all the more confused given the fact that the recent addon version actually added FBX settings right to the addon preferences:
This is the absolute opposite of what should be done. The point of having some sort of bridge exporter is that these things are sorted out for us. It should be one click always works solution. Having actual exporter settings to mess with should only be relevant if the import/export target software is not known. But here, you have the advantage of knowing the exact conditions in both output and input software, so these settings should never be a factor for the end user.
Bottom line is that if I have a 20 meter wide, 20 meter deep and 10 meter tall thing facing what’s considered a “Front Axis” in Blender, I want to end up with a 20 meter wide, 20 meter deep and 10 meter tall thing facing what’s considered a “Front Axis” in Unreal.
EDIT: One more thing that makes no sense to me. In the Path section of the preferences, there string fields for paths that the tool creates in the UE project content folder. Why are these global? Let’s say I work on a robot and a tree in Blender. I certainly want to have tree meshes in completely different location in content folder structure than the robot parts. Is the end user workflow really intended to be that the user keeps going deep in the addon preferences every single time they work on a different asset to change the global export path? This must be very frustrating and lead to numerous errors causing the asset to be unintentionally exported to a wrong folder because user forgot to do a chore of going to usep preferences and mess with global, scene file independent addon settings. These paths are unique to assets, so they should obviously be saved as the .blend file property, not as a global addon preference.
There are multiple factors in your blend file or unreal project that could produce the results you are seeing. I suggest starting with a clean .blend and unreal project and using that to retrace your steps.
Also the settings are global until saved, then they are loaded from the .blend file scene data, so you can save settings into .blends just like you are saying.
And as much as we would all love a one click button, that is not realistic. There are quite a few use cases for different fbx export/import scenarios, that is why they are available to the user.
Also just want to clarify that this is a free addon that we released to the community, there is no QA other than the community. This is a project that relies on contributions from the community. The tools are still very young, and we are not able to contribute a lot of dev hours to these tools, because we have other internal projects our developers need to work on. We do however welcome PRs from people who are interested in improving the tools.
At the end of the day, if you find value in the tools, use them. If you don’t, than don’t. Also if you have other questions, please look through existing issues, or open a new issue on the github. I monitor that more often, and there are other users on there who can help you too.
Well, this on its own is a problem then. If the Send to Unreal tool is dependent on some adjusted user I/O settings on either Blender end of Unreal end instead of completely overriding them by its own, then that’s the issue of the exporter, not the user. That should always be considered a bug. Seriously, having to check if I did not turn something on or off along the way to make sure the sending even works correctly is just not feasible workflow.
In that case they absolutely do not belong in the addon preferences part of the user interface. The user has no chance of knowing this very obscure behavior, which is not obvious from the UI in any way. This should belong somewhere in the .blend file itself, ideally in the right viewport sidebar where such tools and settings usually reside. Also, how do I then check what the path is currently set in the given .blend file?
You are right, not one button, 3 buttons actually. There are 3 unique workflows: Static Meshes as individual files, Static Meshes as as single file, and Skeletal Mesh.
That’s it. Everything else is a symptom, not cause. People usually want/need settings simply because it’s automatically assumed and expected the export result will be wrong and there will need to be some button pushing and knob turning to get the result right. But that simply does not apply if you have known, specific export software and known, specific import software. In that case, there’s very little excuse to offload this workload onto user.
That’s a fair point. Sorry, I did not know that. For some reason this toolset had “official Epic thing” aura around it I perceived. At least, I don’t remember ever directly hearing this is unofficial, community project. Especially since there were multiple official Epic livestreams just about the Send to Unreal tool.
Anyway, while I also do not have much time to spend on this and contribute significantly, for what it’s worth, I am attaching my script toolset in Blender I built for this purpose. I do not have enough time to separate just the Export to Unreal portion of it, but it’s quite simple script, and the function itself is called “Export Socketed Static Mesh FBXs”
Assuming the import settings on Unreal’s side are in order (I would have make sure it is always done so if I was making a complete Send to Unreal bride, not just Blender Export script), according to this picture:
The script will then, with a click of a single button, assuming the export path is set, export entire hierarchy of static meshes, creating socket for every child named after the child. Every static mesh will have correct size in unreal and will be correctly facing the front axis.
So it’s as simple as having a hierarchy of static meshes, no additional helper/dummy objects are needed, then specifying path once, which is saved with the .blend file, and then clicking one button.
Once in unreal, it’s super easy to reassemble the entire hierarchy as every mesh has correctly positioned, oriented and scaled sockets of their supposed child meshes. So all that’s needed is parenting a mesh component under its parent, resetting all transforms to zero, and choosing a socket of the exact same name as the imported mesh itself.
Now, the reason I am complaining when I fixed it myself is that I originally thought this was Epic’s official initiative. I would love have to drop maintaining my suboptimal solution in favor of something official, and much better done. I am aware of how incredibly bad Blender’s FBX exporter is, so I kind of understand why it’s so hard to get this right. But I was actually hoping this initiative was about some new, better exporter rather than one just relying on Blender’s broken FBX exporter.
Anyway, perhaps you can scavenge parts of the script I attached and use it to improve at least the static mesh portion of the Send to Unreal, as at least that one should be one click solution. I am aware that skeletal meshes are a whole different level of affair. Feel free to use it in any way you want. It’s not much more than just loop for creating the sockets, resizing the static mesh hierarchy to match Unreal’s transforms and then calling the FBX export operator with predefined settings. But it’s enough of a proof that it can be a one click solution.
If this limitation was fixed/removed, it would be possible to export entire static mesh hierarchies as a single, self contained FBX file, which would be imho much nicer and cleaner. Right now unfortunately, my tool exports the meshes as separate files just because of this limitation.
Hello
I’m using the Unreal to blender and ue2rigify for exporting my custom character from blender to ue4
It was hard but I some how managed to overcome the initial tchnical issues.
There is an issue I have and that is I rigged my character with rigify and animated in blender.
Everything is fine in blender BUT after exporting to UE4 the weapon (which is attached to the right hand and left hand is parented to it as well) overlaps with the left hand. In other word the offset (rotation and location related to the hands) is not a constant value and this is troublemaking.
It is so important for me and I’m here after at least 2 months of working researching watching tuts and etc.
please help me with any thing.
Hello,
I have the same issue, I have both Epic and Github accounts connected, but still having a 404 error.
Is there an alternative way of finding the addon?
Is this just for artists who are banging away on a test model and want to see it in unreal w/ 3 clicks instead of the 5-6 clicks + 2 key presses of fbx export->import?
This seems overly complicated to get meshes where they need to go in UE4. Maybe if Mesh Folder setting had a keyword to use blenders folder hierarchy to determine where every meshes final folder is at in UE4? e.g. “Mesh Folder” = “/Game/{BlenderFolderHierarchy}” creates every folder in ue4 like blender folder hierarchy and puts each model in it’s rightful place.
In the end I suspect this is just meant for someone else’s workflow. As I’m sure we all know, everyone’s blender/ue4 habits are wildly different!
I just tested this “official” plugin now as well, and wow… all I can say is that it’s definitely not made for architects wanting to transfer scenes over (I guess that’s what Datasmith is for, but that only has a non official plugin).
First off, having an entire scene dumped in a folder named “untitled_asset” (note the singularis) speaks volumes about the very narrow workflow that the creators of this had in mind.
Second, and I know there’s a “preserve origins” setting for this, but altering all origins and then forcing the user to manually filter by meshes and drag them into the scene, completely ignoring all empties and any hierarchy is just… again, wow.
I’ll stick with the non-official plugins. Seems the community did it better (and even the previous skeletal rig community plugin creator had to fight to get his scaling correction included with the official thing, since that issue was initially ignored… which was kinda amazing to see go down).
I would just like the toolset
Why do I need a github account?
Is there a link to just the addon somewhere
I have Blender 2.92
and UE 4.26.1
I really don’t want a github acct.
I’m having some problems with Send To Unreal (1.6.5):
1a. I was expecting that meshes would be grouped by Collection on export, for example, if I have:
Mesh (Collection)
Head (Collection)
Head
Hair
Eyes
Teeth
Body (Collection)
Torso
Legs
That on export, Head, Hair, Eyes, Teeth would all be exported as a single “Head” skeletal/static mesh, and then Torso and Legs would be exported as a second single “Body” skeletal/static mesh. This is not the case. Either they all export as individual meshes or I can choose to “combine child meshes” in which case everything is exported as a single mesh. This makes exporting modular mesh parts extremely difficult, almost impossible, in fact.
1b. Similarly, I was expecting that while they would export as a group of different skeletal meshes, that because they’re all rigged to the same skeleton, only one skeleton and physics asset would be generated. Instead, a new skeleton and physics asset is created for each exported mesh… Again, in the case of modular assets, this becomes difficult to manage.
As a genuine bug (I believe), I’m having issues in several places where material ID’s seem to be scrambled or merged. I have hair parts that all share the same material ID in Blender, but in Unreal, some of those hair parts will be assigned to the head material ID for some reason… Examples below:
