Je sais pas de quoi tu veux parler.
Si c'est pour la conversion des HDR, c'était prévu que je le code. Ça ne devrait pas être trop compliqué à faire même s'il ne m'est pas possible de l'incorporer dans l'éditeur comme prévu.

En fait j'ai réussi à faire fonctionner IBL Baker et cmftStudio... Mais je peux pas en tirer grand chose.
IBL Baker ne sort que des DDS et la sortie ne me convient pas du tout en terme de structure. Quant à cmftStudio, il sort bien des HDR en cubemap mais les images générées sont bourrées d'artefacts visuels ! Donc forcément au rendu ça se voit énormément.

Du coup je pars sur une application en ligne de commande pour le moment. Comme ça j'aurai le format voulu et, j'espère, sans bug.

Oh, et j'oublais. IBLBaker comme cmftStudio se basent sur imGUI pour leur interface graphique (boutons, etc). J'aime pas trop donc ça ne représente même pas une alternative à Qt.

Pardonne de mon manque de détail.

Citation :

Donc tu devrai coder un "glbinding" personnel pour pouvoir avancer, si tu ne voulais pas attendre l'implémentation dans glbinding.

Non,non, j'ai rien à faire à ce niveau-là.

glbinding c'est une bibliothèque qui existe déjà. Je pourrais l'utiliser mais je veux que quand on compile mon projet, les dépendances soient automatiquement téléchargées. Un peu comme quand on installe un logiciel sous Ubuntu, il télécharge avec lui tout ce dont il dépend.
Sauf que ce n'est pas possible pour glbinding car les gens n'ont pas encore fait les packages, un peu comme si tu voulais un logiciel sous Ubuntu mais qu'il n'est pas présent dans le gestionnaire de paquets.

Rien que pour moi-même, quand je suis sous Windows, c'est beaucoup plus simple et j'ai pas à me prendre la tête.

Petite mise à jour de l'avancement.

Aujourd'hui, j'ai commencé à avoir de premier résultats pour mon outil qui permettra d'avoir toutes les textures HDR qui serviront à l'éclairage ambiant.

Pour le moment, c'est encore en chantier. Le code est un peu en vrac (des morceaux sortiront du moteur car ça n'aura plus lieu d'être là) et tout n'est pas fini. Mais j'ai réussi à avoir des images tout à l'heure !

Donc voici à quoi ressemble la HDR utilisée sur la cubemap.


Et là les images générées (je les ai assemblées manuellement, le but sera de les fusionner automatiquement avec le générateur).


Cette petite cubemap est un exemple de ce qui sert à faire un éclairage ambiant.

Quand j'aurai finalisé (nettoyage du code, etc), j'aurai encore une autre cubemap à générer dédiée aux reflets.

Ce qui me "plaît" avec cet outil de conversion, c'est que je me sers de mon propre moteur pour faire ces images. J'ai ajouté/modifié de petites choses mais tout s'imbrique très bien.
C'est réconfortant de se dire qu'il "fonctionne bien" même en dehors d'une application de type jeu vidéo pour laquelle il est plutôt dédié !

Bonne nuit à tous !

J'ai "fini" le projet. Pour le moment, le logiciel crache plusieurs fichier .hdr, chacun correspondant à une des 6 faces d'un cube (pour créer une cubemap).

Pour finaliser ce projet, je voudrais créer un "format" de fichier spécifiquement pour mon moteur, le HEM (hARMful Environment Map). Il s'agit ni plus ni moins que d'une concaténation des différents fichiers en un seul "gros" fichier pour les transporter plus facilement.

Voici la page du programme en question, nommé incredIBL (IBL pour image-based lighting, le nom de la technique d'éclairage) :
https://github.com/dcarlus/incredIBL

Il s'agit donc d'un outil en ligne de commande (CLI) mais il fonctionne sur GPU. Le traitement est donc très rapide, les seuls ralentissements possibles sont liés au chargement et à l'écriture des fichiers.

On lui donne une image HDR en entrée (un panorama 360°) et il ressort toutes les maps nécessaires pour faire un bel éclairage en OpenGL.
Vous trouverez un exemple en bas de la page du projet (joliment agencé à la main en format cubemap pour la représentation).

On peut définir la taille des images générées. Le logiciel s'arrange pour que les tailles soient des puissances de 2 (sinon OpenGL refuse d'afficher les cubemaps).

Tout ça peut rester encore un peu flou sur la finalité. J'espère vite pouvoir vous montrer le résultat !

