Archives par étiquette : demo webgl

Effet d’eau pour webglparis.com

Un effet de simulation d’eau fait office d’arrière plan sur le site internet de WebGL Paris, http://www.webglparis.com . Pour réaliser cet effet nous simulons les équations de Saint Venant (Shallow Water Equations) en GPGPU dans le shader de fragments en utilisant une texture flottante de 512X512 pixels.

La simulation est réalisée 4 fois par image rendue, soit à un rythme de 4*60=240 pas par seconde pour un affichage à 60Hz.

Après le chargement de la page, les positions et les tailles de différents éléments de la page (ayant la classe CSS .obstacle) sont récupérées en javascript avec l’aide de JQuery. Un canvas2D est alors dessiné pour faire office de heightmap.

Une normal map est calculée côté GPU, après avoir préalablement appliqué un flou gaussien sur la heightmap.

Le rendu final est assez léger, peu perturbant pour l’oeil, et il répartit la teinte d’une façon intéressante sur la page. Seul bémol : pour les configuration n’ayant pas l’extension WebGL OES_TEXTURE_FLOAT, les vagues sont légèrement trop marquées.

Une vidéo de l’effet :

WebGL tiny background water effect
Runtime
0:37
Compteur de vues
353

 

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.

frontoffice 3D pour wordpress

Nous avons créé une interface 3D pour un site vitrine ou un blog wordpress.

Les images d’arrière-plan, le contenu texte, le titre… sont tous facilement modifiables en passant par le backoffice wordpress. Les modèles sont également changeables.

Nous nous sommes basés sur Three.js, et nous avons également utilisé JQUERY et JQUERY-UI.

La démonstration est visible ici : Interface 3D pour wordpress