Hi,

First of all, the project looks great. So I am also working on a 3D game that I am "trying" to program from scratch. I am at a stage where I want to now import 3D models. The quandary that I face is whether to use a 3D model import library or write an xml parser(using Collada) since I am trying to not use any external libraries. So I want to know what did you do? And if you used an import library that can you let me know which one?

Thanks

Hello, I just wanted to share my experience.

The assimp library gave me good results with most formats as long as I didn't need to import animations; when trying to import animations with assimp, only its Collada importer worked somewhat satisfyingly enough, but I still had some issues, so I ended up writing my own gtTF importer, so this one has become the format I'm most familiar with.

If you want to implement a compliant glTF importer, all the information you need is here: https://github.com/KhronosGroup/g...aster/specification/2.0/README.md

There is also an existing lightweight glTF library, cgltf: https://github.com/jkuhlmann/cgltf (I didn't test this one)

For my own importer, I didn't start exactly from scratch, I'm using rapidjson as my json parser, but it would make sense at some point to have a glTF importer that doesn't need any dependency.

Hi Elven,

For this game, I've written a custom collada importer from scratch, but I'd advise against it. It was excruciating to write such a thing especially for a grotesque file format like collada ... But the choice is yours.

I think it's worth noting that it's a common practice, when handling 3D models and other heavy game assets, to write a standalone program to convert some model interchange format like FBX, Collada, glTF, etc. into a customized internal data format which is then loaded and used by the game. In that case, even if the standalone program depends on a library, you don't necessarily have to integrate it with the game's build system or ship it to end-users.

notnullnotvoid
I think it's worth noting that it's a common practice, when handling 3D models and other heavy game assets, to write a standalone program to convert some model interchange format like FBX, Collada, glTF, etc. into a customized internal data format which is then loaded and used by the game. In that case, even if the standalone program depends on a library, you don't necessarily have to integrate it with the game's build system or ship it to end-users.

+1

https://github.com/lsalzman/iqm

I came across this a while ago. It gives both a text based & binary format for models & animations. And you get a plugin that exports the animations from Blender. It might be worth a look as it looks quite simple & don't have to write your own blender script (which I found can be quite confusing). I believe RayLib uses the binary format for it's 3d model animations.

Only took me a day to write an importer for a sub-set of the "Stanford PLY" format without textures. Just need a good string library that allow parsing easily using high-level split functions or something more advanced and then feed the data stream into the internal buffers. Optimization is not needed for importing models, because it doesn't affect the game's performance. Most import tools are full of bugs, because it doesn't really matter when you can easily fix what's broken when a new dialect of the format appears.
https://en.wikipedia.org/wiki/PLY_(file_format)

Unfortunately, as much as I love PLY for static models (it's pretty much the simplest possible textual format for that use case and absurdly easy to parse), it has the major limitation of being unable to include bones and animation data, as well as not being very good for mutli-texture/multi-material models. So for the vast majority of 3D games which have some skeletal animation happening somewhere, even if most of the models are static, you'll still have to invest in a more complex model format eventually.

Also, things that only run at startup are still very much worth optimizing, sometimes early in the development cycle. Long startup times are annoying and, more importantly, increase the time it takes for you as a developer to iterate on the program.

notnullnotvoid
Also, things that only run at startup are still very much worth optimizing, sometimes early in the development cycle. Long startup times are annoying and, more importantly, increase the time it takes for you as a developer to iterate on the program.

Importing is usually done by the designer before saving in a custom format with additional features. In my old engine, I had my own 3D modeling editor that could both import from other formats and apply custom features like geometry shaders and bone rigging. Only 6000 lines of code is enough to have your own tools.

I still very much wouldn't like to wait for that step when making frequent changes to models, but also, doing things that way prevents some features that are really nice to have, like quickly hot-reloading models.