[Bf-committers] import_obj.py - Reimplementation

[Kursad Karatas]

Hi

I think that it will be great if the obj importer has been taken for a 
new ride. Recently I needed to import an .obj that was around 3.5Gb into 
Blender. Naturally, as you might expect Blender(Win 64bit) was not able 
import it. Rather it just froze up for a long time. I am not sure if 
that is a limitation with the mesh memory or a limitation of the Python 
version in use.

I am sure most Blender users  will never need to import meshes that are 
that big (at least for now), but in big and serious projects big data is 
always a possibility.

thanks

k

On 01/02/2013 08:16 PM, Isaac Lenton wrote:
> Hi
>
> A few days ago I was using Blender's import_obj.py script to import a few
> rather bulky OBJ files into blender (200MB and above).  On my little system
> it takes about 2 minutes for every file.  I have been looking into improving
> this script with simple optimisation, splitting the work amongst multiple
> workers and changing the amount of memory the script uses.  Some of these
> methods are successful, but the results are only minor.  I did manage to
> reduce the loading time of the 200MB file to 1 minute 40 seconds.
>
> Although a quicker method for importing my data into Blender would be to
> use another format, I quite like the OBJ format and I am "in the mood" for
> optimising.
>
> In order to significantly improve the speed of Blender's OBJ importer I can
> see a couple of options:
>
>      - Implement the importer straight in C/C++ and build into Blender.
>          I think this option is probably undesirable considering it takes
>          away one of the really nice things about Blender's add-ons (the
>          add-on part!).
>
>      - Keep the implementation in pure python.
>          Also, in my opinion, undesirable.  The Python is great, but it can
>          slither only so fast.  (Also, what are your opinions on using Python's
>          multiprocessing module in import scripts?)
>
>      - Keep the python script but implement the most expensive methods in
>          a C dynamic library.  This option will keep the interface to the
>          exporter exactly the same, the module will still be able to be
>          imported using pythons `import` and Blender will not even notice
>          the difference.  The library would be placed in the same directory
>          as the script (scripts/addons/io_scene_obj) and the script would
>          simply add the line `from . import TheNewLibrary` at the start.
>          Downside: using plain C and python can be painful (but fun).
>
>      - Keep the python script but implement the most expensive methods in
>          a boost::python C++ dynamic library.  Same as above.
>          Downside: Boost::Python libraries have a big overhead.
>
> I find for my own code, when size is not important, I prefer the last option.
>
> I am interested to hear any opinions on the above ideas, and any ideas anyone
> may have on generally improving the speed of Blender's importers.  Are any
> of these options Blender compatible (as in, could they be included in the
> official release)?
>
> Thanks,
> Isaac Lenton
> (ilent2)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
Kursad Karatas
http://portfolio.plecxus.com/