[Bf-committers] [GSoC 2018]Idea -- Fast Import / Export for selected formats

[Campbell Barton]

On Thu, Mar 8, 2018 at 7:53 PM, Paul Melis <paul.melis at surfsara.nl> wrote:
> Hi Campbell,
>
> On 08-03-18 04:48, Campbell Barton wrote:
>>
>> Supporting C/C++ in an add-on means there is technically nothing
>> stopping someone from bundling an entire library.
>>
>> While it's possible this makes sense in some cases, it introduces
>> issues with having to properly integrate a library into Blender
>> (workaround constraints in the API, even bugs).
>> Notice the add-on linked misses support for things currently working
>> in our add-on.
>> While it could be fixed, that add-on is basically moving from Python
>> to C which is quite a different project.
>
>
> Thats' true. I actually didn't spend too much time on the add-on, as I
> mostly use the bundled script (mesh_readply.py) directly in other scripts
> that need to load data from PLY. Interactive import happens a lot less (and
> even then I frequently use blender -P mesh_readply.py...).
>
>> For the GSOC I rather we keep a Python reference implementation with a
>> C fast-path which is typically useful for parsing arrays of geometry.
>
>
> I will be interested to see how the GSOC work pans out. Going through
> Python, even when being able to pass arrays/buffers is still somewhat
> suboptimal in the current setup. Setting up a Mesh with UVs and such takes a
> bit of work and having to use 4 indices per triangle to pass to
> foreach_set('vertices_raw',...) is unfortunate. I didn't look into it, but
> is passing polygons with more than 4 vertices even possible, or would you
> need to tessellate the geometry first yourself?

Done carefully, we can ensure float arrays are used (no conversion to
lists of Py objects) so it should be quite fast.
You can create ngons if you need but this involves calculating
loop-offsets for each polygon.

>> PLY and STL are simple enough formats that I'm skeptical of the value
>> of using 3rd party libraries.
>
>
> Fair point. STL is a no-brainer to implement oneself. For PLY I used rply
> because it exists and I didn't want to spend time on writing a PLY reader
> (and it supports both binary and ascii variants of .ply). The API is
> actually a bit quirky, with all the callbacks.

Moving the entire import/export into C code or not has a lot to do
with whoever maintains the code.
If we had developers eager to write & maintain high quality C/C++
io-addons for Blender, I'm not against it.
It's just that in the past we had more active development with Python.
In 2.4x we had import/export written in C, almost nobody improved of
fixed bugs there.

On the other hand, things might have changed since then.


> Regards,
> Paul
>
>
> --
>
> Paul Melis
> | Visualization group leader & developer | SURFsara |
> | Science Park 140 | 1098 XG Amsterdam |
> | T 020 800 1312 | paul.melis at surfsara.nl | www.surfsara.nl |



-- 
- Campbell