There was a trick used with Blender 2.7x that allowed exporting a single FBX containing LODs for static mesh. Life was good 
Now with Blender 2.80 that trick no longer works and working with LODs became painful all over again 
Has someone figured out how to export a single FBX file with static mesh containing LODs from Blender 2.80, so that when you import it into UE 4.22 / 4.23 you get a single static mesh with LODs ?
Hah, apparently I forgot to check Empty along with Mesh in the Blenderās FBX export options. All good now - old trick works 
Sorry for false alarm :o
AFAIK, I had to mod the export script to actually take LOD_ as the empty to look at.
Also, Iām still not 100% happy with the inside nomenclature, but here is the script portion since I have it open
def fbx_data_empty_elements(root, empty, scene_data):
"""
Write the Empty data block (you can control its FBX datatype with the 'fbx_type' string custom property).
"""
empty_key = scene_data.data_empties[empty]
null = elem_data_single_int64(root, b"NodeAttribute", get_fbx_uuid_from_key(empty_key))
null.add_string(fbx_name_class(empty.name.encode(), b"NodeAttribute"))
val = empty.bdata.get('fbx_type', None)
#empty groups = LODS
if empty.parent is None and empty.name.startswith("LOD"):
null.add_string(b"LodGroup")
else:
null.add_string(val.encode() if val and isinstance(val, str) else b"Null")
elem_data_single_string(null, b"TypeFlags", b"Null")
tmpl = elem_props_template_init(scene_data.templates, b"Null")
props = elem_properties(null)
elem_props_template_finalize(tmpl, props)
# No custom properties, already saved with object (Model).
Though Iām not 100% sure I have published it - this should also be part of my Curves Plugin - if itās not, revise from line 563 of export_fbx_bin.py
http://mosthostla.com/gamedev/ue4curves/
Wow, Blender sucks againā¦ Using 2.81a and nothing works when it comes to exporting LODs into FBX. 
Something is totally off and it could be either Blender or UE 4.2x or both or I am not checking some checkbox.
If I load FBX with LODs to Akeytsu, for example, I can clearly see LODs are there, in the FBX. If I set number of LODs in the import settings to the number of LODs in FBX, I get FBX imported with LODs, except the file is imported 3 times o.O
WTF ?!
Here is .blend file for Blender 2.81: UE4_LODs_test.blend - Google Drive
Here is FBX with LODs: UE4_LODs_test.fbx - Google Drive
Note that Blender 2.81 doesnāt need any hacks to export with LOD groups (I tried it as-is and with hacks and resulting FBX is always the same). Also, this FBX loaded into another software, with LODs.
Ha, I think itās Blenderās BS after all. Here is FBX exported with 2.79b: UE4_LODs_test279.fbx - Google Drive
While the order of LOD iterations is wrong (thanks to Blender), the file imports properly as single static mesh with 3 LODs.
Not sure what you are doing, but my plugin was updated and works correctly as of the last time I tested .81
you just need to properly name your meshes and your empty- which is a bit of mental workā¦
Ok, finally I got to the bottom of it all!
Basically, Blender 2.8x is all good to go with FBX LODs as-is, without any modifications. However, I made a modification to FBX exporter I totally forgot about - to make it not exporting Armature as root bone. The way it was done (either someone suggested the fix or I found it on the Internets :rolleyes: ) was interfering with export of Empties. Which resulted in screwed up FBX file when it comes to LOD groups.
All good now (thatās what I said last time, didnāt I :o ).
If you dont know what you are modifying thatās bound to happenā¦
the root bone hasnāt needed special treatment since before .78ā¦
It always needed special treatment, unless itās named āarmatureā instead of standard āArmatureā. In that case UE4 automatically removes it on import.
Obviously, I work with blender and UE4 a lot. Enough to make 2 working plugins.
I have literally never had any issue at all with a custom armature and the root bone on stock engine/blender combo since a whole year and a half ago.
Same here, you are not special 
I am betting you didnāt use root motion animation. I never even thought about Armature until I had to use root motion in UE4.
I use it constantly on complex imported mocaps. Again, never an issueā¦
If you are curious, you can probably find the bug tracker where Montagne fixed it. Iām positive its documented, since some changes to the export IO files for it are commented.
So, has anyone figured out a fix for LodGroup index order being incorrect? I have a traffic cone with the base model plus 3 additional LODs. However, they important in the following order:
LogFbx: Display: Triangulating static mesh Cone_Medium_LP_LOD1
LogFbx: Display: Triangulating static mesh Cone_Medium_LP_LOD0
LogFbx: Display: Triangulating static mesh Cone_Medium_LP_LOD2
LogFbx: Display: Triangulating static mesh Cone_Medium_LP_LOD3
As you can see, LOD1 is imported as the first LOD and LOD0 as the second. (No idea how or why it does that) and I canāt figure out how to make them the correct order.
The _LOD# naming is for my own benefit as the FBX Importer for UE4 doesnāt care about the naming at all and only the āLodIndexā
If there is no way to control the order of LODs from Blender, then this entire process is pointless and you have to revert to the manual LOD import method.
I donāt have any issues (so far) with 2.81a and LODs order in FBX, but here is a workaround that requires engine hack: SDG Blog
UPDATE: I successfully modified the engine source to load lods based on the mesh name vs the index order Blender decides to place them in.
Follow the normal process with parenting to the empty and ensure they have ā_LOD#ā on the end. Code is in the following thread:
I had implemented that but it still ignored the naming and used the LodIndex. Although I may have misunderstood the naming convention because ChildNode always resulted in null and fell back to LodIndex.
Iām also using 2.81a and sometimes the LOD order is correct and other times, like with my current object, LOD1 always imports to LOD0.
So I need to figure out how Blender is indexing them into the parent Empty and try to modify it in some way.
**Update: **The engine hack was indeed because I named the objects wrong. Simply āLOD0ā and not as a suffix. Iām not a C++ programmer, so Iāll have to figure out how to search as a suffix instead of the whole name.
Still though, Iād like to figure out how to fix the index order so an engine hack isnāt necessary if the LOD order comes out wrong.
Hi, Iām independently developing Brigge for Meshes, a paid addon + plugin combo which lets you avoid FBX and all the workarounds that come with it. We just added LOD support thatās easier to set up & manage in Blender, and export to Unreal. Weāve had early access customers since January, and after months of feedback and fixes itās pretty solid. Check out our LOD docs and release history to see if it fits your needs.
My blender plug in has supported this and curve export for nearly or more then a year.
Create an empty, call it LOD_meshname
shname.namw the meshes
meshname_01
and alter the numbers how you wishā¦
when you export using the plugin, click on the empties to make sure they are parsed, and thats that.
Are you saying that hack in the blog post I linked doesnāt work for you?
I have been fighting with the LOD order myself, and finally, figured it out. You have to add the empty and the LOD meshes to a new collection and it will fix the LODIndex for them. GOD, it took forever to figure that out. No documentation I could find said anything about that. I had about given up and noticed the only difference between mine and Enlightened was the collection and thought I may as well try it.
Selected the empty and the LOD Meshes, right-clicked on them, and selected āNew Collectionā. Reselected the empty and meshes after they moved to the collection and exported them. Told UE4 to reimport the mesh and boom order fixed. WTH.