Discussion :

[lightbulb]

Bonjour à tous,
Je travaille actuellement sur un moteur en webGL permettant de gérer un jeu de type FPS.
Je cherche une technique me permettant de réaliser un impact de balle sur un modèle lorsqu'on lui tire dessus par exemple.

Pour un objet solide sujet aux tile map (comme un mur) il suffit de récupérer le point d'impact et de superposer un polygone avec une alpha et ça marche très bien ! Mais lorsqu'il s'agit d'un modèle animé qui est sujet aux déformations placer un polygone au point d'impact est une solution difficilement maintenable.

J'ai donc pensé a une solution que je vous ai résumé sur l'image ci-dessous :



1 - On récupère le point d'impact.
2 - On transpose ce point d'impact en coordonnées UV.
3 - On crée une texture full alpha
4 - On merge l'impact de balle sur la texture centré sur la coordonnée UV.
5 - Lors du rendu => multi-texturing pour obtenir l'impact.

Je trouve le principe simple mais je butte sur les étapes 3 et 4. Comment faire pour créer un texture alpha et comment faire pour lui merger une image par dessus aux bonnes coordonnées UV?

Si jamais vous avez des infos n'hésitez pas !

Merci

[p3ga5e]

Pour les étapes 3 et 4 tu peux créer et manipuler facilement une image en utilisant le context 2D d’un canvas , qui peut être envoyé en VRAM tel quel via la signature WebGL de texImage2D :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void texImage2D(GLenum target, GLint level, GLenum internalformat, GLenum format, GLenum type, HTMLCanvasElement canvas)

Toutefois ta solution, semble très très coûteuse. A mon avis tous doit pouvoir se faire sur le pipeline de rendu, comme par exemple définir la trajectoire de ton tire par un uniform sous la forme d’une équation de droite et faire tes 5 étape sur le GPU, probablement dans ton pixel shader.

Cette discussion mériterait d’être déplacée dans le forum 2D-3D, afin de bénéficier de plus de retour …

[lightbulb]

Je ne savais pas réellement ou placer ce sujet, comme j'utilise le webGL je l'ai mise ici.

En réalité récupérer la position de l'impact est déjà faite par tracé de rayon et détermination du point d'impact plan/rayon. c'est une opération mathématique légère. (cf. théorème de graam-shmidt + barycentre) Je m'en sert déjà pour le picking et la contrainte au sol.

Après benchmark déterminer les collisions sur 950faces avec cet algo prend moins d'une milliseconde sur un portable datant de 5ans et ce en javascript en respectant toutes les contraintes d'optimisation du V8 de chrome.

Pour le multi-texturing, c'est réalisé au niveau du fragment shader effectivement car le moteur gère déjà les specular map, normal map et transparency map. La technique ne pose aucun problème.

Le véritable problème est réellement de blender plusieurs textures pour former une texture finale qui sera multi-texturé sur la diffuse pour donner l'effet d'impact souhaité...

Ca se rapproche du texture painting je pense, j'ai trouvé une démo qui se rapproche ou on peut peindre de la couleur sur une texture :
http://www.spacegoo.com/tiananmen/

Bien sur le petit malin a mignifié et obfusqué son code rendant l’interprétation impossible mais le principe est la sauf que dans mon cas j'utiliserai des textures pour peindre...

[p3ga5e]

Pour le multi-texturing, c'est réalisé au niveau du fragment shader effectivement car le moteur gère déjà les specular map, normal map et transparency map. La technique ne pose aucun problème.

Toutes ces techniques de multi-texturing c’est toi qui les as écrites ? ou bien tu utilise un moteur 3D déjà tous fait ?

Le véritable problème est réellement de blender plusieurs textures pour former une texture finale qui sera multi-texturé sur la diffuse

Ben n’y a rien de plus simple : fonction mix

[lightbulb]

J'écris mon propre moteur 3D webGL à partir de 0 en respectant au maximum les bonnes pratiques d'optimisation du moteur d'interprétation javascript V8 entre autre.

Par contre pour l'architecture je me suis inspiré de la librairie TDL de google et pour les maths la librairie de Brandon Jones et Colin MacKenzie IV : gl-matrix, pour les opérations matricielles et vectorielles de base.

Pour tout le reste je dors avec des bouquins de 3D et de mathématiques pour la 3D. Mais ça ne résout pas tout ! :p

La fonction mix permet d'interpoller linéairement, quand on regarde ce fragment shader tout simple tiré du lien que tu viens de me donner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
                float t = (cos(time)+1.0)/2.0;
		vec4 frontPixel= texture2D(image1, p);
		vec4 backPixel = texture2D(image2, p);
		gl_FragColor = mix(backPixel,frontPixel,t);

