← All ideas
  • Published 8 Jul 2018

Speed up .obj import/export

The current speed of importing and exporting obj's into blender is pretty slow in blender compared to other applications.

Rough estimate - Comparing time to import 4k polygon obj on my system. Please note that more dense obj's are quite common (eg > 1 million polys)

9.3 sec import to blender 2.79

1.1 sec import to zbrush 2018

The current obj import/export addon in blender is written in python, which is the reason for the code to not run as fast as one would hope for. Converting the code to C or Cython would result in a significant speedup.

This is a bit outside my area of expertise, but it seems like it would be possible to convert a .py to cython code. See this post on stackoverflow. stackoverflow.com/questions/5105482/compile-main-python-program-using-cython

Obj is very common and reliable (and non-optimized because of ASCII :-/ ) when it comes to transferring models from different 3d applications. Even though Alembic is a better file format, it is not supported in a lot of applications. Therefore it might be a good idea to fix up the code for obj import/export.

97.1%

Development Status: Open

Upvote 33 Downvote 1
d.bystedt
8 Jul 2018

13 Comments

miclack30

there is already a patch: developer.blender.org/T54863

2
FloTasser

Hey guys, any news on this? I would totally love to get this. Paired with Pixologic creating an official GoZ Link to Blender 2.8 that would be a dream come true.

1
garilhe.nicolas

I'd also love to see some improvement for the obj i/o including:

  • a scale factor parameter in the import settings (it already exist in the export one).
  • the conversion of ngon to tri (ZBrush create weird topology when importing ngons)
joshlobinder

I have noticed that obj import/export prints a lot of stuff to the terminal. Perhaps removing the printing behavior will speed things up. I would do this myself but the code uses some sort of logging object, so it's not as simple as commenting-out print statements. This might be an easier change than implementing in C or Cython

joshlobinder

@joshlobinder: Well I tried out disabling logging on the obj import and export. turns out the time difference was negligible between logging and no-logging versions of the code. This result is with only one test, but I'm already convinced.

d.bystedt Author

Including a twitter thread where Obj import/export is discussed

Check out @3DBystedt’s Tweet: twitter.com/3DBystedt/status/1015228373361098752

SPYReox

Would be great to Drag and drop files into Blender and also Multi import with Shift Selecting instead of doing it one by one.

sreenivas

@jason.nezar: May be you should create a separate proposals for these one. I think they are important.

1
fayscrin

This is a very important aspect. Perhaps for me personally this is the only significant minus of the blender. And it's strange enough considering that even in small programs such as for example knald, imports / exports are faster.

kromar

i agree on the speed but not on the c conversion, this removes the possibility for users to easy modify the exporter to their needs which with a vague format like obj is really needed.

d.bystedt Author

@grauer.d: the reason for the lack of speed is that it is written in python. Python doesn't run very fast compared to other languages like C, Cython, C++

kromar

@Daniel Bystedt: im sure program execution wise this mathers but maybe there is some other layer that makes importing/exporting slow other than just the language, like the way the importers are written. but hey im no programmer and cant see where the slowness is coming from. would be nice to have a benchmark to see the difference. i know the collada importer is natively implemented so maybe someone can do some comparison on big models with that one.

however the question remains, how would we be able to modify the importer/exporter without the need to build blender?

EDIT: just looked up some basic speed comparisons so yes seems to make a big difference notes-on-cython.readthedocs.io/en/latest/std_dev.html (probably not fully accurate when applied to a io scenario)

moniewski

This is much needed. Multi-milion polygon meshes can take several minutes to load when other programs do that in seconds.