Allez, je vais vite me coucher !!

Plop,
Le logiciel arrive à exporter au format .hem. Ce n'est, ni plus ni moins, une archive .tar renommée.

Maintenant, faut charger tout ça pour (enfin) le gérer dans le rendu !

EDIT: Vidéo de présentation...
https://www.youtube.com/watch?v=zoz6vdJ_wik

Souhaitions que ça fera gagner du temps pour le développement d'un concepteur quelconque .

Bah, c'est quelque chose d'assez inintéressant. Ou plutôt, pour le dire correctement, t'as tellement envie d'avoir de "zolis rendus" en 3D que t'es impatient et t'as pas envie de passer du temps à faire tout ça.

Après, je l'ai fait en priorité pour moi-même.
Je le partage si ça peut servir. Si c'est le cas, tant mieux, sinon ça changera rien au fait que ça me sert beaucoup ! :D

C'est comme le mec qui a fait ce programme : https://github.com/HectorMF/BRDFGenerator

C'est aussi une image importante pour le rendu PBR. Son programme va me servir, mais il l'a probablement fait pour son propre besoin à la base (comme un peu tout ce qu'on fait, même si le besoin c'est juste s'amuser).


PS: hier j'ai réussi à faire le chargement des images. Ça va super vite malgré la bonne résolution des images. Pourtant c'est que sur un HDD que j'ai testé.
C'est lié au fait que tout est groupé dans un seul fichier, le HEM (ça limite les commandes lentes de lectures du CPU vers le disque) qui est alors entièrement en mémoire. Les images sont donc lues depuis la RAM et là, ça bombarde !

Une fois qu'ils sont lus, les fichiers sont ensuite effacés de la RAM bien sûr !

J'ai pu charger les images dans le moteur mais j'ai encore rien appliqué du tout au rendu. Il me manquait une donnée représentée sous forme de "texture".

C'est un tableau en 2D, et non une image à proprement parler même si pour des raisons de praticité elle est enregistrée comme tel.
En fait, chaque pixel code deux valeurs (canaux rouge et vert) et ces valeurs sont utilisées pour calculer des choses dans les matériaux.
C'est un peu comme une normal map où chaque canal (RGB) code un vecteur (coordonnées XYZ) pour "modifier la surface" d'un objet 3D. En soit, une normalmap n'est pas une image, c'est des coordonnées de vecteurs.



Cette image ne varie pas, une fois qu'elle est calculée on peut l'utiliser. Elle ne dépend pas du tout d'une image HDR, j'aurais très bien pu faire ça dans un nouveau programme mais c'était plus pratique ainsi.
Le programme ne la calcule pas systématiquement, il faut spécifier une option pour le faire. Par défaut, le programme ne la calcule donc pas !

Alors, ça semble tout bête ce truc rouge mais en fait ça demande pas mal de calculs vectoriels, c'est donc assez long. Ici, c'est un calcul sur CPU mais on peut très bien le faire en GPU. J'avais envie de changer.

Le truc rigolo c'est que j'ai fait le rendu en multithreadé à la façon d'un rendu dans Blender. J'ai découpé l'image en tiles de 32x32 pixels et chaque thread fait les rendus case par case. Dans le Gestionnaire de tâches, le CPU est actif à 100% car j'utilise autant de threads que disponibles sur le CPU. C'est un peu sauvage mais j'ai pas envie de mettre 56000 options dans le soft...

J'ai pas souvent l'occasion de faire des programmes qui fonctionnent en multithreading mais je trouve ça toujours très amusant d'imaginer le bousin mouliner à fond quand on l'exécute. Et j'ai pu apprendre des choses en C++ à ce niveau-là.

Youhou !
Je commence à avoir un rendu intéressant avec tout le bazar dont je vous ai parlé ces derniers temps :

https://pasteall.org/media/c/6/c60647b45d5b39d0db49e44b83e7e535.jpg


https://pasteall.org/media/5/1/51c1fcfcb8d78eedf55a90667befc777.jpg


https://pasteall.org/media/a/8/a8608332b0b73c80afceffb30b0300b4.jpg

En fait, j'ai presque fini à ceci près que j'arrive pas à appliquer correctement mes normal maps. Je comprends pas, ça a toujours bien marché et là ça foire.

Je vérifierai aussi mes shaders parce que les spéculaires sont quand même très faibles pour du métal.

PS: le modèle est le Cerberus de Andrew Maximov.
https://www.artstation.com/artwork/3k2