Page MenuHome

WIP OBJ exporter in C and C++
Needs ReviewPublic

Authored by Hugo Sales (someonewithpc) on Mar 22 2019, 2:02 PM.

Details

Summary

Motivated by the GSoC 2018 and 2019 ideas pages, and so I could familiarize myself with the structure of the project and the code itself, I started to work on the task for porting common exporters to C/C++

This is only a MVP and currently only handles vertices, UVs and normals, but it builds a framework where it's easier to expand and to implement other formats.

Diff Detail

Repository
rB Blender

Event Timeline

I take it you are interested in making a proposal for the exporter idea for GSoC '19?
I will try this out soon. Am very interested in what the speed comparisons are so far with this vs Python export. Did you do any measurements of that yet?

I once made a go at trying something like this (though in C, not C++) using approximately your approach. I think Campbell had a different idea of how it should go, where the non-performance-critical pieces of exporting stayed in Python and that something gets done to the Python API to allow C/C++ speed functions to do the very heavy lifting (Campbell, am I getting your position at all right?). The arguments for the latter approach include (1) it leaves the easier-to-understand Python as a model for other people to write addons for other formats; and (2) there's a lot of complicated embedded knowledge in the current exporter that needs to be rediscovered and properly implemented in C/C++, which could be avoided if one just mutates the current exporter. I have to say that in spite of these, I am personally in favor of an all C/C++ version, perhaps with well thought-out library functions to make for easy reuse by exporters for other formats. But this is up for discussion and your eventual proposal should probably discuss both approaches and why you choose the one you choose.

I will warn you that you will likely bog down when it comes to exporting material-related data. Any time you spend now in understanding that will likely pay benefits later, and may inform some design decisions.

I take it you are interested in making a proposal for the exporter idea for GSoC '19?

Yes, I just sent an email to the mailing list. I wasn't expecting such a fast reply.

I will try this out soon. Am very interested in what the speed comparisons are so far with this vs Python export. Did you do any measurements of that yet?

I did only some very coarse and rough measurements, but, despite not having done any real optimizations, it was already about 1.5 times faster, while exporting a Suzanne with a sudv of 6. I was expecting it to be faster, but I think I didn't compile with optimizations (debug build).

I once made a go at trying something like this (though in C, not C++) using approximately your approach. I think Campbell had a different idea of how it should go, where the non-performance-critical pieces of exporting stayed in Python and that something gets done to the Python API to allow C/C++ speed functions to do the very heavy lifting (Campbell, am I getting your position at all right?). The arguments for the latter approach include (1) it leaves the easier-to-understand Python as a model for other people to write addons for other formats; and (2) there's a lot of complicated embedded knowledge in the current exporter that needs to be rediscovered and properly implemented in C/C++, which could be avoided if one just mutates the current exporter. I have to say that in spite of these, I am personally in favor of an all C/C++ version, perhaps with well thought-out library functions to make for easy reuse by exporters for other formats. But this is up for discussion and your eventual proposal should probably discuss both approaches and why you choose the one you choose.

Hm, I see. I think it would be more clear as to how it works and easier to maintain if it were completely implemented in C++. I tried to write my code in a rather generic way and I even started to separate parts which I think might get reused to separate files (*common* files). If Campbell still thinks it's relevant for it to be partially in Python, I can make that work.

I will warn you that you will likely bog down when it comes to exporting material-related data. Any time you spend now in understanding that will likely pay benefits later, and may inform some design decisions.

Thank you for the tip, for now I tried to stay away from the materials because I was expecting just that, for it to be a more messy task :P But I have full intentions of getting it to work.

As an aside, like I said in the mailing list, I wouldn't mind working on any other of the ideas if they're deemed more urgent, this was just to familiarize myself more with the code.

seems like the obj importer/exporter in c++ is something we all played with, I did a small exercise last year writing an obj parser / importer based on boost::spirit

importing sanmiguel low poly from http://casual-effects.com/data/index.html (628 megs)

languagetimepeak memory
c++11.21.7gb
python321.910.3gb

The code is nothing more than a proof of concept, i'd like to say it has some rough edges, but it's mostly rough edges really, but if you're interested i'd happily send it your way

the main speedup without a doubt was using memory mapped files over regular IO

Best of luck with your GSOC submission!

@LazyDodo (LazyDodo) I'm sure it would be handy, even if only to look through if I get stuck, so I'd really appreciate it if you could share :) Was this just a program to learn, not related to Blender or am I misunderstanding something?

I was fed up how long my imports took, and had never used boost::spirit before, so that sounded like some fun tinkering, I think i ran into issues on getting the normals and smoothing groups into blender , materials seemed like a lot of work and I lost interest in it.

It's "tinkering code"-(tm) not production ready code, so don't take it as being written with best the practices (I'm not even show how appreciated by the other devs the use of boost in an importer is) but if it's helpful to you, feel free to cannibalize it, if not feel free to completely ignore it, no hard feelings either way :)

P943