tinyobjloader VS single_file_libs

Obj file parsing isn't really OpenGL... But you can take a look at this GitHub project: https://github.com/tinyobjloader/tinyobjloader

For the Blender export part, the simplest 3D model format is OBJ. It's a text format that can be read in only ~100 lines of code. You can use Assimp for this. Or you can use something like tinyobjloader: https://github.com/tinyobjloader/tinyobjloader

I've replaced tinyobjloader with fast_obj which speeds up model loading process significantly. Here is a good article comparing different obj loaders.

I don't think this is an issue with tinyobjloader but I'm unsure of how to troubleshoot from here. I've been following this tutorial to learn opengl.

Exampes I've seen are the stb single header libraries, as well as tinyobjloader. The necessity to do this is usually written in the comments at the top of the header file:

If you´re using tinyobjloader, the documentation here https://github.com/tinyobjloader/tinyobjloader explains how it works. There´s even a triangulate flag.

Try Tiny obj loader: https://github.com/tinyobjloader/tinyobjloader

Also, it's possible to store a color per vertex, tinyobjloader supports this extended format for OBJ. But, like you say, how many (if any) OBJ loading programs actually support these vertex colors I suspect you can count on one hand (and more likely, zero hands). Blender, for example, does a terrible job even interpreting cutout objects in OBJ files, a common case (see step 9). I doubt they'd ever add per vertex color import support for any file format they read in. But, I'm interested to hear if they do - Blender is (by far, I believe) the main DCC app used with Mineways exports.

Yep: https://github.com/nothings/single_file_libs

Also sometimes I use only header (.h) with all functions included wrapped by #ifndef and #endif. When I use these? for code that I always reuse to simplify things and some data stucture handling (to implement dynamic arrays). A good example list of these (not mine) are https://github.com/nothings/single_file_libs

Also, there are many libraries that are much bigger (little list I found) but are implemented in a single header file.

If others have a similiar problem, I found a great github page that has lots of single header libraries, including data structures.

> Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity.

This is generally why I opt for "single-file" libraries that do one simple task well. The smaller the library, the more likely it is "done". For example, do I want some insanely complex image library that handles every file format under the sun, or do I just want some basic one that allows me to output a simple JPEG?

I often find myself referring to "single_file_libs" repository: https://github.com/nothings/single_file_libs

Looking at the open issues, it doesn't appear to be actively maintained but it's still an incredibly good resource for "completed" projects.

Steamworks is the easy option, but if you're programming-savvy you could also use a networking library (some lists for C and C++: 1 2 3) to accomplish the same thing.

Have a look at these. https://github.com/nothings/single_file_libs#geometry-file