On interpole front et back en fonction du temps(t) ce qui donne ici un effet de fondu. En interne ca revient tout simplement à multiplier front et back en faisant varier les alphas de l'un et de l'autre, ça ne résout pas mon problème.

Je souhaite obtenir une nouvelle texture définitive comme quand on fait "aplatir les calques" sous photoshop dont je puisse me servir en multiplication sur la diffuse.

Je viens de penser à une solution avec ce que tu m'as donné mais je ne suis pas convaincu de son optimisation :

1 - Point d'impact => transformation vers UV coord
2 - Envoi de ces coordonnées, de l'image d'impact dans un shader dédié qui va sortir la texture dans un nouveau framebuffer.
3 - On utilise la texture en sortie du framebuffer en multi texture dans le shader principal.

Théoriquement c'est juste mais de manière pratique j'ai quelques réserves du point de vu optimisation.

Inconvénients :
Utiliser un useProgram en phase de rendu est ce que je cherche à éviter au maximum car ça demande de réupload toutes les informations du shader vers la carte graphique et c'est un ralentissement non négligeable. Si le joueur se fait mitrailler on va générer plusieurs dizaines d'impacts rapprochés si on souhaite afficher tous les impacts. Ouch !

Avantages :
Une fois la texture dans le shader principal aucun traitement supplémentaire n'est nécessaire.

Merci de m'avoir ouvert l'esprit sur ça mais si une solution plus courante et moins gourmande vous vient à l'esprit, n'hésitez pas à en parler !

[p3ga5e]

A mon avis:

• Le temps d’upload d’un program doit être très certainement inferieur à celle d’une texture
• L’upload du programme doit se faire lors des compileShader plutôt que dans useProgram.

Ensuite pourquoi vouloir a tous pris générer une texture ?

1. Envois le point d’impact dans un uniform de type vec3
2. projette le dans le vertex shader dans un varying vec2 ... bon ce point ne varie pas pour chaque sommet mais puisque ce calcule s’effectue sur GPU cela n’est pas grave
3. Dans ton pixel shader calcul les cordonnée UV a partir de ce point point d’impact projeté et les coordonnées du pixel en cours de rasterisation (gl_FragCoord.xy)

[lightbulb]

Faire un useProgram ne fait pas qu'uploader le shader il fait aussi de nombreux checks et switch les attribArrays, c'est sans contest une opération lourde et bien plus coûteuse que l'upload d'une image.

Par ailleurs le compileShader est une opération généralement réalisée à l'initialisation puisqu'elle transforme le code du shader en code compilé interprétable par la CG, en plus d'être une opération lente, il vaut mieux que ça plante dès le début qu'en plein milieu de l'apply. C'est la fonction useProgram qui upload le programme vers la CG.

Quand on a plusieurs vertex/fragment shader on est obligé d'utiliser un useProgram pour switcher donc je ne comprend pas du tout le sens de ta phrase :

L’upload du programme doit se faire lors des compileShader plutôt que dans useProgram.

Pour aller plus loin je ne comprend pas du tout comment tu crées un impact de type blessure sans créer une nouvelle texture ou en modifiant la diffuse originelle...

[p3ga5e]

Je peux me tromper, mais il me semble que l’on peut créer plusieurs shader et program en VRAM et utiliser un useProgram pour switcher entre eux sans que cela déclenche des transferts entre la RAM et la VRAM.
En tous cas j’ai jamais remarqué de baisse de perfs lors d’un switch entre diffèrent pipeline de rendu.

Tu devrais demander à un modérateur de déplacer ce sujet dans le forum OpenGL, pour obtenir l’avis de plus de personnes expérimentés.

Pour aller plus loin je ne comprend pas du tout comment tu crées un impact de type blessure sans créer une nouvelle texture ou en modifiant la diffuse originelle...

Je pensais a un truc très simple comme ceci, mais je n’arrive pas requeter correctement la texture d’impact, je ne vois pas où est l’erreur dans mon pixel shader

[lightbulb]

Ok je vois ce que tu veux dire mais en réalité ca rejoins ce que je dit depuis le début. Dans ton exemple tu as un shader spécialisé qui va mélanger les textures.

Voici la démarche théorique que je vais suivre :
Init : Pour chaque modèle défini comme impactable dynamiquement (humanoides), creation d'une texture supplémentaire vierge.

