[Bf-committers] import_obj.py - Reimplementation

[Xavier Thomas]

Hi,

One other solution you didn't mention and I thinki would be better: C/C++
add-ons.
Would be cool for custom nodes/textures/sequencer effect too.

Xavier


2013/1/3 Kursad Karatas <gonderici at plecxus.com>

> 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/
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>