First off I really don’t know how to categorize this issue; if its due to it being a hard problem to handle or its because of inefficient code… or perhaps a memory related bug!
Simply describing what I’m trying to do is a import of a FBX file at 14MB of size which contains 2million polygons into UE4.
For 3dsMAX 2015 it imports this FBX file at 10 seconds and for unreal engine it takes about an hour…!
Scene is exported to FBX and DWFx from Revit 2015. Opening the same scene as a DWFx file (2MB) in Autodesk Design review takes 3 seconds, just to have an idea of the scene not being that complex.
Settings I’ve tried in UE4 are many but I guess the most important one is “combine meshes” which i have tried both on and off.
During the 1 hour import UE4 ram usage jumps periodically between 900MB and 1200MB and at the end of the import process it goes above 7 gigs, because of that UE4 sometimes crashes.
In the Trello roadmap there is an “Import FBX into level” card, that has made me curious if it will fix this issue or not and if it will have some nice features.
Basically what I want is to import this scene quickly and also being able to reimport/update it quickly as well.
The “import procedure” and “update procedure” between Revit → FBX → UE4 should be minimal, meaning that when the scene from Revit is updated it should be a simple procedure to export FBX from Revit and then reimport the FBX file in UE4 keeping materials, uv etc. Much like how “Link Revit” and “Link FBX” works in 3dsMAX.
As an idea I think importing the scene with multiple meshes should have a dummy object created, this dummy object located at 0,0,0 world space in fbx scene and all the meshes parented to it.
So moving or scaling the dummy object in UE4 should affect the child meshes. Also this dummy object could(?) be used as a placeholder for remembering settings, materials, uv and other things that you have done in UE4 for that particular FBX import, for when you want to re-import and update that scene in UE4 from a newer FBX scene version (new export from Revit). Essentially keep what you have done in UE4 and get the Revit updates.
Why? Because this kind of projects are basically alive and ever changing until the final part is physically placed on the building, and we see that having the possibility to iterate and have UE4 as a real time tool would be beneficial.
Btw fast iteration is the key of UE4.5 isn’t it? This feature is cool as the C++ hot reload feature right? …yeah that’s my strong selling point… at least I tried =P
To the curious one at Epic I can provide both the FBX and DWFx files exported from Revit.
As far as scaling goes, the way your exporting all of the objects would have their pivot in the same location, so you’d easily be able to scale them uniformly between each other.
Also, I don’t know what the file looks like, but I’m going to guess that it’s probably not optimized for a game engine, if you’re looking for good realtime performance then you’d probably need to do some extra work on the file. 2 Million polygons is a massive amount, but it’s not surprising if it’s not designed for a game since a lot of architecture tools don’t have that in mind.
FBX is a workhorse/shovel that works best within an edit in place work flow and not so well or managed as you would as being native to a given application.
FBX is not your typical export format but rather a structured DCC wrapper that can pad out with extra info that has to be sorted through by the host application and if export as full that’s a lot of data. I took a quick look around as to what can be stored but could not find anything short and sweet but it’s a lot of data.
I’m not surprised that importing is choking.
Best practice is to export by selection which is just an additional step added to importing everything from a single file but gives you better control of iteration and source control management.
When successfully importing this scene after an hour it runs with good performance. Optimization can be done but in my case I don’t have to spend time on it thankfully.
About exporting one mesh per file, what matters is the process. Exporting one mesh per file means that I would have to first import the FBX to 3dsMAX and through scripting re-export the FBX scene (that came from Revit) containing 1000+ meshes one mesh per file and having each mesh pivot at scene world space. Haven’t scripted with maxscript for years but the new python scripting looks nice so It is probably doable. Although I would like to skip this scripting part and have UE4 handle everything.
FBX might be as you said a workhorse/shovel kind of format to handle, but in this case 3dsMAX imports the scene in 10 seconds and UE4 in 1 Hour. This means that in my particular case UE4 FBX import is 360 times slower! Something must be wrong
I made a test with two new FBX files, I call these FBX files “1x” and “10x” where “10x” is roughly 10 times bigger than “1x”.
1x has 3784 objects and a file size of 2.9MB.
10x has 39272 objects and a file size of 39.3MB
Se table below for more details.
UE M = UE4.5 with Multiple mesh import settings (Combine mesh = off)
UE C = UE4.5 with Combine mesh import settings (Combine mesh = on)
MAX = 3dsMAX 2015
Diff Cmp = Difference in comparing
Import in seconds, Win7 SP1 64
[TABLE=“class: grid, width: 500”]
**1x
** 10x
10x/1x
Diff factor
**Notes
**
**Objects
**
3784
39272
**10.378
**
**Size (MB)
**
2.913
39.345
**13.507
**
**[Import]
**
Should be
between
**MAX
**
3
38
12.667
10.3x-13.5x
UE M
7
380
54.286
10.3x-13.5x
UE C
14
1740
124.286
10.3x-13.5x
[Diff Cmp]
Ideal factor
UE M/MAX
2.333
10
4.286
~1x
UE C/MAX
4.667
45.789
9.812
~2x*
UE C/UE M
2
4.579
2.289
~1x
*not counting for combine mesh optimization
Summary and key comments on importing FBX:
3dsMAX has a more linear performance hit based on size and objects.
UE4.5 scales horribly on both where combine mesh is on or off
UE M compared to MAX is 2.3 times slower with a 3MB file and 10 times slower on a 40MB file
UE M scales 54 times slower when file is 10x bigger, in this setup it should be between 10.3 and 13.5 times slower.
UE M in this setup didn’t use swapfile, pagefile was turned off in Windows.
UE C uses above 24GB memory (around 30GB I guess) for importing a 40MB FBX file!
UE C scaling slowdown factors (from 1x-10x) import example is due to paging/swapping, so better memory management/usage might improve import.
I believe that combine mesh could also be optimized for small files, 2x slower (on 3MB file) doesn’t seem right.
I still say something is not right with UE4.5 FBX importing process.
Please read what people say. You are trying to explain your point and push it but Unreal 2,3 or 4 is a game engine and there are rules to use it, like many things in the computer and real world. Trying to import 2 million polygons is insane, maybe its fun for you or maybe you are trying to test Ue4, I don’t know.
At the end of the day, Unreal is a game engine and 3D max is a rendering software amongst other things, so please do not compare apples and oranges.They are different things.
You are absolutely right when you say it doesn’t work, I am not suprised, nor would anybody who has a habit of using the game engine would be. No one who properly uses the engine would do that, so… what is your point?
In game cut scenes,arch vis product vis game prototyping, art and concept there are many scenarios where it would be convinient to drag and drop mill poly geometry into a project so yes unreal engine fbx import is STILL broken
…yeah that’s my strong selling point… at least I tried =P