Technologies Créatives. p5.js ou openFrameworks : le guide de l'art génératif

p5.js ou openFrameworks: le guide de l’art génératif

Dans l’art génératif, le choix de l’outil apparaît souvent après le premier obstacle matériel: une simulation qui ralentit, une interaction qui répond trop tard, un projecteur qui ne reçoit pas le bon signal, une installation qui fonctionne sur l’ordinateur de l’artiste mais pas sur celui de l’exposition. À ce moment-là, p5.js et openFrameworks ne sont plus deux manières élégantes d’écrire du code. Ce sont deux rapports très différents au rendu, à la machine et au lieu d’exposition.

p5.js ouvre immédiatement une fenêtre sur le navigateur. Une ligne de JavaScript, un élément Canvas, quelques formes: l’image est visible, partageable, modifiable. openFrameworks demande davantage de préparation, mais donne en retour un accès plus direct à OpenGL, au son, aux périphériques et aux ressources de la machine. Pour choisir entre p5.js ou openFrameworks pour l’art génératif, il faut donc partir de l’œuvre à produire, pas de la popularité supposée d’un langage.

L’accessibilité immédiate: la philosophie du Web avec p5.js

p5.js est une bibliothèque JavaScript conçue pour rendre le code créatif accessible aux artistes et aux débutants. Elle s’inscrit dans la continuité conceptuelle de Processing, dont le développement initial remonte à 2001, mais elle ne constitue pas le même langage: p5.js fonctionne nativement avec JavaScript et l’environnement Web, tandis que Processing repose sur Java.

Cette différence n’est pas un détail de vocabulaire. Elle change le premier contact avec l’outil.

Avec p5.js, le rendu peut être exécuté directement dans un navigateur, via Canvas HTML5 ou WebGL. Le navigateur devient à la fois la surface de test, le cadre de diffusion et une partie de l’atelier. L’artiste écrit une fonction, recharge la page, observe le comportement, modifie une valeur, recommence. L’itération est courte. Elle laisse de la place aux accidents, aux variations de paramètres et aux petits défauts de calcul qui finissent parfois par devenir le langage visuel de l’œuvre.

Le p5.js Web Editor réduit encore la distance entre l’idée et l’image. Il permet de coder, tester et partager un projet sans installer d’environnement de développement local. Pour un atelier pédagogique, une résidence avec des participants peu familiers de la programmation ou une série d’expérimentations destinées à être consultées en ligne, cette simplicité compte davantage qu’une performance théorique.

Le navigateur impose cependant son propre cadre. Il faut composer avec le modèle d’exécution de JavaScript, le fonctionnement du Canvas, la mémoire disponible et la charge des autres éléments de la page. Pour une composition de lignes, de formes, de textures ou de mouvements relativement légers, la contrainte reste discrète. Elle devient visible quand le nombre d’éléments augmente ou quand chaque élément doit recalculer sa position, sa vitesse, ses interactions et son apparence à chaque image.

p5.js raccourcit la distance entre une intuition et un premier rendu. Sa force n’est pas de tout absorber, mais de rendre l’itération presque immédiate.

Cette immédiateté favorise une pratique particulière du code créatif. On travaille dans le visible. Les paramètres sont exposés, les erreurs apparaissent vite, le résultat se partage par une page Web plutôt que par un programme à installer. Dans le contexte de l’art algorithmique, c’est un outil très efficace pour produire:

• des compositions génératives destinées au navigateur;
• des études de formes, de couleurs et de mouvements;
• des expériences interactives simples utilisant le clavier, la souris ou les gestes tactiles;
• des prototypes d’installation avant un passage vers un environnement plus exigeant;
• des œuvres dont la diffusion doit rester accessible depuis une page Web.

La contrepartie est que l’image reste liée à une chaîne de rendu pensée pour le Web. Ce n’est pas nécessairement un défaut. Le navigateur peut être le médium exact de l’œuvre. Mais il faut éviter de traiter p5.js comme une version allégée d’un outil conçu pour piloter une installation complexe. Le projet peut commencer dans un éditeur en ligne; son exposition, elle, demandera peut-être une autre architecture.

La puissance brute: le contrôle matériel et OpenGL dans openFrameworks

openFrameworks adopte une position différente. Il s’agit d’une boîte à outils open-source écrite en C++, conçue pour le code créatif et directement reliée à OpenGL pour le rendu graphique. Elle prend également en charge le son et les interactions. L’artiste ne travaille plus seulement dans la fenêtre d’un navigateur: il construit une application qui exploite plus directement le système sur lequel elle s’exécute.

