Sans parler de RTX mais de « Raytracing » en général, rien n’empêche que ce soit implémenté, ce qu’il faut pour ce faire, c’est que quelqu’un le fasse. Et en fait ce n’est pas spécifique au tracé de rayons, c’est spécifique à toute fonctionnalité graphique qui pourrait être implémentable.
Les développeurs de moteur de jeu sont une espèce très rare et précieuse, et qui se raréfie. Les spécialistes des moteurs de rendu sont encore plus rare. Il y a plusieurs raisons à cela et je ne suis pas certain de tout savoir, mais déjà ce sont des compétences très pointues, et qui sont de plus en plus pointues (et qui sont donc de plus en plus sélectives). Si on regarde le marché du jeu vidéo, on voit surtout de très très grosses entreprises qui produisent des moteurs de jeu. Cette concentration n’est d’ailleurs pas spécifique au jeu vidéo : IBM rachète Red Hat, Microsoft rachète Zenimax (et donc id Software). Je ne sais d’ailleurs pas si c’est une sorte de bulle qui va éclater, ou si c’est l’avènement d’un monde cyberpunk où tout est entre les mains d’une poignée d’acteurs, mais c’est le constat pour le jour actuel.
Dans le domaine des moteurs de jeu et peut-être plus encore de moteur de rendu graphique, l’artisanat est devenu une curiosité. Les rares ressources sont déjà bien exploitées par une poignée d’acteurs. C’est la dèche. Donc bref, la seule chose qui empêche que tel ou tel truc sexy soit implémenté c’est tout simplement les limites de la main d’œuvre. Pour Unvanquished/Daemon on a la chance d’avoir quelques développeurs qui connaissent le domaine.
Un projet comme Unvanquished/Dæmon c’est un projet qui avance au rythme des disponibilités et compétences de chacun.
Pour voir implémenté du raytracing, du vulkan ou toute autre chose à la monde il faut que quelqu’un à qui c’est à la portée de le faire, s’y mette. 😁
En fait, un de nos développeurs, Fuma, a déjà un projet de tracé de rayon qui semble fonctionnel même si incomplet (quelques copies d’écran ici, l’absence de texture est volontaire puisque ce qui est comparé sont les lumières et les ombres). Je n’ai aucune idée des performances. Par rapport à ce projet, il est du genre à venir sur le chat une fois l’an avec des nouvelles. Je ne peux donc pas dire si ça viendra un jour ou jamais. Ça dépend entièrement de lui en fait... Fuma fait partie des gens qui peuvent lire des papiers de recherche et produire quelque chose, tout en ayant une bonne connaissance de l’état de l’art actuel (je ne sais pas ce qu’il fait en dehors d’Unvanquished en fait).
Pour donner un exemple, de mon côté, j’ai fait un énorme travail de nettoyage de code (un autre effort de plusieurs années) qui, par réécritures et refactorisations successives ont conduit à supprimer 680 lignes tout en ne retirant aucune fonctionnalité, permettant de combiner plus de ces fonctionnalités, rende certaines fonctionnalités implémentables, et rend le code plus testé, rend la maintenance plus facile, et dont la conception du code empêchera certains bugs d’être introduit ou oublié d’être corrigé par inadvertance. Ce travail a fait passer le moteur Dæmon de la preuve de concept qu’était XreaL à quelque chose de propre sur ce plan, en corrigeant parfois des bugs qui avaient été introduit dans XreaL avant même la sortie standalone de Tremulous 1.1.0... Ce grand nettoyage fera, je l’espère, l’objet d’un autre article.
Mais faire cela pour moi a été essentiellement une forme de méta-programmation, il s’agissait de reformuler les chose, réorganiser le code, le découper, le factoriser, le dédupliquer, changer la façon dont il était appelé pour le rendre réutilisable. À aucun moment je n’ai vraiment touché aux formules mathématiques. Un autre spécialiste des moteurs de rendu, gimhael, a surtout contribué ces dernières années par des commentaires, des explications très précieuses, que du code. Cela a rendu ce travail de refactorisation et de nettoyage possible, mais pour implémenter de nouvelles fonctionnalité il faudra des commits de leur part. On verra bien ce que nous réserve le futur. 😃
Mais avant le tracé de rayon, il y a tout plein de choses sur lesquelles on peut agir et qui sont plus à la portée des contributeurs les plus actifs actuellement. Grâce à ce travail de refactorisation, le reliefmapping a été corrigé et est utilisable : aux artistes de fournir les fichiers qui vont bien pour en profiter. Le PBR (physical based rendering) a été activé pour toutes les surfaces, là encore c’est aux artistes de fournir les textures qui vont bien, avant cela, le moteur saura faire mais ne le fera pas. J’ai découvert que quelque chose d’encore inconnu assombri le jeu... Si je charge la même carte dans Dæmon avec la petite démo Xonotic, la luminosité est celle attendue, si je charge la même carte dans Dæmon avec le jeu Unvanquished, quelque chose l’assombri un peu... Nous avons donc un bug à trouver et corriger pour améliorer les choses ! Aussi, j’aimerai voire implémentée la prise des lightmaps sRGB. Les lightmaps sont des textures de lumières et d’ombres précalculées. Il s’agit là d’utiliser un format d’image non-linéaire qui privilégie les valeurs utiles l’œil (ce qui réduit les dégradés à grosse marche bien visible) et d’avoir des calculs qui sont plus proche de ce qui se passe physiquement. Avant même de faire du tracé de rayon, il serait bon d’avoir des formules qui soient plus proches des modèles physiques, et on n’a pas besoin de tracer des rayons pour ça. =)
Bref, ce sujet est dans ma liste des sujets dont j’espère pouvoir faire un article (comme annoncé à la fin de celui-ci), ce commentaire m’aura aidé à trouver un angle d’attaque et donné quelques idées quant au découpage de ses parties. 😉
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Graphisme / RTX
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Unvanquished : maintenant nous sommes libres !. Évalué à 10.
Sans parler de RTX mais de « Raytracing » en général, rien n’empêche que ce soit implémenté, ce qu’il faut pour ce faire, c’est que quelqu’un le fasse. Et en fait ce n’est pas spécifique au tracé de rayons, c’est spécifique à toute fonctionnalité graphique qui pourrait être implémentable.
Les développeurs de moteur de jeu sont une espèce très rare et précieuse, et qui se raréfie. Les spécialistes des moteurs de rendu sont encore plus rare. Il y a plusieurs raisons à cela et je ne suis pas certain de tout savoir, mais déjà ce sont des compétences très pointues, et qui sont de plus en plus pointues (et qui sont donc de plus en plus sélectives). Si on regarde le marché du jeu vidéo, on voit surtout de très très grosses entreprises qui produisent des moteurs de jeu. Cette concentration n’est d’ailleurs pas spécifique au jeu vidéo : IBM rachète Red Hat, Microsoft rachète Zenimax (et donc id Software). Je ne sais d’ailleurs pas si c’est une sorte de bulle qui va éclater, ou si c’est l’avènement d’un monde cyberpunk où tout est entre les mains d’une poignée d’acteurs, mais c’est le constat pour le jour actuel.
Dans le domaine des moteurs de jeu et peut-être plus encore de moteur de rendu graphique, l’artisanat est devenu une curiosité. Les rares ressources sont déjà bien exploitées par une poignée d’acteurs. C’est la dèche. Donc bref, la seule chose qui empêche que tel ou tel truc sexy soit implémenté c’est tout simplement les limites de la main d’œuvre. Pour Unvanquished/Daemon on a la chance d’avoir quelques développeurs qui connaissent le domaine.
Un projet comme Unvanquished/Dæmon c’est un projet qui avance au rythme des disponibilités et compétences de chacun.
Pour voir implémenté du raytracing, du vulkan ou toute autre chose à la monde il faut que quelqu’un à qui c’est à la portée de le faire, s’y mette. 😁
En fait, un de nos développeurs, Fuma, a déjà un projet de tracé de rayon qui semble fonctionnel même si incomplet (quelques copies d’écran ici, l’absence de texture est volontaire puisque ce qui est comparé sont les lumières et les ombres). Je n’ai aucune idée des performances. Par rapport à ce projet, il est du genre à venir sur le chat une fois l’an avec des nouvelles. Je ne peux donc pas dire si ça viendra un jour ou jamais. Ça dépend entièrement de lui en fait... Fuma fait partie des gens qui peuvent lire des papiers de recherche et produire quelque chose, tout en ayant une bonne connaissance de l’état de l’art actuel (je ne sais pas ce qu’il fait en dehors d’Unvanquished en fait).
Pour donner un exemple, de mon côté, j’ai fait un énorme travail de nettoyage de code (un autre effort de plusieurs années) qui, par réécritures et refactorisations successives ont conduit à supprimer 680 lignes tout en ne retirant aucune fonctionnalité, permettant de combiner plus de ces fonctionnalités, rende certaines fonctionnalités implémentables, et rend le code plus testé, rend la maintenance plus facile, et dont la conception du code empêchera certains bugs d’être introduit ou oublié d’être corrigé par inadvertance. Ce travail a fait passer le moteur Dæmon de la preuve de concept qu’était XreaL à quelque chose de propre sur ce plan, en corrigeant parfois des bugs qui avaient été introduit dans XreaL avant même la sortie standalone de Tremulous 1.1.0... Ce grand nettoyage fera, je l’espère, l’objet d’un autre article.
Mais faire cela pour moi a été essentiellement une forme de méta-programmation, il s’agissait de reformuler les chose, réorganiser le code, le découper, le factoriser, le dédupliquer, changer la façon dont il était appelé pour le rendre réutilisable. À aucun moment je n’ai vraiment touché aux formules mathématiques. Un autre spécialiste des moteurs de rendu, gimhael, a surtout contribué ces dernières années par des commentaires, des explications très précieuses, que du code. Cela a rendu ce travail de refactorisation et de nettoyage possible, mais pour implémenter de nouvelles fonctionnalité il faudra des commits de leur part. On verra bien ce que nous réserve le futur. 😃
Mais avant le tracé de rayon, il y a tout plein de choses sur lesquelles on peut agir et qui sont plus à la portée des contributeurs les plus actifs actuellement. Grâce à ce travail de refactorisation, le reliefmapping a été corrigé et est utilisable : aux artistes de fournir les fichiers qui vont bien pour en profiter. Le PBR (physical based rendering) a été activé pour toutes les surfaces, là encore c’est aux artistes de fournir les textures qui vont bien, avant cela, le moteur saura faire mais ne le fera pas. J’ai découvert que quelque chose d’encore inconnu assombri le jeu... Si je charge la même carte dans Dæmon avec la petite démo Xonotic, la luminosité est celle attendue, si je charge la même carte dans Dæmon avec le jeu Unvanquished, quelque chose l’assombri un peu... Nous avons donc un bug à trouver et corriger pour améliorer les choses ! Aussi, j’aimerai voire implémentée la prise des lightmaps sRGB. Les lightmaps sont des textures de lumières et d’ombres précalculées. Il s’agit là d’utiliser un format d’image non-linéaire qui privilégie les valeurs utiles l’œil (ce qui réduit les dégradés à grosse marche bien visible) et d’avoir des calculs qui sont plus proche de ce qui se passe physiquement. Avant même de faire du tracé de rayon, il serait bon d’avoir des formules qui soient plus proches des modèles physiques, et on n’a pas besoin de tracer des rayons pour ça. =)
Bref, ce sujet est dans ma liste des sujets dont j’espère pouvoir faire un article (comme annoncé à la fin de celui-ci), ce commentaire m’aura aidé à trouver un angle d’attaque et donné quelques idées quant au découpage de ses parties. 😉
ce commentaire est sous licence cc by 4 et précédentes