Lors d'un impact :
1- Récupération du point d'impact sur le modèle
2- Projection de cette position en coordonnées UV
3- Changement de programme pour utiliser le shader spécialisé
4- Appel du shader avec texture d'impact(sang) + texture vierge + UV impact
5- Blending des textures
6- Affectation de la texture en sortie du framebuffer à l'objet en cours.
7- Changement de programme vers le programme de rendu principal avec nouvelle texture générée.

Avantages : Appels ponctuels
Inconvénients :
1- Risque de ralentissement si la cible est mitraillée à cause d'un changement de programme à chaque impact (laps de temps court entre impact).
2- Si la texture d'impact est trop grosse, risque de débordement dans des zones non souhaitées. Exemple : Si le visage est proche de la jambe dans les UV, lors d'un tir à la jambe du sang peut déborder sur l'oeil. Faudra que je gère ça aussi.

Mais tu as raison ce post devrait être placé en catégorie 3D ou openGL car j'aimerai savoir dans le monde professionnel comment sont réellement gérés les impacts. Pour les objets statiques je suis sur que ce sont des "decals" (poly superposés, fonctionne comme un calque) mais pour un impact sur une surface dynamique (sujette aux déformations) aucune idée.

[p3ga5e]

YES j’ai résolu mon problème de requetage !
On peut changer la position de l’impact en cliquant sur l’image !

Ta méthode semble bien plus coûteuse que la mienne ! Non ? Que reproches-tu à ma méthode ?

Bon, vu que j’ennuis un peu à mon job, je vais tenter de la transposer en 3D sur le model Zombie

[lightbulb]

Je lui reproche juste que la tu c'est comme si tu cliquais sur un UV pour mettre la tache de sang à l'endroit du clic et c'est pas du tout mon cas.

Je rappel que c'est pour un moteur de jeu de type FPS donc tu imagines le joueur avec son arme qui se ballade dans la carte, il voit un ennemi et va tirer une balle qu'on peut représenter par un rayon d'ancre posCamera et de direction dirCamera.

Ce rayon va entrer en collision avec un objet que j'ai représenté en 1 par un personnage. Il percute le modèle, pas son UV, d'ou la nécessitée de transposer les coordonnées du point de collisions en coordonnées UV pour ensuite venir appliquer l'alpha.

Peut être que je me suis mal exprimé au début.

En tout cas merci de t’intéresser au problème c'est vraiment gentil !

[p3ga5e]

Peut être que je me suis mal exprimé au début.

Non non ! j’ai bien compris ce que tu souhaites obtenir.

Il percute le modèle, pas son UV, d'ou la nécessitée de transposer les coordonnées du point de collisions en coordonnées UV

C’est là ou nos 2 techniques divergent, je pense que l’on peut garder le point d’impact en coordonnée 3D et tous faire dans le Pixel Shader, sans passer par une génération de texture de taille égale à la diffuse map.
En te re-lisant j’ai l’impression que tu ne souhaites pas modifier le codes de tes shaders et que tu préfères tous faire sur le CPU, quoique tu souhaites mettre en place un pipeline dédié pour le rendu de tes textures d’impact

Je commence a rencontré quelque problème ! Tout d’abord, je viens de découvrir que mon extension Three.js me permettant d’utilisé un model animé au format MilkShape 3D, ne fonction pas avec le system de lancer de rayon de Three.js , la cause est que je garde que la géométrie de base ré-exprimé dans le repère locale a chaque os du squelette, le skinning étant directement fait par le vertex shader. Du coup je ne peux pas calculer le point d’impact, coté CPU, sans reconstruire la géométrie en fonction de son anim skinné , cela implique de reproduire le pipeline du vertex shader sur CPU, donc un surcoût énorme.

Comment animes-tu tes models ? Cela ne ta pas posé de problème pour le calcul du point d’impact ?

[lightbulb]

L'animation des modèles par bones est prévu pour le début de l'année prochaine, je travaille sur un projet long (~1an et demi) et j'ai pris un peu d'avance en demandant une technique pour récupérer le point d'impact histoire de savoir quoi faire le moment venu.

Etant libre de toute librairie plaçant une couche d'abstraction supplémentaire je peut implémenter les animations à ma façon pour favoriser la detection des collisions en ajoutant des boites transformées :
-AABB autour du perso
-Chaque bones est contenu dans une OOBB transformée en même temps que lui.

Collision rayon-perso :
-Rayon-AABB englobante
-> Si collision trouvée
-Rayon-OOBBs
->Si collision trouvée
-Rayon-faces skinnées sur le bone

