Que faut-il apprendre pour devenir programmeur graphique ?
(blog.demofox.org)- Les compétences recherchées en graphisme temps réel exigent à la fois des API graphiques explicites côté CPU et l’éclairage et le shading côté GPU, et il est difficile d’approfondir les deux domaines en même temps
- Côté CPU, il s’agit de travailler avec des API modernes comme DirectX12, Vulkan et Metal, ainsi qu’avec le chargement d’assets et les tâches de support du moteur ; côté GPU, on traite les ombres, l’occlusion ambiante, le post-traitement et les caractéristiques de performance du GPU
- L’apprentissage du GPU repose surtout sur l’écriture d’un path tracer et la compréhension du PBR ; Ray Tracing in One Weekend, LearnOpenGL PBR, la documentation de Filament et PBRT peuvent servir de points de départ
- Le portfolio idéal montre ses connaissances avec un moteur de rendu temps réel en C++, un path tracer produisant des images photoréalistes, et du code comparant et validant les résultats des deux rendus
- Les mathématiques nécessaires se concentrent sur l’algèbre linéaire, la trigonométrie de base et un peu de calcul différentiel et intégral ; en développement de jeux, le langage côté CPU est C++, et le langage de shaders le plus courant est HLSL
Le graphisme temps réel couvre à la fois le CPU et le GPU
- Le rendu moderne ressemble en pratique à la combinaison de deux métiers
- Apprentissage côté CPU : programmation moteur pour les API explicites modernes comme DirectX12, Vulkan et Metal, le chargement d’assets et d’autres tâches de support
- Apprentissage côté GPU : mathématiques modernes de l’éclairage et du shading, ombres, occlusion ambiante, effets de post-traitement, différences entre les opérations rapides et lentes sur GPU
- Il est très difficile d’apprendre les deux domaines en même temps
- Pour se concentrer sur le GPU, on peut utiliser des outils où la charge côté CPU est plus faible, comme OpenGL, WebGL, DirectX11 ou un moteur existant
- Pour se concentrer sur le CPU, on peut commencer par afficher un triangle à l’écran, puis un mesh, sans trop se soucier de la beauté du résultat
Path tracing et PBR
- L’apprentissage côté GPU inclut l’écriture d’un path tracer
- Le path tracing est une méthode utilisée pour le rendu au cinéma, et c’est ce que les techniques modernes de rendu temps réel cherchent à approximer
- Comme ressource de départ, le livre gratuit en ligne Ray Tracing in One Weekend convient bien : il est accessible et montre comment produire un rendu proche d’une photo
- Le Physically Based Rendering (PBR) correspond à une façon de gérer l’éclairage, en particulier l’application du specular
- Le PBR est une approche fondée sur des principes : si l’on respecte les règles, on obtient de bons résultats
- Avant le PBR, on utilisait beaucoup de formules arbitraires, d’ajustements et de hacks pour l’éclairage ; un asset qui paraissait bon dans un environnement lumineux pouvait donc sembler trop sombre ou trop brillant dans un autre
- Il fallait alors créer différentes versions d’assets selon les conditions d’éclairage, ce qui demandait beaucoup de temps et d’efforts
- Le PBR permet aux assets d’apparaître de manière plus cohérente dans diverses conditions d’éclairage et réduit le temps et les efforts nécessaires à la création de versions multiples
- Malgré cela, le temps, le coût et l’effort de production des assets restent un important goulot d’étranglement dans le développement de jeux
Ressources d’apprentissage recommandées
- Pour débuter avec le PBR, la section PBR Theory de LearnOpenGL et ses sous-sections conviennent bien
- Pour aller plus loin, la documentation de Filament peut constituer l’étape suivante
- Plus on approfondit le PBR, plus le calcul différentiel et intégral ainsi que les statistiques apparaissent fréquemment
- Plus loin encore, il existe le livre gratuit en ligne Physically Based Rendering: From Theory To Implementation
- Le machine learning ne produira sans doute pas les résultats annoncés par le battage médiatique actuel, mais il reste utile d’apprendre les techniques d’ajustement et d’optimisation dans la boîte à outils de l’informatique
- Comme ressource liée, on peut consulter la vidéo Machine Learning For Game Developers
Code à montrer dans un portfolio
- Pour prouver ses connaissances à un recruteur, l’idéal est de mettre du code source partageable sur GitHub ou une plateforme similaire, et de le lier depuis son CV
- Exemples de portfolio :
- Un renderer de type moteur qui charge des assets, comme des modèles et des textures, et les rend en temps réel à l’écran
- Avec quelques effets comme l’éclairage et les ombres, le depth of field, les area lights, le tone mapping et les ray traced shadows
- Si possible, utiliser un éclairage basé sur le PBR, une caméra contrôlable par l’utilisateur, une API comme DX12 ou Vulkan, et C++
- Un path tracer générant des images photoréalistes
- C++ est préférable si possible, mais un programme sans fenêtre qui ne produit que des PNG convient aussi
- Il n’a pas besoin d’être temps réel
- C’est encore mieux si le path tracer est un mode séparé du renderer de type moteur
- Cela permet de comparer le résultat path traced avec le rendu PBR temps réel afin d’en vérifier l’exactitude
- Si l’on peut identifier les points où les deux rendus ne correspondent pas, expliquer pourquoi ils diffèrent et réfléchir à des moyens de les rapprocher tout en conservant le temps réel, cela sera encore mieux évalué
- Un renderer de type moteur qui charge des assets, comme des modèles et des textures, et les rend en temps réel à l’écran
Mathématiques, algorithmes et choix de langage
- En réalisant directement les éléments ci-dessus, on rencontre naturellement les mathématiques nécessaires
- Les bases nécessaires sont la multiplication de matrices en algèbre linéaire, le cross product, le dot product, la trigonométrie de base et un peu de calcul différentiel et intégral
- En graphisme et en développement de jeux, le minimum mathématique requis est relativement modeste, mais l’éventail des mathématiques utilisables est pratiquement illimité
- Les algorithmes sont similaires
- Il faut connaître les types de données abstraits et algorithmes de base comme les linked lists, les hash tables, le tri et la recherche
- Les algorithmes les plus rapides sont souvent simples, et les tableaux sont beaucoup plus rapides que les linked lists
- Les concepts algorithmiques plus avancés sont utiles lorsqu’on a réellement besoin de quelque chose de nouveau et sur mesure
- Le langage à apprendre pour le développement de jeux est C++
- Certaines personnes utilisent Rust, et il a une certaine présence, mais ce n’est pas le langage standard attendu
- WebGPU dispose de nombreuses fonctionnalités absentes de WebGL et devient une plateforme plus sérieuse, tout en permettant d’effectuer le travail côté CPU en JavaScript
- Cependant, on voit peu d’emplois WebGPU et de contenu WebGPU sur le Web
- Le langage de shaders le plus courant est HLSL
- Certains utilisent GLSL
- Dans les jeux multiplateformes, les shaders sont souvent convertis vers d’autres langages de shaders
Portée d’utilisation des LLM et du ML
- Les technologies de ML actuelles semblent insuffisantes pour la plupart des usages dans lesquels elles sont vendues
- Claude peut être utile pour discuter de mathématiques, d’articles scientifiques et d’algorithmes peu familiers
- Dans ces situations, il est facile de vérifier s’il invente des choses, et également facile de contrôler la validité avec d’autres sources
- Pour la programmation, ce n’est pas très utile
- Même si le code produit fonctionne comme souhaité, il faut passer du temps à le comprendre
- Dans ce cas, il semble préférable de l’écrire soi-même
- Les petits usages peuvent être utiles
- Par exemple, si l’on demande « vois-tu un bug dans ce fichier ? », on peut enquêter si la réponse est oui, et si la réponse est non, le coût de la question est quasi nul
- Il est probable que l’humanité créera un jour une intelligence artificielle de niveau humain et ira au-delà, mais il est impossible de savoir si cela arrivera de son vivant
- L’époque actuelle des LLM ressemble à une répétition générale en vue du moment où le « vrai » arrivera
1 commentaires
Avis de Hacker News
Il faut d’abord distinguer si l’on veut créer des jeux ou faire de la programmation de moteurs 3D.
Si l’on veut créer des jeux, mieux vaut utiliser un moteur existant comme Unreal Engine, Unity, Godot ou Bevy ; on apprendra les problèmes graphiques de plus haut niveau plutôt que la manière de pousser directement des pixels. Le vrai défi, c’est de rendre le jeu amusant.
Si l’on veut créer un moteur 3D, il faut savoir qu’il existe déjà beaucoup trop de mauvais moteurs de jeu. Rien que du côté de Rust, les principaux projets sont trois renderers ratés, un renderer inachevé et le renderer intégré à Bevy, et les projets qui annoncent « je vais créer un moteur de jeu » sont encore bien plus nombreux. Atteindre le niveau d’un « premier renderer » prend déjà environ deux ans, et arriver à de grandes scènes détaillées et dynamiques est une entreprise bien plus vaste.
Si l’objectif est l’emploi, l’industrie du jeu vidéo n’offre ni de bons salaires ni de bons horaires ; quand un projet se termine, le poste se termine aussi, et comme à Hollywood, les candidats qui veulent y entrer sont surabondants. En plus, à cause de l’effondrement du Metaverse, même les profils expérimentés sont aujourd’hui en excès.
Le mobile est un exercice de compression où l’écran, la puissance de calcul, le GPU et la batterie sont tous limités ; c’est pourquoi la plupart des jeux indés actuels sont en 2D. C’est ce qui reste faisable, et ils sont souvent faits aussi en HTML/JavaScript.
Mais créer un renderer de base et une boucle de jeu n’est pas si difficile, et il est probable que cela ne représente même pas la majeure partie du code du jeu. Pour un jeu simple, un
drawObject()dans une boucleforpeut suffire, et les préoccupations comme le streaming de ressources, l’optimisation des bindings ou le parallélisme peuvent attendre d’être réellement nécessaires.Je me demande quels point de départ et critères de réussite sont supposés derrière l’idée qu’il faut « deux ans pour un premier renderer ». Il y a environ un an, pendant mon temps libre, en un mois — moins d’une semaine à plein temps — j’ai créé un renderer différé avec éclairage dynamique, shadow mapping et quelques post-traitements.
Il n’y a pas non plus de raison de dénigrer la 2D. Une grande partie du travail sérieux se fait dans des interfaces 2D, et WebGL comme le vieux canvas 2D sont aujourd’hui assez puissants. Beaucoup de jeux indés à succès sont aussi en 2D.
Il est vrai que l’industrie du jeu n’est pas idéale, mais aujourd’hui presque tout utilise le GPU. L’écriture et le débogage de workloads de machine learning, la visualisation de données, les HUD et les interfaces utilisateur générales nécessitent souvent une compréhension du graphisme.
En dehors des jeux, il y a bien plus de domaines qui utilisent le graphisme, comme la visualisation ou la simulation, et les bons programmeurs graphiques sont extrêmement rares ; c’est donc une carrière étonnamment intéressante. C’est assez contrasté avec le fait qu’il semble plus difficile pour les développeurs de jeux ou les artistes d’obtenir de bons postes. Cela dit, l’offre comme la demande sont faibles, donc changer d’emploi peut ne pas être facile.
Si l’on regarde seulement la stabilité professionnelle, je déconseillerais de faire du développement de jeux une carrière, mais la programmation graphique est autre chose.
Parmi les jeux auxquels j’ai joué ces dernières années, Core Keeper (Unity), WORMHOLE (Unity, en particulier la latence du mode infini) et Crab Champions (UE4, où il faut utiliser un upscaling qui rend l’image laide pour maintenir 60 fps en 1920x1200) avaient de gros problèmes de performance.
À l’inverse, Terraria, Necesse et Barony utilisent leur propre moteur et tournent très bien ; plus ils vieillissent, meilleurs ils paraissent.
Pour être juste, Tiny Rogues (Unity) tournait globalement bien dans mon souvenir, mais comme le développeur travaille à quitter Unity à l’avenir, il semble avoir lui-même identifié un problème.
Je comprends la différence entre créer un jeu et créer un moteur, ainsi que l’importance de vraiment terminer et publier, mais si l’on sort quelque chose de médiocre, il est difficile de laisser un bon héritage. Même si cela implique de faire un détour, je pense qu’il vaut mieux garantir un certain niveau de qualité. Les jeux peuvent être joués pendant des décennies après leur sortie, et s’il y a des bugs ou de la latence, les gens continueront à les subir.
« Je vais d’abord créer mon moteur pour faciliter la création de mon prochain jeu » est un piège étonnamment puissant. C’est parce qu’on apprend vraiment des choses importantes et qu’on obtient chaque jour de petites victoires. On ajoute un unroll de plus pour rendre la scène plus fluide, une couche logique de plus au format de configuration pour faciliter la création de scènes, et on lit encore un article SIGGRAPH.
Il y a toujours quelque chose d’important à améliorer, mais tout cela ne s’assemble pas en un jeu terminé. Avec le recul, utiliser son propre moteur est une manière parfaite de repousser la partie difficile mais nécessaire du jeu dont rêve un technicien : « le rendre amusant ». On acquiert la compétence de coder un jeu vidéo impressionnant, mais on n’apprend pas à créer un jeu.
Il existe aussi des pièges secondaires. On apprend cent façons de créer de beaux effets visuels qui tournent en douceur en temps réel, mais pas comment les utiliser comme art.
Cela ressemble beaucoup au piège de l’« Enterprise Java ». C’est simplement plus subtil parce que l’on manipule des concepts concrets. Comme il n’y a pas de Factory Factory Interface dans le Scene Graph, on croit avoir évité cette balle, mais on passe en réalité à côté du fait que tout cela est inutile pour afficher un bitmap à l’écran et le faire réagir aux touches.
C’est particulièrement vrai en 2D. Par exemple, je crée actuellement un jeu avec mon propre moteur, en mettant l’accent sur les performances, la compression et une architecture sans serveur ni base de données.
Ce moteur contient une structure et des hypothèses très spécifiques sur l’organisation du jeu afin d’atteindre des performances et une compression extrêmes dans les contraintes que j’ai définies. Je prévois de publier bientôt, si possible la semaine prochaine, un billet à ce sujet sur Hacker News.
J’ai déjà essayé plusieurs fois de faire des jeux navigateur avec Unity, Godot et React, mais apprendre leurs API était pénible, et les moteurs ne satisfaisaient pas mes contraintes extrêmes. Bien sûr, c’est peut-être aussi parce que je ne les maîtrisais pas bien, mais avec le recul, je pense que ce que j’ai obtenu en interne aurait été impossible sans un moteur sur mesure créé depuis zéro.
J’ai énormément appris en créant moi-même le moteur et le jeu, et je pense qu’aujourd’hui, notamment grâce aux LLM, le fait pour un développeur expérimenté de créer son propre moteur de jeu adapté est soudain devenu réaliste pour la plupart des développeurs.
Aujourd’hui, je ne recommanderais à personne de se lancer dans la programmation graphique
J’ai commencé en 2001, au moment où Nvidia a présenté sa première GeForce 1, la fameuse « carte à shaders gigatexels », et depuis, le rythme des progrès et de l’innovation dans ce domaine a été vertigineux. Comparée à il y a 25 ans, la technologie actuelle est vraiment incroyable.
Mais cet émerveillement s’accompagne d’un gros « mais ». Le domaine évolue à une vitesse effrayante. Nvidia a même sorti des effets basés sur l’IA qui influencent les scènes et les assets ; à l’époque, on n’aurait jamais imaginé que ce genre de chose puisse être possible en temps réel.
Je ne sais même pas s’il est encore possible de devenir un « bon expert » dans ce domaine. Autrement dit, la question est : « où est le John Carmack d’aujourd’hui ? ». Il est devenu célèbre en poussant le matériel dans ses derniers retranchements et en exploitant des idées qui circulaient discrètement dans la communauté, mais aujourd’hui, quelqu’un comme lui ne semble plus disposer d’un avantage concurrentiel défendable. Le domaine est trop vaste et change trop vite pour qu’il y ait une occasion de devenir le prochain Carmack.
Il existe aussi un autre point de vue. Si, jusqu’ici, on n’a fait que des applications web et du Kubernetes, au contraire, essayer la programmation graphique peut être une très bonne idée. La boucle de feedback est grisante, et on prend conscience à quel point un ordinateur ordinaire est absurdement rapide. Même si l’on finit par optimiser des choses sans importance, cela garde de la valeur, parce qu’on n’a jamais appris à quel point les choses peuvent être rapides à bas niveau.
Les ressources sont nombreuses et les maths ne sont pas excessivement difficiles. La modélisation 3D peut aussi devenir un exutoire créatif qu’on ne soupçonnait pas. Même si cela ne s’applique absolument pas à son travail principal, on en ressort avec une nouvelle appréciation de l’art qu’est la programmation informatique, et on décidera peut-être de ne plus jamais toucher à Kubernetes et de consacrer cinq ans de son temps libre à écrire son propre moteur de jeu.
Des fous comme ça, il y en a beaucoup, et la communauté des développeurs amateurs qui n’ont pas été usés par le développement de jeux professionnel est plus grande qu’on ne l’imagine. Le Discord Graphics Programming est aussi un espace accueillant qui vaut le détour. Il suffit d’essayer.
Pour quelqu’un qui se fiche de ce qu’il fait concrètement et veut seulement changer de carrière, le conseil d’éviter ce domaine peut être juste. Mais ce n’est pas une bonne manière de vivre. Mieux vaut suivre ce que l’on trouve intéressant et précieux, apprendre sans cesse de nouvelles choses et se lancer des défis. Alors la question de savoir s’il faut apprendre l’informatique graphique devient relativement claire, et pour la bonne personne, le bilan est positif. Même si cela ne devient pas un métier, les compétences se transfèrent bien vers beaucoup d’autres domaines.
Il n’est pas nécessaire d’être aussi connu que l’une des personnes les plus célèbres d’un domaine ; on peut aussi simplement le faire par plaisir. Les mathématiques et l’art de la programmation graphique et du jeu sont beaux en eux-mêmes.
Ma raison de ne pas vouloir conseiller la programmation graphique est différente. Les moteurs 3D avec des sommets et des textures existeront-ils encore dans quelques années ? Ou bien tout sera-t-il rendu directement par des modèles du monde IA ? Quelle quantité de code y aura-t-il dans les jeux, ou bien existeront-ils sous forme d’une suite de prompts intelligemment rédigés ?
Si vous avez besoin d’un tutoriel rapide d’algèbre linéaire, vous pouvez consulter celui que j’ai écrit, imprimable en 4 pages : https://minireference.com/static/tutorials/linear_algebra_in...
Il y a aussi ici un notebook avec des exemples de code SymPy : https://github.com/minireference/noBSLAnotebooks
Grâce aux visualisations, des choses que je n’avais pas comprises dans le cours Linear 101 m’ont soudain paru évidentes.
Je suis un peu surpris qu’il ne soit pas question de comprendre les principes de base du design ou les caractéristiques de la perception humaine.
Mon frère était artiste de production sur des jeux vidéo célèbres des années 90 et 2000, et il se plaignait sans cesse des programmeurs et des managers qui n’avaient aucun sens visuel et aucune curiosité pour le point de vue des artistes.
Le graphisme n’est pas mon domaine, mais en tant que musicien, sound designer et producteur, les codeurs DSP audio les plus efficaces et influents que je connaisse comprennent les bases de la musique, la physique et l’acoustique du son, ainsi que les pièges entre le traitement numérique discret et la manière dont nous percevons et interprétons les stimuli.
Qu’un programmeur graphique ait une sensibilité artistique aide, mais comme il travaille généralement à un niveau assez bas, ce n’est pas indispensable pour réussir.
L’IA a changé un peu l’équation, ou a au moins le potentiel de le faire, mais je pense qu’une bonne partie de la vague « apprendre à coder » du milieu des années 2000 venait aussi de là. Il s’agissait de traiter le développement logiciel comme une « fonctionnalité, pas un produit » pour les experts d’un domaine existant, afin que les personnes qui connaissent le mieux le domaine créent directement le logiciel, au lieu de traduire les besoins à une équipe de développement.
Honnêtement, la programmation graphique est le plus souvent une sorte de rôle de service : permettre à ces personnes de faire ce qu’elles veulent faire, ou les aider à créer ce qu’elles ont imaginé.
Inigo Quilez est souvent cité comme exemple de programmeur graphique qui est aussi artiste ; c’est vraiment une personne puissante, presque une licorne.
Personnellement, je préfère jouer de la musique et la programmation audio, et c’est une bonne base pour apprendre le DSP. Par exemple, si l’on pousse le bruit de rendu vers les hautes fréquences, un filtre passe-bas peut parfois être plus efficace pour supprimer le bruit.
Si cela éveille votre curiosité et que vous avez du temps, ça vaut la peine d’apprendre. C’est vraiment amusant, on apprend beaucoup, et cela fait de vous un meilleur ingénieur dans plusieurs autres domaines de l’informatique. On comprend le matériel, la programmation système, le modèle machine du programmeur, etc.
Mais si l’argent est votre objectif final, mieux vaut ne pas l’apprendre. De nos jours, la récompense est fugace, temporaire et non garantie.
Je m’intéresse à la programmation graphique depuis longtemps et j’ai commencé à apprendre Vulkan en autodidacte il y a quelques années. Je ne sais pas combien de temps j’y ai passé au total, mais probablement environ 6 mois de temps libre le soir, peut-être un peu moins. J’ai construit quelque chose qui ressemblait à un framework de rendu.
Mais c’est le genre de domaine où, plus on avance, plus on se rend compte de tout ce qu’on ignore. Au moment où l’on se dit que la structure est correcte, on découvre que ce n’est pas la bonne architecture.
Au fond, ce qu’on fait, c’est essentiellement des mathématiques appliquées à l’éclairage, et le reste, c’est de la plomberie. On se demande « pourquoi le spot traverse-t-il le cube comme s’il n’existait pas ? », puis on réalise qu’il faut calculer les ombres, et on passe des semaines à creuser comment intégrer ça au pipeline de rendu. Cela dit, si vous aimez ce genre de choses, c’est assez « amusant ».
Par exemple, même pour créer des ombres, il faut écrire facilement 10 fois plus de code que ce que la technique elle-même exige intrinsèquement.
Pour apprendre la programmation graphique, je pense qu’écrire un moteur de rendu logiciel est beaucoup plus plaisant. Il y a moins de code, et le code que l’on écrit touche au cœur du sujet plutôt qu’au boilerplate. L’inconvénient, c’est que l’on perd l’accélération matérielle, donc c’est plus lent.
Si vous voulez simplement créer des jeux, vous pouvez utiliser un moteur de jeu comme Unity, Godot ou Unreal.
Si vous voulez faire du graphisme au niveau moteur, simulation ou renderer, il faut apprendre un langage bas niveau et une API graphique. Côté langage, je recommande C++ ; C ou Rust peuvent aussi convenir, mais C est un peu difficile et les API graphiques sont déjà compliquées, donc vous n’aurez probablement pas envie de vous battre aussi avec le langage. Rust peut aussi être un bon choix, mais personnellement je trouve les temps de compilation très lents et la syntaxe laide.
Côté API, je recommande OpenGL. C’est multiplateforme, ancien — ce qui est à la fois un avantage et un inconvénient — et c’est le plus facile du lot.
learnopengl.com est de loin le meilleur tutoriel OpenGL, donc je vous conseille de le suivre.
Après avoir utilisé OpenGL pendant un certain temps, vous pourrez élargir vers Vulkan ou vers des bibliothèques graphiques implémentant plusieurs API ; ou bien continuer avec OpenGL si cela vous convient.
Ce n’est clairement pas facile, mais je pense que c’est l’un des domaines les plus fascinants de l’informatique.
Je suis mal placé pour le dire, mais la communauté est aussi formidable. Le web est un excellent moyen de partager ce que l’on crée pendant l’apprentissage, de recueillir des retours et de gagner en visibilité. Beaucoup de personnes de la communauté ont fini par se spécialiser professionnellement en 3D graphique.
Quand je retourne parfois voir le dépôt, le code de l’époque est tellement en désordre que j’en ai honte, mais sans ce projet, je ne serais probablement pas là où je suis aujourd’hui.
On commence avec des balises simples, on ajoute des animations, puis si cela ne suffit pas, on ajoute des composants de la communauté. Si cela ne suffit toujours pas, on peut modifier avec ThreeJS, voire aller jusqu’aux shaders. A-Frame est excellent.
En plus, on peut aussi faire de l’AR et de la VR.
Plutôt que de « devenir programmeur graphique », pourquoi ne pas simplement faire de la programmation graphique ? Commencez par des choses simples jusqu’à en saisir l’idée, et quand vous verrez qu’au fond il s’agit d’envoyer de la logistique au GPU, vous pourrez empiler toutes sortes de concepts complexes par-dessus.
C’est comme gravir une petite montagne puis, soudain, tout s’emboîte et on se dit « waouh… ». On commence à voir les possibilités et tout ce qu’on peut expérimenter.
Dire « je suis grimpeur », « gamer », « artiste », « mère », « père », « accro à la salle de sport », « programmeur graphique » ne désigne pas nécessairement un métier, mais suggère quelque chose de plus profond qu’une implication légère et passagère.
Aujourd’hui, j’ai appris le format d’image PPM, et il est très accessible pour ce genre d’usage. Écrire un bitmap n’est pas non plus de la science-fusée, mais PPM est encore plus simple.