Discussion :

[LittleWhite]

Le WebGL a t-il un avenir ?

WebGL est la spécification d'une bibliothèque graphique 3D au même niveau que OpenGL ou Direct3D. Celle-ci repose sur OpenGL ES 2.0 (la spécification pour l'embarqué de OpenGL) et permet de créer des pages Internet intégrant du contenu 3D. Ainsi, à l'aide de HTML 5 et du Javascript vous pouvez afficher un rendu accéléré par la carte graphique et bénéficiant donc de la puissance du GPU.

Actuellement, les principaux navigateurs présents sur le marché disposent du support de WebGL :

• Firefox (6 juillet 2010)
• Google Chrome(3 février 2011)
• Safari (20 juillet 2011)
• Opera (14 juin 2012)
• Internet Explorer (17 octobre 2013).
• les versions mobiles de Firefox, Opera et du navigateur de Blackberry supportent également WebGL.

Pendant un long moment, Internet Explorer a été un frein au développement de cette technologie mais depuis fin 2013, la onzième version du navigateur la supporte. On notera aussi le possible second frein lorsque des failles de sécurité critiques ont été découvertes dans le standard même, entraînant notamment la vive réaction de la communauté et de Microsoft.

Il ne faut pas non plus oublier que l'accélération graphique dans WebGL est disponible uniquement que si la carte graphique implémente correctement la spécification. Cela a aussi provoqué une certaine lenteur dans l'évolution du support d'OpenGL, notamment sous Linux où il était peu présent. Maintenant, nous pouvons dire que ces soucis sont globalement résolus.

Malgré cela, la technologie n'est pas désuète. En effet, elle a une place de plus en plus importante et les différents acteurs se dirigent vers cette solution (Unity Technologies, Epic Games...). En effet, Flash est de plus en plus abandonné (et son intégration de la 3D fut laborieuse et n'était d'ailleurs pas portable), WebGL est un standard disposant de nombreux avantages. Le plus clair et le plus visible pour l'utilisateur est le fonctionnement immédiat des pages intégrant WebGL. En effet, contrairement à une solution comme celle proposée dans Unity et nécessitant un module à installer sur la machine, WebGL est disponible dans le navigateur de l'utilisateur sans rien avoir à faire en plus. Comme indiqué ci-dessus, le support est présent sur une majorité de machines et même de mobiles.

WebGL a toutefois quelques limitations :

• absence de tampon de sélection ;
• absence de textures 3D ;
• absence de geometry shader.

Mais tout cela sera résolu dans la nouvelle spécification WebGL 2.0 dont l'étude a commencé en 2012.


De nombreuses bibliothèques 2D et 3D ont vu le jour pour les développeurs. Elles permettent de faciliter le développement des applications tout en bénéficiant des apports de WebGL. On peut maintenant dire que la technologie est répandue et facile à prendre en main. De plus, il est possible de convertir un programme C et C++ à l'aide de compilateurs tel que Emscripten. La 3D n'est pas perdue grâce à la bibliothèque WebGL.

Chez les concurrents, on ne peut pas vraiment citer d'alternatives répandues. Il existe Adobe Flash 11, mais celui-ci est de plus en plus abandonné et n'a jamais permis d'avoir une application 3D autre que sous Windows. Il existe aussi le Native Client de Google proposant lui aussi une accélération graphique (reposant aussi sur OpenGL ES 2.0), mais son fonctionnement est complètement différent de WebGL. En effet, le Native Client est une sandbox où le code natif est exécuté puis afficher dans le navigateur.

Finalement, il n'y a toujours pas d'application phare pour cette technologie. De plus, pour les jeux vidéo et les applications intensives le JavaScript et la surcouche apportée par le navigateur peut être aussi un facteur décisif et ainsi empêcher l'adoption de ce standard.


Votre opinion

Croyez-vous que le WebGL a un avenir ? Comment voyez-vous cet avenir ?
Qu'aimeriez-vous voir dans le futur du Web et des site intégrant du contenu 3D ?


Voir aussi

Retrouvez une série complète de tutoriels sur WebGL sur Developpez.com

[jean_kevin_musclor]

Oo impressionné comment t'as trop bien réecrit mon post La prochaine fois que je veux lancer un débat je te l'envoie directement par mp.

Pour répondre au quizz:

je ne sais pas si WebGL a un avenir. comme je disais, la 3d ça coute un bras, je ne sais pas combien de temps mozilla google microsoft vont continuer à investir là dedans

histoire de pas prendre de risques je vais rester sur du low-poly des années 50, au pire ça sera rattrapable en rendu software

[Dabou Master]

histoire de pas prendre de risques je vais rester sur du low-poly des années 50, au pire ça sera rattrapable en rendu software

Ahem, c'est-à-dire un cube ? Non parce que le high-poly des années 50 étant nettement moins chargé que les low-poly qu'on peut trouver actuellement, je me dis que tu es parti un peu trop loin dans le passé là .

[Sodium]

Je n'ai jamais compris l'intérêt d'afficher une application 3d dans un browser et encore moins comme l'on peut souhaiter vouloir coder ce genre d'applications en javascript.
Si le but est de ne pas avoir à installer le jeu sur sa machine, je trouve le principe d'un plugin comme Flash beaucoup plus intelligent.
À vouloir transformer notre navigateur en seul point d'entrée du contenu informatique, on y perd toujours plus en performance et en ergonomie.

[jean_kevin_musclor]

Je n'ai jamais compris l'intérêt d'afficher une application 3d dans un browser et encore moins comme l'on peut souhaiter vouloir coder ce genre d'applications en javascript.
Si le but est de ne pas avoir à installer le jeu sur sa machine, je trouve le principe d'un plugin comme Flash beaucoup plus intelligent.
À vouloir transformer notre navigateur en seul point d'entrée du contenu informatique, on y perd toujours plus en performance et en ergonomie.

Flash plugin non c'est pas conçu pour des jeux vidéo, juste du multimédia grossier (vidéo, son, cartoon).

Pour les jeux y'a le plugin unity.

Javascript ça n'a jamais servi à faire des jeux vidéo (on peut s'amuser à en bricoler certes mais ça ne donnera rien de bon, ça sera lent, bouffe-cpu, memory-leaké, comme flash mais en pire).

Webgl c'est juste pour faire des petites applis avec de la 3d rudimentaire, c'est utilisé par exemple pour les cartes de google maps ou greenpeace.

Mais c'est ça que je trouve intéressant dans le webgl justement, faire de la 3d pour des choses plus nourrissantes que les jeux vidéo. L'embauche dans les jeux en france c'est mort, par contre dans le webdesign y'a de l'emploi.

[Neckara]

Bonjour,

Javascript ça n'a jamais servi à faire des jeux vidéo (on peut s'amuser à en bricoler certes mais ça ne donnera rien de bon

C'est vrai que tous les jeux doivent avoir des graphismes de fou pour être un bon jeux ...

C'est vrai que des jeux JavaScript comme candy box 2 ne sont pas du tout de bon jeux .

[scandinave]

fluide c'est 60 fps
là j'en ai 3 sur chrome

Tu doit avoir un problème de pilote graphique ou autre, parce qu'avec un chipset integré c'est parfaitement fluide. Les 60 fps sont la.

donc de toutes façons on a pas trop le choix on doit se contenter du javascript tout pourri

Javascript à plusieurs défaults mais il à aussi d'énorme qualité.

• aucune compilation
• support universel ( meme ie6 le supporte)
• typage dynamique
• orienté prototype/object

Alors c'est tout sauf un langage tout pourri. encore une fois libre a toi de ne pas l'utiliser.

[super_navide]

Moi je dis oui pour faire de la 3D dans sans navigateur ca deviendra indispensable pour tous type d'application.
Mais OpenGL est peut-être un peut trop bas niveau, je pense qu'il faudrait étendre la spécification HTML pour y intégrer un moteur 3D.
avec des API implémenté directement par le navigateur, une sorte de DOM mais pour la 3D.

[super_navide]

Tu doit avoir un problème de pilote graphique ou autre, parce qu'avec un chipset integré c'est parfaitement fluide. Les 60 fps sont la.


Javascript à plusieurs défaults mais il à aussi d'énorme qualité.

• aucune compilation
• support universel ( meme ie6 le supporte)
• typage dynamique
• orienté prototype/object

Alors c'est tout sauf un langage tout pourri. encore une fois libre a toi de ne pas l'utiliser.

Je suis tout à fait d'accord .

javascript est le meilleur langage pour apprendre à programmer.
nodejs fait 5 mega
tu le lance
et tout de suite tu peux expliquer une variable
e = []
tu affecte
console.log(e)
tu affiche
tu ajoute un élément
e.push("hello")
tu vérifie la modification
console.log(e)
donc il y a pas plus simple pour débuter.

[Fooshi]

Je n'ai jamais compris l'intérêt d'afficher une application 3d dans un browser et encore moins comme l'on peut souhaiter vouloir coder ce genre d'applications en javascript.
Si le but est de ne pas avoir à installer le jeu sur sa machine, je trouve le principe d'un plugin comme Flash beaucoup plus intelligent.
À vouloir transformer notre navigateur en seul point d'entrée du contenu informatique, on y perd toujours plus en performance et en ergonomie.

Afficher une application 3D dans un browser, il y a des tonnes d'applications. Dans ma société on en a besoin constamment, nous travaillons pour des promoteurs immobiliers , on leur proposer donc une modélisation 3D des bâtiments qui est présenté sur une application mobile et sur le web. Le programme immobilier est donc présenté en multi canal et est un formidable outil d'aide à la vente.
Lorsque que sur un site web One Page tu a toutes les plaquettes, les rendus 3D d'un bâtiment et que tu peux en plus naviguer dans le bâtiment et autour du batiment dans une vue web GL en 3D temps réel , ca me parait évident que c'est une grosse plus value.

Pourquoi perdrais t'on en performance et en ergonomie ? les browsers évoluent tous les jours avec leur spécifications, leurs performances. Pourquoi seulement limiter les navigateurs aux liens hypertextes et à la 2D ?

[jean_kevin_musclor]

C'est un bon exemple d'utilisation du webgl.

Quand à la question des performances c'est les développeurs qui en sont responsables, il faut déterrer les vieilles techniques d'optimisation et être copain avec le taskmgr.
Revenir à de la 3d simple je vais pas m'en plaindre, ça fait moins de boulot...

[p3ga5e]

C'est un bon exemple d'utilisation du webgl.

Quand à la question des performances c'est les développeurs qui en sont responsables, il faut déterrer les vieilles techniques d'optimisation et être copain avec le taskmgr.
Revenir à de la 3d simple je vais pas m'en plaindre, ça fait moins de boulot...

Heu c’est quoi la 3D simple ? Revenir plus de 20 ans en arrière et coder un moteur de raycasting avec le context 2D ?
En plus d’être moche, je ne suis même pas sure que cela soit performant, les vielle techniques de rendu ne sont pas forcément adapté aux technos et hardware actuel !

Alors qu’en est- il des vielles techniques d’optime C/C++, A l’époque ou je travaillé sur console PS1, GameCube et Dreamcast, je me souviens que :

• L’on désactivé le RunTimeTypeInfo RTTI du compilateur ;
• L’on désactivé la gestion d’exception du compilateur ;
• L’on allouer de la mémoire uniquement sur la pile ;

Arf 3 axes d’optims impossible en javascript!

Un développeur C/C++, ne connaissant pas trop javascript utilisera un Array en pensant que les données seront plus rapides en random access, c’est une erreur car l’objet Array a pour protoype le type Object et que c’est ce dernier qui dispose d’une méthode en random access, vertex[i] sera plus lent si vertex est une instance de Array plutôt qu’une instance d’Object .

De manière plus général la POO en JavaScript sera plus couteuse qu’en C++, Les développeurs C++ optimise leurs codes en utilisant judicieusement la directive inline cela leurs permet, au niveau code, d’utiliser la spécialisation et le polymorphisme sans que cela impacte les perfs au runtime ! Là encore c’est un axe d’optim impossible en javascript.

