Archives de l’auteur : Xavier

WebGL 1K demo

fnacap6

WebGL est réputé pour être lourd à mettre en oeuvre. Effectivement développer un simple cube tournant coloré nécessite beaucoup de lignes de code.

Mais pour jouer avec les mathématiques et calculer la couleur des pixels parallèlement, dans le but de créer des visualisations sympathiques, webGL peut s’avérer imbattable.

Pour preuve, une démo WebGL de 1024 caractères, soit 1KO :

<body style=’margin:0onload= »m=’;varying float x,y;void main(void){‘,w=window,c=document.getElementById(‘c’);k=c.getContext(‘webgl’);r=k.createBuffer;y=c.width=w.innerWidth,z=c.height=w.innerHeight;f=k.createProgram(),x=function(o,l){n=k.createShader(l);k.shaderSource(n,o);k.compileShader(n);k.attachShader(f,n);return n};x(‘attribute vec2 p’+m+’x=p.x;y=p.y;gl_Position=vec4(p,0.,1.);}’,35633),x(‘precision lowp float;uniform float t’+m+’gl_FragColor=vec4(mod(floor(t-x*pow(x*x+y*y,-1.5))+floor(t-y*pow(x*x+y*y,-1.5)),2.)+vec3(0.,.4,.8), 1.);}’,35632);k.linkProgram(f);j=k.getUniformLocation(f,’t’);b=k.getAttribLocation(f,’p’),k.enableVertexAttribArray(b);k.useProgram(f);q=function(n,p){v=k.createBuffer();k.bindBuffer(p,v);k.bufferData(p,n,35044)};q(new Float32Array([-1,-1,1,-1,1,1,-1,1]),34962);q(new Uint16Array([0,3,1,2]),34963);k.viewport(0,0,y,z);d=function(l){k.clear(16384);k.uniform1f(j,l*.001);k.vertexAttribPointer(b,2,5126,0,8,0);k.drawElements(5,4,5123,0);w.requestAnimationFrame(d)};d()« ><canvas id=’c‘/>

Je me suis permis le luxe de placer des balises HTML, et de les compter dans le total. Je n’utilise pas les balises <!DOCTYPE html>, <html>, je ne précise pas l’encodage des caractères et je ne ferme pas les balises <body>, <html>. Je n’utilise pas de var pour déclarer les variables et j’oublie volontairement GL.flush() à la fin de la boucle de rendu. La déclaration du code dans la propriété onload de la balise body n’est pas chaleureusement conseillée par le W3C. Mais les navigateurs modernes sont très tolérants,  alors il faut en profiter !

La démo est entièrement codée en caractères texte normaux. En effet, je considère qu’utiliser des jeux de caractères étendus/compresser tout le code de façon plus qu’incompréhensible n’est pas fair play.

La démo est accessible à partir du site de Webgl Academy : Démo Webgl 1K

 

WebGL : Guide de développement d’applications web 3D premier au classement 2D/3D/jeux

Le livre WebGL : Guide de développement d’applications web 3D a été promu premier au classement des livres dans la catégorie 2D – 3D – jeux sur developpez.com.

Le site developpez.com rassemble la communauté francophone des développeurs, professionnels et amateurs. Leurs news sont incontournables pour qui veut effectuer une veille technologique dans le domaine de l’informatique.

Je tiens à remercier tous les lecteurs, et particulièrement ceux qui m’ont envoyé des retours sur expérience, et des liens vers leurs projets !

Lifting pour Spacegoo.com

Spacegoo.com reste la principale source de clientèle de Spacegoo. En effet, le site internet est plutôt bien positionné pour les requêtes de recherche concernant le WebGL. Ce positionnement s’explique principalement d’une part par l’ancienneté de Spacegoo.com, positionné sur le WebGL depuis sa création début 2011, et d’autre part par un bon pagerank et beaucoup de liens retour grâce à nos démonstrations.

En ce qui concerne les autres leviers de l’optimisation SEO, nous n’avons pas eu besoin d’y faire recours. L’interface actuelle de Spacegoo est peu compréhensible par les bots des moteurs de recherche, et il n’y a pas de version de fallback au cas où le visiteur n’est pas compatible WebGL. Déjà que les bots des moteurs de recherche ont du mal avec Javascript, alors leur demander de comprendre le WebGL…

Et quant aux campagnes de publicité, google adwords, efforts commerciaux divers, nous n’y avons pas recours. Nous sommes pour l’instant dans le B2B. Nos clients veulent des applications de qualité, mixant WebGL avec d’autres technologies web de pointe (WebRTC, WebAudio, …), et ils ont déjà fait leur choix technologique.

Bien que le design ne soit pas notre métier (notre métier est la programmation), nous avons effectué un petit lifting pour Spacegoo.com. La comparaison en images :

ancienne version :

Simulation de tissus

