Edit January, 4th 2022 : The Assimp maintainers merged just a few days ago a pull request that enables PBR support by Assimp’s OBJ importer. If you are able to use a recent version of Assimp, I would advise you to go get it and work with it the way Assimp expects it. See the pull request here.
These days, I’m trying to import 3D models exported as Wavefront OBJ files in my Vulkan renderer. In order to achieve that effortlessly (kinda), I’m using the very good Assimp (pun not intended) library.
It kinda works well if you stick to a « traditional Blinn-Phong » lighting pipeline (also known as « prehistoric lighting » 😉 ), with ambient/diffuse/specular components and so on. Everything is there. Things become trickier if you try to bring PBR into the mix, with roughness, metallic and ambient occlusion maps for example.
What parameters should you use in Assimp to read those values ? What texture type should be used in order to import those maps ? Turns out it’s not as easy as one would think, because support on both the Wavefront OBJ specification and Assimp is just not there.
I had a problem recently : my scripting experience coming mostly from Linux, I’m much more used to shell scripts than .bat scripts. And despite working on Windows, I still prefer using shell script language mostly for human factors reasons (I find batch syntax ugly and frankly impossible to understand and/or remember).
But contrary to the Linux world, a shell executable (also known as sh.exe, or any other flavor like Bash or Zsh to name a few) is not installed by default on a Windows. You have to install it yourself and do a bunch of wiring so that shell files are automatically executed by the shell executable using some kind of fake Unix environment (Cygwin is a good example).
J’ai rencontré l’autre jour un problème qui s’est avéré assez compliqué alors que je cherchais à faire un truc simple à la base : je voulais ouvrir un projet de code C++ généré par CMake dans l’éditeur Eclipse et pouvoir le déboguer avec le débogueur inclus dans Eclipse. Sauf que bien sûr ça ne fonctionnait pas…
Et je me suis par la suite rendu compte qu’il ne s’agissait pas seulement d’un problème d’Eclipse mais que tous les logiciels utilisés à côté avaient également, à des degrés divers, leur part de responsabilité. Ou quand les logiciels se liguent pour faire chier au maximum !
Cet article est en rédaction depuis un moment, mais quel meilleur moment qu’aujourd’hui pour le publier puisque s’organise ce Dimanche à Lyon le Doctor Who Day ? Considérons donc qu’il s’agira de ma maigre participation vu qu’exceptionnellement, cet article sera narré (à grand renfort de gifs) par des acteurs de la série Doctor Who.
Bon, déjà que c’est un article au sujet extrêmement technique de base, pas sûr que l’on comprenne encore bien le problème de base ou la solution à y apporter, mais au moins une chose est sûre: cet article sera unique. Et c’était très amusant à écrire.