Au lieu de tester 10 000 faces on ne test plus que des boites et les faces à l'intérieur de la dernière.

Et pour finir pour répondre à ta question, au lieu d'effectuer les transformations du perso sur le CPU pour détecter les collisions, ce qui reviendrai a effectuer l'action de la GPU sur le CPU, on transforme le rayon pour le replacer dans le repère des box. Et transformer un rayon c'est vraiment pas long, ancre*MVmatrix + direction*NMatrix !

J'ai déjà mis en oeuvre ce procédé pour une boite transformé lorsque j'ai créé le module de picking du moteur.

Les graphistes qui travaillent avec moi vont me passer les animations au format FBX. Je ne connais pas milkshape3D mais de toute façon il faut écrire un module de parse pour réécrire les animations au format JSON :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
"bones" : [{"parent":-1,"name":"origin","pos":[0,0,-0],"rotq":[0,0,0,1]},{"parent":0,"name":"Body","pos":[-2.13016,63.5822,-0],"rotq":[0,0,0,1]},{"parent":1,"name":"Hips","pos": ...
 
"skinIndices" : [24,30,25,24,24,25,25,24,24,25,24,25,25,24,24,25,36,37,24,22,24,22,24,0,24,25,36,37,24,25,36,24,24,33,24,30,30,24,30,24,24,0,24,0,24,33,24,33,24,33,24,22,24,0,24,30...
 
"skinWeights" : [0.550559,0.274047,0.468559,0.468559,0.719755,0.170999,0.5,0.5,0.77806,0.22194,0.948287,0.0517131,0.5,0.5,0.506803,0.493197,0.513286,0.428218,0.758592,0.16307,0.534855,...
 
"animation" : {"name":"idle","fps":24,"length":7.25,"hierarchy":[{"parent":-1,"keys":[{"time":0,"pos":[0,0,-0],"rot":[5.40774e-10,-0.0066385,8.14586e-08,0.999978],"scl":[1,1,1]},{"time":0.0416667, ...

[p3ga5e]

Ah oui !

Ramener le rayon dans les repères locaux de chaque objet est bien moins coûteux que de ramener chacun des sommets dans le repère global ! je m’en veux de ne pas y avoir penser …

La dernière version du lancer de rayon de Three.js fonctionne de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Rayon repère global sur BoundingSphere repère global
Si collision :
->Pour chaque Triangles :
->Rayon repère local sur plan du triangle 
->Si collision :
---->Calcule de l’intersection dans le repère local puis transformation de ce point intersection dans le repere global.

Mais ta solution OBB semble bien moins couteuse de plus elle peut permettre une meilleur qualité pour le system de collisions

Je m’aperçois également que de calculer le point d’impact dans le repère local au model n’est pas suffisant, il faut également que j’assigne ce point d’impact a un bone du squelette. Du coup l’idée d’exprime ce point d’impact dans le repère du skin (coord UV) me semble de plus en plus pertinent !
Comment a tu fais ce changement de repère ? tu l’interpole de façon quadratique à partir des 3 texels de ton triangle ?

Je ne connais pas milkshape3D mais de toute façon il faut écrire un module de parse pour réécrire les animations au format JSON

En réalité je m’en suis passé! je parse directement le fichier binaire c’est possible depuis la nouvelle API de l’XHR. Cela a plusieurs avantage : pas besoin de convertisseur, plus léger à transférer et plus simple à parser (remarque non valable pour du JSON ). J’ai choisi le format de MilkShape 3D en raison de la liste impressionnante de format d’import, l’inconvénient est que l’outil d’édition est un shareware.

[lightbulb]

Pour changer le repère de mon rayon j'utilise la matrice Model-view et la matrice des Normales transmises à la CG.

Lors d'un clic correspondant à un lancé de rayon je transforme mon rayon issu de l'unprojection ou de l'axe de la caméra grâce à ces deux matrices.

Faut que je regarde pour la nouvelle API du XHR c'est intéressant mais je ne sais pas si c'est plus rapide que l'UTF-8. Pour le moment je me sers de la librairie de google :

http://code.google.com/p/webgl-loader/

Dans ce projet aucune donnée ne transitera en JSON, c'est utf-8 crypté et DDS crypté. Les graphistes ont pas envi de se faire voler leur travaux.

Sinon pour le moment je reste avec mes plans générés à l'impact le temps de trouver comment transformer un point de collision en coordonnées UV et générer une texture superposable de manière optimisée.

Que ce soit un mesh annimé ou non c'est la même chose, tu récupères un point d'un tris que tu transposes en coordonnées UV. Le reste, c'est de la physique.