Nous avons réalisé une démo de simulation de tissu sur GPU. Elle est disponible ici : simulation de tissu webgl . Elle représente un carré de tissu, modélisé par un réseau de masses liées les unes aux autres par des ressorts/amortisseurs. Le réseau comporte 62500 points, et tous les calculs des champs du réseau (vitesses, position) sont effectués en parallèle, côté GPU dans le shader de fragments. En plus des forces exercées par les ressorts, chaque point est soumis à la gravité et à une force de frottement, dont la composante normale est séparée et plus élevée que la composante tangentielle.

Des collisions entre le tissu et des cylindres sont calculées, avec un coefficient de frottement statique et dynamique.

Cette simulation utilise différentes extensions webgl : les texture flottantes (OES_texture_float – qui permet de stocker des données dans des textures sur 16 bits au lieu de 8), l’indexage des tableau d’éléments sur 32 bits, qui permet d’avoir plus de 2^16 points dans un unique maillage (OES_element_index_uint), le filtrage de texture anisotropique pour un meilleur rendu lorsque le tissu est affiché en biais (EXT_texture_filter_anisotropic), et enfin la possibilité d’avoir plusieurs buffers de rendu dans un même framebuffer (WEBGL_draw_buffers).

La dernière extension, WEBGL_draw_buffers, est encore très expérimentale. Elle permet de lier un framebuffer à plusieurs buffers de rendu, eux-même liés à des textures. Ensuite il est possible de dessiner dans le i-ème buffer de rendu dans le shader de fragments en remplaçant la variable de sortie gl_FragColor par gl_FragData[i].

Il serait possible de se passer de cette dernière extension moyennant quelques passes supplémentaires dans le rendu, et plus de lignes de code.

Pour exécuter la démo,

– utilisez Chrome 29 ou supérieur. Pour afficher votre version de Chrome, cliquez sur l’icône en haut à droite, puis sur « A propos de Google Chrome » :

A l’heure ou j’écris ces lignes, cette version de Chrome est encore en version béta.

– Activez les extensions expérimentales de WebGL. Pour celà tapez dans la barre d’URL : chrome://flags . Puis cliquez sur « activer les extensions  WebGL brouillon » :

– Fermez Chrome. Si vous utilisez Linux, relancez Chrome et testez la démo. Si vous utilisez Windows, il sera nécessaire de désactiver ANGLE sous Chrome. ANGLE est une implémentation d’OpenGL ES2 redirigeant tous les appels de WebGL vers DirectX. Pour désactiver Angle sous Chrome, cliquez du bouton droit sur votre lien vers Chrome, puis ajoutez –use-gl=desktop à la fin de la cible :

Enfin, lancez Chrome à partir du lien ainsi modifié et testez la démo 🙂 .

Moteur physique sur GPU basé sur le Cubemapping

Habituellement les moteurs physique WebGL ( ce qui empêche le joueur de passer à travers le décor ) tournent sur le CPU (Central Processing Unit) et non sur le GPU (Graphic Processing Unit).

Dans les applications compilées, la physique peut être calculée sur GPU, soit en utilisant des shaders comme le geometry shader auxquels on n’a pas accès en WebGL, soit en utilisant des fonctionnalités matérielles spécifiques, comme PhysX pour les carte graphiques Nvidia. Mais pour les applications WebGL, la physique est ramenée à des collisions sphère/octree calculées sur CPU.

L’octree (arbre contenant toutes les faces de la scène) est soit pré-calculé et inclus dans les données, soit calculé lors du chargement de la scène. Dans tous les cas, il alourdit le chargement. Quant au moteur physique en Javascript, il requiert beaucoup de calculs de collisions pour chaque image générée.

Je détaille le fonctionnement d’un tel moteur physique dans mon ouvrage WebGL : Guide de programmation d’applications web 3D.

Je présente ici une façon très différentes de calculer la physique. Elle ne nécessite ni de calcul d’octree, ni de calcul d’intersections sur CPU via des méthodes dérivées de l’utilisation des coordonnées de Plücker et du théorême de l’axe séparateur. Presque tout est effectué sur le GPU.

Capture d’écran de la démonstration :

Capture d'écran de la démonstration du moteur physique basé sur le cubemapping

Capture d’écran de la démonstration disponible sur http://spacegoo.com/publis/cubemapPhysics/implementation

Cliquez ici pour lire la publication détaillant le fonctionnement de l’algorithme (en anglais)

Cliquez ici pour jouer à la démonstration (utilisez les flèches du pavé directionnel du clavier pour vous déplacer, et la barre d’espace pour sauter),

Cliquez ici pour télécharger le code source de la démonstration

Cet algorithme est intéressant à implémenter pour des applications où la physique se résume à des collisions personnage/décor. S’il y a de nombreuses interactions physiques à calculer (interactions objet-objet notamment), il vaudra mieux passer par des algorithmes plus classiques basés sur l’utilisation d’octree.