Deskmat VS assimp

Sorry meant to attach it :D https://github.com/Prkns/Deskmat

Playing around with blender scene rendering, found this: https://github.com/Prkns/Deskmat

This PR will use the crate bindgen to provide the unsafe c-bindings from the library. If you want to help and contribute you can take a look onto the following PR: Rust-Binding proposal

Curiously, what people commonly refer to as 'Waterfront OBJ' is merely a tiny subset of that format dealing with polygons.

The format supports e.g. higher order curves and surfaces and apps like Maya or Rhino3D can read and write OBj files containing such data. [1]

Writing a parser for the polygon subset also comes with some caveats.

If your target is a GPU you probably need to care for robust triangulation of n-gons and making per-face-per-vertex data per-vertex on disconnected triangles.

Vice versa, if you are feeding data to an offline renderer you want to absolutely preserves such information.

I believe the tobj Rust crate is one of the few OBJ importers that handles all edge cases. [2] If you think it doesn't, let me know and I will fix that.

This is surprising for people familiar with one but not the other of the requirements of offline- or GPU rendering.

I.e. if you write an OBJ reader this can become an issue, see e.g. an issue I opened here [3].

1. https://paulbourke.net/dataformats/obj/

2. https://docs.rs/tobj/latest/tobj/struct.LoadOptions.html

3. https://github.com/assimp/assimp/issues/3677

And, finally, resource loaders. I have worked with many resource loaders in the past. That's to say that I know my way around them. For image loaders, I decided to go with the obvious stb_image. It is small, easy to use, and has only a single header. Meaning, like MiniAudio, I can easily integrate it into the engine. Besides that, it supports a wide array of image formats. Even HDR which was surprising. Audio file loaders are next. For this one, I decided to use a few small libraries. Specifically, the Mp3 and WAV loaders from dr_libs and the OGG loader from STB once again (Sean Barret to the rescue!) Each of these are a single-header library as well. Once again, very small and very easy to integrate. As for 3D models, I decided to use a huge dependency named ASSIMP. For me, that was a very hard sell. ASSIMP is huge but it supports plenty of 3D model formats. And besides that, none of the resource loaders are going to be present in the engine itself. But, rather, there is going to be a separate tool--one that I dubbed NBR (Nikola Binary Resource)--that would take only the minimum required data from these loaders and save it into a binary file (.nbr) which then would be read accordingly by the engine.

If you use something like libassimp https://github.com/assimp/assimp it will allow you to import these and access the data to generate your Vertex Array Objects then render to a frame buffer object.

If you just want to load other data in a relatively simple fashion, assimp https://www.assimp.org supports loading a bunch of different formats and is pretty easy to use.

The emscripten interface for the assimp library. It runs entirely in the browser, and allows you to import 40+ 3D file formats and access the result in JSON or glTF format. This is not a full port of assimp, but an easy to use interface to access it's functionality.

I ran into what sounds like a similar problem a few months ago. It turns out this was an assimp bug: https://github.com/assimp/assimp/issues/1974

You could give assimp a go (there is a python version) i've used it for 3DS before then you can export to something else. https://github.com/assimp/assimp/blob/master/port/PyAssimp/README.md