I have tried to import a single hero asset with 500 000 polys and it seems UE4 editor crashes while it trys to import it. Task manager shows program as inactive … maybe it takes just very long but this loading time is not viable.
Is it normal that a 500K poly asset takes forever when i have a nvida gtx 970 (not the best but not the worst card ether)? and a quadcore 4x 3,8 Ghz ?
When i want to import assets which polycount is viable with my hardwaresetup ? 40 K ? 4 K ?
For games I’d keep 100k as an upper limit, but for realtime graphics the lower always the better.
Try to replace some of the geometry detail with normal maps and so on.
the engine can handle it, i’v imported mesh’s of over 1 mil poly before, it just takes ages 45-60+ mins. such high poly models are normally not meant for real time engines, any extra detail going from 100k to 500k is minimal (unless its a huge tree or something with 1000s of branches) models in that range of polys are more for normal map baking onto a low poly or for VFX.
It was a huge tree .
If i get a gtx 1080 would it cut the load time in half compared to a gtx 970 ?
The gpu contributes to absolutely nothing when importing that thing into the engine.
If the editor doesnt close itself or pop up some sort of crash window. Just leave it doing.
Itll do something eventually.
But yeah, you might wanna re-evaluate the way you modeled that tree. 500k for a single tree is quite outside the scope of reason - at least for an average game.
Its the hero tree , there is only that one giant tree in the middle of the map , the rest of the objects have way less polys 
I have 20 GB of RAM , is that not enough ?
Zbrush and blender load the asset with no problem at all in under 20 sec, why does UE4 editor take more than 20 minutes for the same asset ??
Shouldnt they be at least in terms of loadingspeed for assets comperable,even if they are used for different purpose otherwise?
Not really, because the ue4 does very different things with your asset compared to zbrush or maya.
One thing I just realized, make sure you have autogenerate collision volumes turned off in import menu. Else yeah, itll take forever to figure out collisions for your tree.
is there any difference using .obj or .fbx file format ? Is one faster than the other ?
UE4 has to process the mesh when it imports, which takes a lot of extra processing time. If you don’t change any of the default import settings it’s even worse because it will try to generate lightmap UV’s which adds even more processing.
It’s likely though that you don’t need a mesh that high poly, unless it’s like a giant tree like Avatar then most likely you’re overdoing it. There’s tree systems like Speedtree that optimize stuff like that for games.
I would split the tree up into several seperate models.
For example the trunk, and each main branch. If needed, brachnes can be split further.
Another upshot of this is that you dont have one drawcall anymore handling the whole tree.
If split into smaller meshes, the branch on the “far side” of the tree can be clipped…
If you create sockets for the branches on the trunk, you can then also easily swap out branches.
That way, your tree stays even, to some extent, configurable…
Oh, and you dont have to cram the entire tree into on big texture…
Spliting up the tree and unchecking the collision calculation are good ideas.
If i split up the tree in a group of models, how can i make sure the objects in the group maintain their correct distance to each other while i import them one by one.
Can i import them as group, i dont want to play lego with all the branches …
And what about the fileformat, is there any difference between .obj and.fbx anymore in terms of importspeed and usability ?
Either export them with a common pivot. That is: Have the branches “floating” in your 3D app. When importing in Unreal, they are at the correct place, offset from the origin.
Another (in my oprinion, better) way are sockets.
Here you would set your branches at the origin in your 3d app, just like the trunk.
In the static mesh editor, create sockets for the branches.
Wrap that up in a blueprint that places branches where the sockets are.
If you later decide to move/rotate a branch a little, just move/rotate the socket…
I found FBX working good so far. As it is the preferred format by UE, I see no point in experimenting with OBJ.
The processing time has nothing to do with the file format. Reading that data is trivial in comparison to the extensive calculations done on it, as others already mentioned.
The engine may handle importing a mesh with high poly, but too many of them, and your engine will just slow down to a crawl.
so high polys must be used sparingly.
In the UE5 (2021) we able to import any highpoly mesh from CAD or sculpt programs without any limitations?
I want to keep the same quality of skeletalMesh without decreasing file size and for now I’m stuck at this point.
Maybe someone has compiled source code of UE4 that allow to import large meshes like that?
Some of the stuff that UE4 does on import will not be necessary with UE5, however, I don’t think that the stuff they’re doing with high polycount assets extends to things like skeletal meshes (characters)
900k test
As a number 900K in the year 2020 is not a lot or even the use of 8k textures but to give an educated response there is need for more information.
What application are you importing from?
What is the planned purpose, intended use?
Are you importing morphs?
In general yes it can take a long time to parse an FBX due to the amount of data the host app sends to the format and what you chose to import into UE4.
In the example on the other hand was imported using the DS to unreal 4 bridge and took no more the 5-10 minuets with out morphs
The process that takes by far the longest is triangulation. So you can save yourself a ton of processing time by triangulating a mesh before import in a dcc.
by contrast, generating lightmaps is not an intensive. However disabling the option and always making the lightmap on the 3d program saves import time as well.
Other than those 2 things, there isn’t much else to be done. Perhaps use Alembic for intense geometry morning, since its kind of what it was built for.