Notifications
Clear all

[Closed] FBX Import – Speed

I need to import hundreds of FBX files (most of which are < 100 KB) using MaxScript.

I use ImportFile (filepath.fbx) #noPrompt

So far, so good. However, it’s quite slow (~45 secs for 250 files). This may not sound like a lot, but for this use, I’d really like to get it below 10 – preferably 5 – seconds, since it’s something that may require several iterations for the user.

Is there any way to speed up the loading of FBX files? They are usually very simple files just containing a single mesh.

Regards,

Mikkel

9 Replies

could you attach a sample fbx file?

I could, but they’re just simple geometries, 1-3 editable meshes exported as an FBX file. Do you think it’s related to the FBX files? I suspected the import procedure, since it appears to have some overhead.

Let me know if I should still upload one?

2 Replies
(@denist)
Joined: 10 months ago

Posts: 0

i need the same as yours file to make a test…

(@mixx)
Joined: 10 months ago

Posts: 0

Alright, attached one (zipped) file below. Thanks!

the best what possible to get is ~20 secs for 250 imports.
all unexpected delays are caused by max window and max dialogs redraw. FBX import shows progress bar every time, and it hides all dialogs before and shows all dialogs after. it takes time.
the solution is:

set max window redraw to off

close all popup dialogs (or set their redraw to off)

run all imports

set max window redraw to on

force redraw…

there are several samples on this forum those show how to disable/enable window redraw.

Thanks for taking the time Denis!

Yeah your findings seem to match mine pretty well, it is simply a limitation in the FBX importer and how fast it’ll run.

I might test converting parts of the geometry library to another format – .obj say – to see if that’s faster. The downside is that some of these objects have Skin and/or other components that .obj doesn’t support, so those will have to remain .fbx

Still, it’s a convenience issue mostly – the script runs as expected, and no errors so far, so I suppose I shouldn’t complain (my animators might, though! heh!).

Hello Mikkel,

How many times a day is this script going to be run? If the answer is not many, the efficiency from having the script compared to not having it is considerable. So for me it wouldn’t matter if it took 45 seconds if it saved me hours out of my day.

If it is something that is being run all the time, I would perhaps setup a maxscript processing job on Deadline (if you have it) or a batch process.

2 Replies
(@dangrover)
Joined: 10 months ago

Posts: 0

I’m a huge fan of offloading stuff to the farm, and it’s worth noting that you can do that on backburner too using cmdjob.exe and a wee script.

Edit: To the OP, have you tried it with undo off? I’m not sure if importing like this would even be included in the undo stack, but that could save you time too.

(@mixx)
Joined: 10 months ago

Posts: 0

I have, it makes almost no measurable difference with undo on or off, there might be a small difference on a sufficiently large number of iterations, but I don’t think there’s much to be gained there – the vast majority of the execution time is the import function, which can’t really be sped up much – it doesn’t appear that the import goes in the Undo stack at all (probably for a good reason).

Turning Undo off for the actions I do post-import would probably provide a difference, but it’s a drop in the sea. Thanks for the suggestion though!