What I did was build my own. I learned Python to write an exporter from Blender for DirectX11. I mean the exporter was generic and not for anything specific, but the importer was DX11. I haven’t tried Assimp, but I’m considering it. I’m also considering writing an OBJ importer.
I agree with Silence, it would probably be a really good idea to go to Assimp and get some help. Lots of people use it, so I would be inclined to think that there is a way to make it work although I have to admit I’ve never used it myself.
I did like the route that I took of writing my own exporter from Blender. It was a good learning experience for one thing. Now if I were to try and tackle the OBJ format, it should be no problem. I was able to look at the output and answer someone’s questions on it recently. The problem with writing your own exporter is skinned animation. Writing an exporter for rigid animation is not too bad. But writing one for skinned animation is like an order of magnitude more difficult. I’m fairly certain Assimp would support skinned animation.
None the less, that might be putting the cart before the horse. If you can’t write a skinned animation importer, then you are likely not ready to do skinned animation.
The first step is to know how to hand code 3D models using vertex and index buffers. That’s really all a model is. I imagine even with Assimp you’re going to have to take it’s data and draw it unless it gives you a model class with a draw method you can simply call.
Lately I’ve been using Substance and the work flow is to export OBJ files to Substance, paint them, and export the maps. So, the end product is OBJ files and JPEGS or PNGs. I could probably throw away the OBJ and use my custom file from my exporter because all I really need is the UV data for the vertices in order to make the maps work. And both files contain that data. So, the OBJ is about the same as my custom file.
One problem you face pretty early is triangulation. Modeling programs model in polygons, but the vertex buffer you need to put that data in only understand triangles (in modern versions of OGL and regardless of which version, the graphics card doesn’t know what anything other than a point, line, or triangle is whether OGL defines it or not). So, I use the triangulation option in Blender to break the whole model down into triangles before exporting. Most exporters don’t require that and I’ve been theorizing how that might be handled automatically. If you assume that all triangles in a face are co-planar, than it probably doesn’t matter how you divide them except perhaps for skinned animation. But even then, I would expect most of the time triangles that are part of the same face or polygon would be fairly close together.
I don’t think you have this problem with Assimp, but I’m not sure of that. With OBJ files you certainly do. From what I’ve seen, OBJ files exports faces, not triangles. So, you very much have to deal with triangulating the model. Although, I suppose you could triangulate it in Blender and then export to OBJ and the faces would “happen” to be triangles.
Anyway, when I was doing DirectX, I would code pretty much everything from scratch. OGL really lends itself more to using libraries. Just to have some cross platform compatibility, I would recommend using libraries like GLFW, GLEW, GLM, and so fourth. So, by the time you start linking all these libraries in, it makes a lot of sense to just keep going and link in something like Assimp. With DX, I was operating under the assumption that it would never run on anything other than Windows and so it was easier and made more sense to code things from scratch without the help of libraries. But once you start going down the path of using libraries, it makes sense to make as much use of them as you can. I hope to write a tutorial example program and maybe one day do a tutorial video on loading models for OGL, but I’m in school learning 3D modeling and don’t see that happening in the next year. But one day when I get around to it, I’m debating on whether to rewrite my Blender exporter/importer for OGL, to use OBJ files, or to use Assimp, or even to do all 3.
Anyway, if you are interested in the Blender exporter and C++ importer, it’s on my website. The Blender exporter is generic and just exports a text file with Blender’s basic model data. So, it would not change for OGL. The DX11 project is there as well. A lot of the C++ code would not change, especially the parts that read the text file. I use the data to build my model object. Once the model object is build, the class is setup to basically serialize and export a binary file that loads straight into the object’s variables. One thing you will learn pretty quickly when building your own is that all these file formats are extremely inefficient; most of them contain garbage that just wastes time and resources when loading. Ultimately, what you really want is binary data that loads straight into what ever model class you create. The specifics on drawing the model class in DX are different, but other than that, much of the C++ code should be about the same. I’ve been meaning to convert all of this code over to OGL, but just haven’t had the time yet.
Writing your own OBJ importer is not a bad option.
Either way, you need to know how to hand code models in OGL first. I have that in OGL 4.5 on my website.
For Assimp, LearnOpenGL.com covers it in it’s tutorials, if you haven’t seen that already. I haven’t gone through those tutorials, but they look pretty good at a glance. Really, I think getting Assimp working is likely your best option. Before you can code your own model class, you pretty much have to know what it is you are trying to code and how the models work and such. Getting some experience with Assimp before trying to write your own may be helpful.