GSOC 2022 – Draft Proposal Fast Import / Export for selected formats (STL / PLY)

Contributing to Blender Summer of Code
1

Hello everyone,

I created a proposal draft, kindly find attached below:

Please feel free to provide any feedback.
I will submit it later this week.

Thanks in advance.

Cheers.
Sam

1 Like
2

Looks nice!

Some random thoughts:

  • The draft of the proposal feels like some parts of it are from year 2020, back when new OBJ exporter/importer was still in development. Now two years later, there’s some more knowledge, for example “use fprintf” is not a great performance advice :slight_smile: Rather, perhaps the new native exporters should use similar technique as used by the current OBJ exporter code, which is to format text into a buffer (using “{fmt}” library), and then flush the buffer into the file “once in a while”. That also enables multi-threaded format buffer generation, something that’s also used in the OBJ exporter.
  • I don’t think there is much to share code-wise between STL/PLY and OBJ exporters. Maybe some? But it might also be that there’s “none” which is also fine.
  • However… while “let’s write it in C++” might be a way to achieve “best possible” performance, that also has downsides (C++ is inherently less safe, more verbose, you’d end up with more code to maintain, etc. etc.). Maybe the existing Python exporter/importer could be optimized instead? E.g. by using Numpy for large data arrays, and similar techniques. Probably could look into code of the glTF2 exporter/importer for inspiration – that one does not feel terribly slow.
  • There are various “work in progress” efforts by various people at either extending the STL/PLY support, or attempts at writing them in C++. Before starting doing serious work on this project, might be worth looking at them, as to not duplicate the work.
4 Likes
3

Thank you very much for this feedback.
I was definitely not aware of the usage of libfmt in Blender (of which I am a huge fan).

I will check the glTF2 exporter, and the work done by other people and update the proposal accordingly.
I do agree that optimizing the python code will be more straightforward than a full re-write.

Thanks again.

2 Likes
4

Hi! I’ve recently been in the PLY importer adding expanded compatibility and vertex-color point cloud loading (Github: Here ). Those are working and I’ll be submitting them as two patches. But, I haven’t touched performance at all yet. I do have a fair amount of cProfile data and various benchmarks if you might find those useful? Having come from a C++ background I also tend to want to rewrite everything in it, but @aras_p makes a very solid point in that quite often faster Python makes for fewer headaches. Our PLY importer takes a rather cumbersome route to get in data, but has the huge advantage that it correctly parses all the data types coming in. For meshes, the add_face() function is the serious bottleneck - loading the same file as just points runs ~60% faster with no intentional optimizations. I haven’t even looked at the exporter yet :rofl: