Archives par étiquette : déplacements 3D

Moteur physique sur GPU basé sur le Cubemapping

Laisser un commentaire

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.

La perception 3D : 2 systèmes de navigation antagonistes

Laisser un commentaire

Il n’y a pas qu’une seule façon de se déplacer dans un univers en 3D tout à la souris, ou avec n’importe quel dispositif de pointage. En effet, il y a deux catégories d’utilisateurs. Selon nos tests, Chaque catégorie représente au minimum 25% des utilisateurs et ne peut donc pas être négligée.

Les joueurs :
Pour les joueurs, il semble plus naturel de partir du curseur en position centrale, et d’aller à droite pour tourner à droite par exemple. Celà correspond au mode de déplacement rencontré dans la plupart des jeux vidéos :
Dans ce mode de déplacement, l’utilisateur prend la caméra comme la référence, et les mouvements angulaires de la caméra sont proportionnels au déplacement du curseur.

Capture d’écran d’un jeu vidéo 3D, Unreal Tournament 436 :
Ce système de navigation est également le plus employé dans les visionneuses d’images immersives, ou les visites virtuelles. Il est utilisé notamment dans Google Street View.

Les utilisateurs de smartphones et de tablettes :

Pour cette catégorie d’utilisateurs, il est plus naturel d’aller positionner le curseur sur le côté de l’écran vers lequel ils veulent déplacer la vue, et de ramener le curseur vers le centre. Par exemple pour aller vers la droite, il faut amener le curseur vers la droite, puis le ramener au centre en maintenant le clic enfoncé :
Celà correspond au système de navigation adopté dans les tablettes et les smartphones. L’utilisateur se positionne par rapport aux objets environnant, et les pousse pour se déplacer :

Ce système de navigation revient à faire effectuer a la caméra une rotation d’angle inversement proportionnel au déplacement de la souris. Les utilisateurs familiarisés avec ce mode de déplacement vont penser que le premier mode est inversé, et vice-versa…

Ce système de navigation est adopté notamment dans les murs de photos 3D de Cooliris.

Et les novices…
Les utilisateurs qui ne sont ni joueurs, ni utilisateurs de périphériques à écran tactile se placent naturellement dans l’une ou l’autre des catégories. Cependant il est plus facile pour eux de changer leurs habitudes que pour des joueurs assidus ou des accros de l’Ipad.

Dans les univers 3D ayant peu d’objets proches, ou peu de grandes surfaces planes, typiquement les visionneuses d’images immersives (que l’on peut assimiler à des univers 3D où l’utilisateur est au centre d’une sphère texturée), le premier système de navigation l’emporte. Mais dans le cas d’univers comportant de larges surfaces planes, comme ceux créés par Spacegoo CMS ou Spacegoo PDF, la situation est plus ambigüe.

Actuellement le système de navigation choisi par SPACEGOO est celui des joueurs. Nous allons bientôt prendre en charge les deux systèmes de navigation.