On pourrait croire que les techniques d’optims au niveau code, du genre frustum culling, soit tous aussi vallable en C/C++ qu’en Javascript ! et ben pas forcement ! tester si un OBB , un AABB ou même une BS se trouve dans le champs de la camera peut être plus couteux que de simplement lancer la rastérisation de l’objet sans se soucier de savoir si il est dans le champ !
Pourquoi cela ? Car tous ces vielles bidouilles d’optims ont un impact insignifiant face à la puissance de la parallélisassions des calculs, qu’apporte WebGL !

Vive les instructions SIMD ! Vive le GPU !

[xavierbourry]

WebGL est la spécification d'une bibliothèque graphique 3D au même niveau que OpenGL ou Direct3D. Celle-ci repose sur OpenGL ES 2.0 (la spécification pour l'embarqué de OpenGL) et permet de créer des pages Internet intégrant du contenu 3D. Ainsi, à l'aide de HTML 5 et du Javascript vous pouvez afficher un rendu accéléré par la carte graphique et bénéficiant donc de la puissance du GPU.

WebGL n'est pas une bibliothèque graphique 3D. La bibliothèque 3D utilisée par WebGL est OpenGL ES2.0, et parfois les appels vers cette bibliothèques sont transcrits en DirectX via Angle, notamment sous Windows. WebGL est un binding, soit une liaison entre Javascript et OpenGL ES2. Il permet simplement d'utiliser OpenGL ES via javascript.

WebGL permet d'aller bien plus loin qu'afficher du contenu 3D sur des pages internet. En effet depuis le VRML de l'eau a coulé sous les ponts. WebGL permet de créer des applications interactives 3D dans le navigateur : des jeux, des configurateurs 3D, des interfaces de navigation, de la réalité augmentée, ...

A l'aide d'HTML5 et de javascript il est effectivement possible d'afficher du rendu accéléré par la carte graphique : sur un navigateur moderne tout est accéléré par le GPU. Mais WebGL ne fait pas partie du standard HTML5. HTML5 est un standard normalisé par le W3C, consortium industriel spécialisé dans le web, tandis que WebGL est spécifié par le Khronos Group, consortium industriel spécialisé dans l'accélération matérielle, et pas moins légitime que le précédent (même si son nom est moins hype et fait moins branché que le World Wide Web Consortium).



Le support

Actuellement, les principaux navigateurs présents sur le marché disposent du support de WebGL :

Firefox (6 juillet 2010)
Google Chrome(3 février 2011)
Safari (20 juillet 2011)
Opera (14 juin 2012)
Internet Explorer (17 octobre 2013).
les versions mobiles de Firefox, Opera et du navigateur de Blackberry supportent également WebGL.

L'information est plutôt approximative. Pour des statistiques détaillées des support il vaut mieux se fier à caniuse.com/webgl. Il est nécessaire de préciser que bien que Safari ai implémenté WebGL précocement, il a fallu attendre la version 8 du navigateur pour que WebGL soit activé par défaut (sortie après IE11 dont l'activation est par défaut). WebGL sera également compatible avec la version 8 d'iOS Safari, et il l'est déjà avec les dernières moutures d'IE mobile.



La sécurité

On notera aussi le possible second frein lorsque des failles de sécurité critiques ont été découvertes dans le standard même, entraînant notamment la vive réaction de la communauté et de Microsoft.

Lors des débuts de WebGL, Microsoft tentait d'imposer sa technologie propriétaire, Silverlight, d'où sa réticence face à WebGL. Depuis Internet Explorer a rapidement comblé son retard, implémenté WebGL depuis la version 11 et Microsoft soutient également le développement du moteur BabylonJS. Deux failles de sécurité ont été découvertes dans la foulée de la sortie de Firefox 4 avec WebGL activé par défaut, et ont été très rapidement corrigées. L'une permettait de récupérer des images normalement accessibles via un login (on peut voler des photos de Facebook waouuh !), et l'autre permettait de récupérer des contenus des tampons vidéos, pour certains GPU avec des pilotes non sécurisés.

Actuellement, WebGL est désactivé (du moins avec Chrome) si les pilotes GPU ne présentent pas les impératifs de sécurité nécessaires (même s'ils seraient en mesure de faire tourner WebGL). Les seuls failles restantes permettent de faire planter certains navigateurs, comme on pourrait le faire en javascript/action script en jouant sur les boucles infinies et la saturation mémoire.



Le mouton noir du Khronos Group ?

Il ne faut pas non plus oublier que l'accélération graphique dans WebGL est disponible uniquement que si la carte graphique implémente correctement la spécification. Cela a aussi provoqué une certaine lenteur dans l'évolution du support d'OpenGL, notamment sous Linux où il était peu présent. Maintenant, nous pouvons dire que ces soucis sont globalement résolus.

Nous ne l'oublions pas. Les fabricants de cartes graphiques sont présents dans le Khronos Group (ATI, NVIDIA, AMD). WebGL nécessite pour eux de produire des drivers présentant des meilleurs impératifs de sécurité. Il s'agit d'un progrès. Depuis 2 ans n'importe que ordinateur, même le plus bas de gamme, est compatible WebGL sans avoir à réaliser de quelconque manipulation (changement de pilote, de paramètres du navigateur).

C'est totalement gratuit d'affirmer que WebGL a ralenti l'évolution d'OpenGL. OpenGL continue d'avancer, indépendamment de WebGL. OpenGL ES également. WebGL est basé sur OpenGL ES2, et OpenGL ES 3 est sorti. OpenGL est à la pointe, approximativement OpenGL ES suit OpenGL avec une dizaine d'années de retard, et WebGL suit OpenGL ES avec 2 ans de retard.

Sous Linux les problèmes proviennent souvent des fabricants de cartes graphiques qui livrent des pilotes peu aboutis pour ce système d'exploitation. Avec Nvidia il n'y a pas de problème, mais avec ATI l'installation des pilotes est parfois plus difficile.



WebGL a un avenir radieux !

Après un paragraphe louant le WebGL, l'auteur émets quelques objections :

WebGL a toutefois quelques limitations :

absence de tampon de sélection ;
absence de textures 3D ;
absence de geometry shader.

Ces trois fonctionnalités ne sont pas présentes dans OpenGL ES2.0 . Il est donc impossible qu'elles soient présentes dans WebGL. Le tampon de sélection peut tout de même être émulé pour faire du picking cheap.


L'auteur semble s'être abondamment inspiré de l'article Wikipédia sur WebGL. Les défauts reprochés sont les mêmes, et les petites imprécisions quant à sa compatibilité aussi.

Finalement, il n'y a toujours pas d'application phare pour cette technologie. De plus, pour les jeux vidéo et les applications intensives le JavaScript et la surcouche apportée par le navigateur peut être aussi un facteur décisif et ainsi empêcher l'adoption de ce standard.

WebGL commence tout juste à avoir un taux de compatibilité sur desktop permettant d'envisager des applications commerciales (66% d'après http://caniuse.com/#feat=webgl ). Peu de développeurs sont actuellement formés à cette technologie, et les projets importants nécessitent encore du temps. Les décideurs sont souvent peu au courant de ce que permet cette technologie.

Les jeux vidéos et les applications intensives resteront évidemment natives. COD ou Solidworks ne passeront jamais dans le navigateur. Les joueurs et les ingénieurs CAO ont des machines puissantes, sont prêts à acheter les licences, à télécharger le produit. Ils recherchent la performance avant tout.

WebGL est uniquement un binding, et ne joue pas sur le même tableau que Unity qui propose un workflow de création 3D remarquable, et depuis peu il est possible d'exporter des applications Unity en WebGL. WebGL ne sera pas non plus aussi optimisé et contiendra moins de fonctionnalités que des technologies propriétaires et tournant sur un nombre limité de plateformes comme Metal.

Le Khronos Group est notamment constitué de développeurs de navigateurs : Google, la Fondation Mozilla, Opera, ..., de concepteur de système d'exploitation: Apple, Canonical, ... de fabricants de matériel : AMD, Nvidia, ... et d'Universités parmi les plus reconnues. C'est compliqué et cela prend du temps de mettre tout le monde d'accord sur un standard. Et même si au final ce dernier à des défauts, sa portabilité est imbattable.



WebGL sera intéressant, voire incontournable pour :

• le casual gaming,
• les configurateurs produit,
• les interfaces de navigation 3D (avec la prise en compte des NUI notamment),
• de nouvelles expériences Web (ex : http://www.chromeexperiments.com/det...ti-general/?f= ),
• la recherche en algo 3D et les simulations (WebGL permet de partager le code très simplement, sans nécessiter d'OS/de librairie particuler ),
• des applications dont on n'a pas encore l'idée !

En bref, c'est un grand OUI, WebGL a un avenir !

[Invité]

Personnellement, je n'ai jamais (de ce que je m'en souviens) ou presque croisé d'application utilisant cette technologie et comme dit plus haut, je ne vois pas trop l'intérêt d'intégrer des applications 3D dans le navigateur ...
Pour moi, un navigateur est un outil qui permet de naviguer sur internet via des forums, des sites webs, mais n'est nullement une plateforme de jeu, et encore moins pour des jeux en 3D dont je trouve le rendu bien moins bon que dans un programme fonctionnant directement sur le PC de l'utilisateur.

D'un autre côté, je suis contre les plugins qui peuvent créer des problèmes de sécurité d'autant que flash, par exemple, n'est plus mis à jours ...

[jean_kevin_musclor]

l'usage majoritaire que font les internautes du html5 c'est youtube. les bricolages de jeux foireux genre farmville c'est marginal

html5 ou flash plugin ça n'est pas conçu pour les jeux vidéo, c'est même pas pensable, les fabricants de navigateurs ou adobe ils ont pas les budgets de chez ubisoft (pour rappel les budgets des jeux pros ça dépasse ceux des blockbusters hollywoodiens, c'est pas des trucs que l'internet peut s'offrir). Ca sert juste à égayer le web avec un peu de multimédia, un peu d'animation, de son, de vidéo, (et éventuellement oui des jeux pourris avec du gameplay d'atari 2600) sinon internet serait aussi chiant qu'une feuille d'impôts. ils appellent ça une "valeur ajoutée" qui permet de retenir plus longtemps l'attention d'un internaute afin d'augmenter le trafic.

si vous voulez absolument faire des jeux vidéo javascript il n'y a que de la 2d simple qui donnera des perf correctes

sinon la 3d sur internet c'est surtout utilisé pour:
- la cartographie (google maps, greenpeace)
- les vr et autres visites virtuelles pour office du tourisme (musées, monuments...)
- le marketing (maquettes de produits ou d'appartements, bannières de pub interactives)
- juste pour faire joli (menus 3d et autres gadgets)

ça n'a jamais décollé à l'époque des plugins car c'était un bazar ingérable (fallait maîtriser virtools, applet jogl, svg, shockwahe, unity, flash, etc.. chaque boite utilisait un différent). Avec le webgl on a réglé ce problème là, au détriment de la performance par manque de moyens, reste à savoir si ça va s'améliorer ou finir laissé en plan pour coupe de budget.

[imikado]

Avec des bibliothèque comme Bablylon.js, webgl a un brillant avenir
https://github.com/BabylonJS/Babylon.js/wiki/Tutorials

[jean_kevin_musclor]

Beuark que ça rame leurs démos... webgl c'est pas fait pour faire des grosses librairies compliquées comme ça... c'est pas ce genre de démos kill-cpu qui vont faire une bonne publicité au webgl.

Le problème du webgl c'est pas de pondre du code, javascript est peut-être bien le langage le plus facile du monde, et webgl la librairie bas niveau la plus obvious, ça n'a strictement rien à voir avec l'opengl. C'est suffisemment facile pour que tu puisses tout programmer toi-même sans marcher avec des béquilles.

Le problème du webgl c'est d'optimiser ta pipeline et de faire un programme le plus simple possible, parce que c'est très lent, c'est pour ça qu'il vaut mieux tout coder soi-même.

[p3ga5e]

Pourquoi vouloir remettre en cause l’avenir d’une norme d’API graphique tel que le GL !

Tout le monde sait, de nos jours, que programmer en respectant cette norme augmente considérablement la facilité de portage de son code,
WebGL apporte une nouvel plateforme a la longue liste des plateformes compatible GL : smartphones, tablettes, consoles, ordinateur personnel (mac et PC ).

Pour ceux qui se posent la question de l’intérêt de GL dans un navigateur, il faut tout d’abord arrêter de penser que GL se limite à la 3D projeté !
Ou dans la norme GL il est indiqué qu’un sommet doit obligatoirement contenir une position 3D dans un espace cartésien orthonormé ? et pourquoi la projection devrait-elle être systématiquement de type perspective ?
Pourtant rien n’empêche d’écrire un shader pour le pipeline géométrique effectuant une projection cartographique de type Mercator sur des coordonnées sphérique (position GPS).
Sachant que les donnée vectorielle sont nettement moins lourdes que les données raster et qu’en prime elle offre un meilleur rendu ( pas de pixellisation). La rastérisation de carte vectorielle en temps réel dans un navigateur est-elle vraiment inutile ? Même pour Google ?

En "bypassant" le pipeline géométrique, on peut utiliser le pixel shader pour paralléliser le traitement de signal en générale !
Pour ma part je vais utiliser WebGL pour traiter et afficher des signaux RADAR maritime par-dessus une cartographie vectorielle rendu grâce à WebGL !
Sur ShaderToy , les génies traitent, au minimum, de deux autres types de signaux :

• Les images de synthèse par des raytraceur /raymarcheur temps réel comme celui-ci
• Des sons/musiques avec des effets (cf ce sound shader de bargot)

Disposer d’univers et de musique de synthèse de manière procédurale sans aucune ressource a téléchargé (a part le code des shaders) est-elle inutile ?
Même si le débit et la bande passante, pour internet, augmentent continuellement …

La direction, de la boite pour laquelle je bosse, m’a finalement autorisé à utiliser WebGL pour remplacer notre vielle techno Flash. Ayant misé sur cette techno je vous invite tous à l’utiliser, sans modération, pour qu’elle ne disparaisse pas ! il n’y a pas que le jeu video comme domaine d’application, par exemples calculer moi la fin du monde grâce aux vertex shader, mais surtout sortez-vous les doigts du cul,gardé l'esprit ouvert et utiliser cette magnifique techno !

[jean_kevin_musclor]

t'es sûr que ça va pas donner un truc super lent comme sur tes démos qui rament abominablement ? le webgl c'est juste bon pour la 3d des années 90 ça supporte pas vos trucs de jeunes high-tech
parce que si on continue à pourrir le web de démos kill-cpu, les gens font finir par désactiver le javascript
je rappelle qu'il y'a beaucoup de processeurs qui ne supportent pas les surchauffes, et que l'autonomie des batteries est courte, et que saturer cpu et ram ça fait planter les navigateurs et freezer les machines et c'est particulièrement désagréable... le multimédia sur le web sert à rendre un site attractif, pas à faire fuir le public.

si tu veux faire du shader gpu performant tu ferais bien mieux de rester sur flash, et si t'es allergique à leur compileur de shader en assembleur, essaye unity plugin...

exceptionnellement je vais dire du bien de unity pour son export plugin, si vous voulez de la 3d moderne performante dans les navigateurs, pour l'instant y'a rien d'autre.

[scandinave]

t'es sûr que ça va pas donner un truc super lent comme sur tes démos qui rament abominablement ?parce que si on continue à pourrir le web de démos kill-cpu, les gens font finir par désactiver le javascript


si tu veux faire du shader gpu performant tu ferais bien mieux de rester sur flash, et si t'es allergique à leur compileur de shader en assembleur, essaye unity...

On a compris que tu n'aime pas webgl mais l'a tu réellement utilisé avant de cracher dessus? va sur threejs.org et dis moi que tu ram. Si c'est le cas c'est qu'il est grand temps de changer de pc. je l'ai testé au bureau sur des machines avec des pentium double coeur et une hd4000 en carte graphique. Ça tournais nickel.

Bref sinon dernièrement webgl m'a bien sauver la mise. Je devais faire une application de retouche photo. canvas étais bien trop lent pour appliquer des filtres. Grâce a webgl, l'application de plusieurs filtres en simultanés ne pause aucun problème. Alors oui je pense que webgl à un gros avenir. Libre a toi de t'en passer mais tu loupera certainement un wagon si tu compte faire de la 3d