Ce déplacement a des conséquences très concrètes. openFrameworks est distribué sous la forme d’une bibliothèque non compilée, avec une structure de dossiers qui comprend notamment addons/, apps/ et libs/. Le projet doit être configuré dans un environnement de développement comme Xcode, Visual Studio ou Visual Studio Code. Il faut gérer la compilation, les dépendances, les bibliothèques additionnelles et les différences entre les systèmes.

Le premier geste n’est donc pas de dessiner. C’est de préparer l’atelier.

Pour une personne qui découvre la programmation, la distinction est nette. openFrameworks n’est pas l’outil le plus direct lorsque l’objectif consiste à afficher une première forme en quelques minutes. Les notions de C++, de compilation et de gestion des dépendances entrent rapidement dans le travail. Elles ne sont pas périphériques: elles conditionnent la capacité à lancer, corriger et déployer le projet.

En revanche, cette préparation donne accès à une maîtrise plus fine du rendu et du matériel. Une installation qui reçoit des données de capteurs, synchronise plusieurs sorties vidéo, traite du son en temps réel ou manipule un grand nombre d’éléments visuels peut bénéficier de cette proximité avec OpenGL et les ressources de la machine.

La différence entre p5.js et openFrameworks ne se résume donc pas à JavaScript contre C++. Elle concerne la place du logiciel dans la fabrication de l’œuvre:

Il faut lire ce tableau comme une carte de contraintes, pas comme un classement. La facilité de p5.js devient un avantage structurel lorsque la diffusion en ligne fait partie du projet. La complexité d’openFrameworks devient productive lorsque l’installation ne peut pas être séparée de ses écrans, de ses capteurs, de ses haut-parleurs ou de ses contraintes de synchronisation.

Performance et limites: quand le JavaScript rencontre ses plafonds

La performance n’est pas une abstraction réservée aux ingénieurs. Dans une œuvre générative, elle se voit dans le mouvement. Une nuée de particules ne ralentit pas seulement l’ordinateur: elle perd sa densité, son rythme, parfois sa qualité de présence. Un geste capté par une caméra arrive trop tard. Une image censée vibrer devient une succession de recalculs visibles.

p5.js peut subir des ralentissements importants lorsqu’un algorithme traite un grand nombre d’éléments. Dans des simulations lourdes, comme certains systèmes de déplacement collectif ou de flocking, la fréquence d’affichage peut tomber à une ou deux images par seconde. À ce niveau, le problème ne relève plus d’un simple confort de navigation. L’itération elle-même est interrompue: l’artiste ne peut plus juger la relation entre le code et le mouvement en temps réel.

Plusieurs facteurs se cumulent:

1. Le nombre d’éléments augmente.

Chaque particule, ligne ou agent peut exiger plusieurs calculs à chaque image. Lorsque la scène devient dense, le temps consacré à la mise à jour des positions et des interactions s’allonge.

2. Les calculs deviennent interdépendants.

Une forme isolée coûte peu. Un ensemble dans lequel chaque élément observe ses voisins, évite les collisions ou suit un champ de forces demande davantage de travail.

3. Le rendu et la logique se disputent les mêmes ressources.

La génération de formes, le calcul des mouvements, la gestion des entrées et l’affichage doivent se succéder sans créer de file d’attente perceptible.

4. Le navigateur ajoute son propre environnement d’exécution.

p5.js n’est pas lancé dans un espace vide. Le Canvas, la page, les autres scripts et les limites du navigateur participent au comportement final.

openFrameworks, grâce au C++ et à son accès à OpenGL, est mieux armé pour conserver une fréquence d’affichage élevée dans ce type de situation. Pour des simulations lourdes, il peut maintenir un affichage fluide autour de 60 images par seconde, là où une implémentation JavaScript équivalente peut décrocher fortement. Cette comparaison ne constitue pas un résultat garanti pour tous les projets: la qualité du code, la carte graphique, la résolution et l’architecture de l’installation restent déterminantes. Elle indique néanmoins une orientation claire.

Quand le rendu doit rester stable sous charge, openFrameworks offre davantage de marge.

Cette marge est précieuse dans une exposition. Une image qui tourne seule sur l’ordinateur de l’artiste n’est pas encore une installation fiable. Il faut considérer la durée d’allumage, la résolution de sortie, les redémarrages, les câbles, le son, les capteurs et les moments où le public intervient de manière imprévisible. Le code créatif quitte alors le statut d’esquisse pour devenir une pièce opératoire.

La question du rendu ne se limite pas à la vitesse

Il serait pourtant réducteur de choisir openFrameworks dès qu’un projet contient beaucoup de formes. La sensation de lourdeur peut aussi venir d’une mauvaise organisation du code ou d’un choix de rendu disproportionné. Dans p5.js, une première version peut servir à isoler le problème: nombre d’éléments, fréquence de recalcul, taille du Canvas, type de texture ou nature des interactions.

Cette phase de prototypage a une valeur artistique. Elle permet de vérifier si le mouvement est réellement nécessaire, si la simulation peut être simplifiée, si le glitch apparaît dans le bon endroit ou si l’œuvre repose seulement sur une accumulation d’effets. La contrainte logicielle agit alors comme un filtre de production. Elle oblige à décider ce qui doit être recalculé, ce qui peut être précalculé et ce qui peut rester fixe.

La question à poser n’est pas seulement: combien d’images par seconde le projet produit-il? Il faut aussi demander: quelle partie de cette fréquence sert l’œuvre? Une animation lente, composée de transformations progressives, ne réclame pas le même budget qu’une interaction instantanée avec plusieurs flux de données.

Du premier résultat à l’application exposée

Le workflow constitue souvent la différence la plus sensible entre les deux outils.

Avec p5.js, l’éditeur en ligne permet d’entrer directement dans la matière. Le projet est organisé autour du code, du navigateur et du résultat visible. Les corrections sont rapides. Une valeur modifiée se teste sans passer par une chaîne de compilation. Le partage est presque aussi simple: un projet peut être montré à distance, intégré dans une page ou transmis à une personne qui n’a pas besoin de configurer toute la machine.

Cette fluidité convient aux œuvres qui assument une logique de publication. Elle convient aussi aux ateliers où le temps disponible doit rester concentré sur les formes, les règles et les variations plutôt que sur la préparation technique. Pour une exposition numérique accessible depuis un site, p5.js peut être le médium et non une simple étape de préproduction.

Mais le passage à une installation physique introduit rapidement d’autres questions. Comment l’œuvre se lance-t-elle après un redémarrage? Que se passe-t-il si le navigateur perd le plein écran? Le rendu doit-il s’adapter à plusieurs dimensions? Les interactions sont-elles compatibles avec les périphériques réellement disponibles? La page Web doit-elle charger des ressources externes ou fonctionner sans réseau?

openFrameworks oblige à rencontrer ces questions plus tôt. La compilation ralentit le geste, mais elle rend explicite la fabrication d’un programme autonome. Le projet est structuré dans des dossiers, relié à des bibliothèques, préparé pour une machine donnée. Les modules additionnels peuvent étendre les capacités de l’application, à condition d’accepter le travail de configuration qu’ils impliquent.

Dans p5.js, l’environnement disparaît derrière l’image. Dans openFrameworks, il devient une partie visible de la fabrication: dossiers, dépendances, compilation, périphériques.

Cette lourdeur n’est pas toujours un défaut de conception. Elle peut correspondre à la réalité d’une œuvre qui doit dialoguer avec son lieu. Un dispositif interactif ne se résume pas à son image finale: il dépend de la latence, de la stabilité du signal, de l’ordre de démarrage et de la façon dont les données entrent dans le programme.

Pour un projet appelé à circuler entre plusieurs ordinateurs, la question de la reproductibilité devient centrale. p5.js facilite la transmission d’une expérience Web, mais reste tributaire du navigateur et de ses conditions d’exécution. openFrameworks permet de construire une application plus étroitement contrôlée, mais chaque configuration matérielle peut demander une préparation spécifique.

Le choix engage donc aussi le temps disponible après la création. Une œuvre peut être visuellement convaincante et pourtant coûteuse à maintenir. Un correctif de dernière minute, une nouvelle résolution d’écran ou un périphérique remplacé peuvent transformer l’exposition en session de dépannage. Le meilleur outil est alors celui qui laisse une réserve de travail à l’artiste, pas seulement celui qui produit le rendu le plus spectaculaire.

Quel outil de code créatif choisir selon l’installation?

Le comparatif p5.js et openFrameworks devient plus lisible lorsqu’on décrit la nature de la pièce avant de parler de technologie. Les deux environnements peuvent produire du code génératif, de l’art algorithmique et des formes procédurales. Ils n’occupent simplement pas le même endroit dans la chaîne de production.

Pour une œuvre Web ou un prototype partagé

p5.js est le choix le plus cohérent lorsque l’œuvre doit être consultée depuis un navigateur. Son éditeur en ligne permet de démarrer sans installation locale, et son modèle de partage réduit les obstacles pour les collaborateurs, les étudiants ou le public.

Il convient particulièrement à une recherche où l’image doit rester ouverte aux modifications. Les paramètres peuvent être exposés, les variantes publiées, les erreurs observées dans différents contextes. Cette souplesse nourrit une esthétique de l’itération: le code n’est pas seulement le mécanisme caché de l’image, il devient parfois sa structure lisible.

Pour un artiste qui travaille sur des compositions génératives en deux dimensions, des systèmes de motifs, des transformations de couleur ou des interactions simples, p5.js offre un rapport travail-résultat très efficace. On peut consacrer l’énergie à la règle visuelle plutôt qu’à l’installation du projet.

Pour une installation interactive lourde

openFrameworks prend l’avantage lorsque l’œuvre dépend fortement de la machine et de ses périphériques. Son intégration avec OpenGL, le son et les interactions permet de construire des applications adaptées à des dispositifs plus complexes.

Cela peut concerner une installation multi-écrans, une visualisation qui doit rester fluide avec un grand nombre d’éléments, une pièce qui traite des données en temps réel ou un dispositif dans lequel le son et l’image doivent rester étroitement coordonnés. La puissance du C++ ne résout pas tout, mais elle offre une base plus solide lorsque le rendu est soumis à une charge importante.

Il faut toutefois accepter la phase de préparation: installation de l’environnement, organisation des dossiers, configuration de l’IDE, compilation et gestion des bibliothèques. Pour une exposition, cette dépense initiale peut être rentable. Pour une étude de quelques jours destinée à être consultée en ligne, elle risque de déplacer inutilement l’attention.

Pour apprendre le code créatif

p5.js est généralement plus accessible pour commencer. L’exécution dans le navigateur rend chaque modification lisible et réduit le nombre d’obstacles non artistiques. L’apprenant peut comprendre progressivement les variables, les boucles, les fonctions et les règles de génération sans devoir résoudre immédiatement les problèmes de compilation.

openFrameworks peut venir ensuite, lorsque la logique de programmation est déjà plus stable ou lorsque le projet exige un contrôle que l’environnement Web ne fournit pas facilement. Le passage au C++ ne consiste pas à ouvrir une version plus puissante du même atelier. Il demande d’accepter une autre discipline: types de données, organisation des fichiers, bibliothèques, construction du projet et relation plus explicite avec le système.

Pour une pièce hybride

Le choix n’est pas forcément définitif. Une œuvre peut être pensée dans p5.js, où les paramètres et la composition se testent rapidement, puis réécrite dans openFrameworks si la version exposée dépasse les capacités du navigateur. Cette translation n’est pas automatique. Les deux environnements ne partagent ni le même langage ni exactement les mêmes abstractions de rendu. Le prototype doit donc être considéré comme une étude de comportement, pas comme un programme qu’il suffirait de copier.

Cette distinction est utile. Elle évite de demander au premier outil de porter toute la charge du projet. p5.js peut servir à trouver le rythme d’une simulation, la densité d’un motif ou la relation entre une entrée et une transformation. openFrameworks peut ensuite prendre en charge la version qui doit fonctionner plusieurs heures, gérer plusieurs flux ou répondre à des contraintes matérielles précises.

Le médium se décide dans les contraintes

Choisir entre p5.js et openFrameworks pour l’art génératif revient finalement à choisir la nature de la contrainte que l’on accepte.

Avec p5.js, la contrainte vient du navigateur, du JavaScript et d’un cadre de rendu conçu pour être immédiatement accessible. En échange, l’artiste gagne une vitesse d’itération, une simplicité de partage et une entrée directe dans l’image. Avec openFrameworks, la contrainte se déplace vers la configuration, le C++ et la maintenance de l’application. En échange, le projet gagne en contrôle matériel, en marge de performance et en capacité à devenir une installation autonome.

Le bon choix n’est donc pas le framework présenté comme le plus professionnel ou le plus puissant. C’est celui qui correspond au geste que l’œuvre doit répéter. Si le geste consiste à générer, observer, modifier et publier, p5.js reste remarquablement efficace. Si le geste consiste à capter, calculer, synchroniser et maintenir un dispositif en fonctionnement, openFrameworks donne une assise plus adaptée.

L’art génératif ne naît pas d’une absence de contraintes. Il se construit avec elles, parfois contre elles. Dans p5.js, la contrainte du Web peut devenir une esthétique de la diffusion et de l’itération. Dans openFrameworks, la contrainte de la compilation peut conduire à une œuvre plus étroitement liée à ses écrans, à son son et à ses capteurs. Le logiciel cesse alors d’être un simple outil de production: il redéfinit le médium que l’artiste est en train de fabriquer.