Discussion :

[KevinduC]

Bonsoir, cela fait des heures que j'essaie de modéliser un rectangle dans mon geometry shader avec la sortie triangle_strip. Quoi que je fasse je n'obtiens que des triangles orientés différemment ou bien rien du tout, il est pourtant précisé ici que les sommets étaient pris par paquets de 3 de sorte à ce que 4 sommets suffisent à former deux triangles mais dans mon cas on dirait que le 1er sommet est toujours ignoré.

Je dessine mes vertices de cette manière :



Si je remplace "triangle_strip" par "line_strip" j'obtiens ceci :



Voici mes shaders :

Vertex shader :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#version 330 core
 
layout (location=0) in vec3 vertex;
 
uniform mat4 projection;
uniform mat4 modele;
uniform mat4 vue;
 
out VS_OUT {
    vec4 pos;
} vs_out;
 
void main(void)
{
	vec4 vertex2=vec4(vertex,1.0);
 
	//gl_Position=projection*vue*modele*vertex2;
 
	vs_out.pos=vertex2;
}

Geometry shader :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#version 330 core
 
layout(points) in;
layout(triangle_strip, max_vertices = 4) out;
 
uniform mat4 projection;
uniform mat4 modele;
uniform mat4 vue;
 
in VS_OUT {
    vec4 pos;
} gs_in[];
 
void main()
{
    const float largeur=2.0;
    const float hauteur=10.0;
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,largeur/2,0.0,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,largeur/2,hauteur,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,-largeur/2,0.0,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,-largeur/2,hauteur,0.0));
    EmitVertex();
 
    EndPrimitive();
}

Fragment shader :

Code :

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

1
2
3
4
5
6
7
8
#version 330 core
 
out vec4 FragColor;
 
void main(void)
{
	FragColor=vec4(1.0,0.0,0.0,1.0);
}

Avec ce geometry shader rien n'est dessiné (Pour une raison mystérieuse), avec celui-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#version 330 core
 
layout(points) in;
layout(triangle_strip, max_vertices = 6) out;
 
uniform mat4 projection;
uniform mat4 modele;
uniform mat4 vue;
 
in VS_OUT {
    vec4 pos;
} gs_in[];
 
void main()
{
    const float largeur=2.0;
    const float hauteur=10.0;
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,largeur/2,0.0,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,largeur/2,hauteur,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,-largeur/2,0.0,0.0));
    EmitVertex();
 
	///////////////////////////////////////////////////////////////////////////////////////////////
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,-largeur/2,0.0,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,largeur/2,hauteur,0.0));
    EmitVertex();
 
	gl_Position = projection*vue*modele*(gs_in[0].pos + vec4(0.0,-largeur/2,hauteur,0.0));
    EmitVertex();
 
    EndPrimitive();
}

J'obtiens des triangles posés sur la pointe. J'ai essayé d'autres configurations mais je n'obtiens JAMAIS de rectangles.

Pourriez-vous m'aider svp car là je sèche complètement ...

[dragonjoker59]

On peut voir les résultats que tu obtiens, avec l'un et l'autre shader ?

[LittleWhite]

Bonjour,

Combien de points dessinez vous (envoyez vous à la carte graphique) ? Envoyez-vous ces points directement en espace écran ?
La largeur me semble vraiment petite, mais bon, cela dépend de quel espace nous nous trouvons.
Avez-vous tenté un débogage avec un débogueur GPU ?

[KevinduC]

J'ai résolu le problème finalement, merci pour vos messages, il faut apparemment dessiner dans un ordre précis, en suivant la structure d'un Z et non d'un N comme je faisais.

Bref sinon j'aimerais avoir vos avis sur la meilleure manière de dessiner un arbre car j'utilise ici quatre surfaces texturées disposées en étoile mais une fois l'éclairage mis en place ça fait ressortir les surfaces et je n'aime pas trop :

[LittleWhite]

Pour les arbres, je pense que vous utilisez une méthode des années 2000. Pour régler rapidement le problème, enlever les arbres du processus d'éclairage (autrement dit, les arbres ne sont pas affectés par l'éclairage). Donnez leur juste une couleur fixe. Si jamais vous avez un éclairage dynamique (notamment un cycle jour/nuit), faites varier la couleur.
Sinon, je pense que dorénavant, on utilise des modèles 3D pour les arbres. Sinon, il faut utiliser des billboards (carré qui font toujours face à la caméra).

Autrement, cette technique peut être valable pour du très bas niveau de détail, c'est-à-dire, pour des arbres très loin.
On remarquera sur la chaîne suivante, pas mal de triche pour les objets lointains :
https://www.youtube.com/channel/UCHT...wm49CQeCVZogMw

[KevinduC]

J'ai aussi pensé à utiliser un billboard mais j'ai un léger souci : Pour calculer l'orientation de la surface je calcule le produit scalaire entre le vecteur normal à la surface (1,0,0) et le vecteur reliant la surface à la caméra et j'utilise la fonction acos() mais cette fonction ne fournit pas de valeur au-delà de 180° donc par moments la surface est mal orientée.

Pour les modèles 3D c'est délicat car il y a plus de 80 000 vertex pour un arbre (Je l'ai modélisé sous Blender et fait des rendus pour avoir mes textures) et je ne peux pas faire ça avec un geometry shader. C'est pour gagner en performance que je veux utiliser un geometry shader : L'arbre n'est dessiné que si la caméra est proche.

Edit : J'ai finalement réussi à faire en sorte que la surface soit toujours alignée avec la caméra mais je n'aime pas trop le résultat car on peut voir la surface pivoter : https://imgur.com/a/ZrcYdb0

[dragonjoker59]

je calcule le produit scalaire entre le vecteur normal à la surface (1,0,0) et le vecteur reliant la surface à la caméra et j'utilise la fonction acos()

Il y a mieux qu'un acos, quand on sait que la view matrix contient les informations dont tu as besoin :

Code :

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

1
2
3
4
5
6
7
8
9
10
// Récupère le vecteur pointant vers la droite depuis la caméra
vec3 getViewRight(mat4 viewMatrix)const
{
	return vec3( viewMatrix[0][0], viewMatrix[1][0], viewMatrix[2][0] );
}
// Récupère le vecteur pointant vers le haut depuis la caméra
vec3 getViewUp(mat4 viewMatrix)const
{
	return vec3( viewMatrix[0][1], viewMatrix[1][1], viewMatrix[2][1] );
}

Ca simplifie les calculs :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Input quad (vertex input rate)
layout( location = 0 ) in vec2 position; // position relative au centre du billboard, sur [-0.5, 0.5]
// Current billboard (instance input rate)
layout( location = 1 ) in vec3 center; // position du centre du billboard
 
void main()
{
	vec3 wsCenter = ( worldMatrix * vec4( center, 1.0_f ) ).xyz();
	vec3 right = normalize( getViewRight( viewMatrix ) );
	vec3 up = normalize( getViewUp( viewMatrix ) );
	vec3 wsPosition = wsCenter
		+ right * position.x * dimensions.x
		+ up * position.y * dimensions.y
	gl_Position = projMatrix * viewMatrix * vec4( wsPosition, 1.0 );
}

Pour un peu de contexte sur le micmac "position" et "center", dans mon moteur, je fais de l'instanciation hardware sur un quad (qui contient "position") avec pour données par instance "center".

Je passais à l'origine par un point que je transformais en quad dans un geometry shader (ça te parle ? ), mais j'en suis revenu, parce qu'en fait c'est de la merde au niveau perfs, par rapport à la solution que j'ai maintenant.

Les geometry shaders sont globalement à éviter, sauf cas particuliers.

EDIT

Pour les modèles 3D c'est délicat car il y a plus de 80 000 vertex pour un arbre (Je l'ai modélisé sous Blender et fait des rendus pour avoir mes textures)

80000 polys, c'est pas grand chose pour les GPU actuels, et l'instantiation hardware te permettra de n'avoir qu'un seul draw call pour N arbres.

et je ne peux pas faire ça avec un geometry shader.

Si tu utilises un mesh, tu n'auras plus besoin de geometry shader.

Si tu veux faire du culling, fais le sur CPU pour commencer, car les solutions performantes sur GPU sont complexes (un exemple utilisant les occlusion queries : https://developer.nvidia.com/gpugems...es-made-useful )
-

[Kannagi]

Pour les modèles 3D c'est délicat car il y a plus de 80 000 vertex pour un arbre (Je l'ai modélisé sous Blender et fait des rendus pour avoir mes textures)

Voilà un jeu fait avec 80 000-140 000 polygone et y'a plein d'arbre , et c'est jolie (et sur 24 Mo de RAM ) :

[LittleWhite]

Je rejoins dragonjoker59 sur les geometry shader. Ce que j'avais vu à l'époque c'est que la seule implémentation potable (autrement dit, efficace/rapide) c'est chez Intel. Du coup, au final, tout le monde a fait l'impasse sur ces shaders. Les tesselation shader sont arrivé peu de temps après et permettait de faire des choses "similaires". Du coup, à part des cas spécifiques, le geometry shader... c'est fini.

Pour vos arbres : avec un billboard, plus besoin de dessiner deux textures. Une seule suffit. Bien sûr que la triche se voit un moment ou un autre, c'est pour ça qu'on les réserve pour les trucs lointains. Pour tout ce qui est proche, un modèle 3D sera bien mieux. Autrement dit : pour tout ce qui est loin, on peut faire autant d'artifice que l'on veut, tant que le rendu est acceptable. Pour ce qui est proche (sous l'oeil du spectateur) alors là, on va vouloir utiliser plus de puissance de la machine et peauffiner le truc jusqu'à ce qu'il soit tiptop (même si c'est de la triche à mort, mais bon, en 3D, tout est triché ).

Et oui, l'instanciation permet de dupliquer des modèles avec un coup faible, tout en poussant le nombre de polygones à l'écran.

[KevinduC]

L'instanciation c'est une bonne solution mais une question me taraude l'esprit : Comment je peux gérer instance par instance le cas de la caméra proche ou éloignée ? Je peux bien sûr envoyer les coordonnées de la caméra en uniforme au vertex shader mais comment dire à ce dernier : "Dessine le modèle 3D ou "Ne dessine qu'un billboard" ? C'est pour ça que j'ai été tenté de passer par un geometry shader car dans ce cas il est facile de demander à ce dernier d'ajouter ou non certains sommets, mais bon apparemment vous me déconseillez cette option et de toute façon impossible de dessiner une forme complexe avec un geometry shader.

[LittleWhite]

Pour complexifier un modèle à la volée, on utilisera certainement un tesselation shader. De mémoire, le geometry shader ne pouvant ajouter qu'une petite centaine de points.

L'instanciation permet de répéter un même modèle. En tableau de variables uniformes ont donnera la matrice objet (donc, position, rotation et redimensionnement), ce qui donnera déjà un bon niveau d'unicité pour l’œil non aguerri du joueur. Cela me rappelle qu'il y a un tuto en français sur Developpez.com sur ce sujet. Après, on peut toujours passer plus d'information à chaque instance, mais il faut bien comprendre que c'est toujours le même objet qui est dessiné plusieurs fois. L'astuce en performance est que l'objet n'est transféré qu'une fois sur la carte graphique, pour être dessiné plein de fois, tout en gardant de l'unicité (sachant qu'un gros goulet d'étranglement des jeux, c'est les transferts CPU -> GPU). C'est mieux que d'agrandir les tableaux de sommets/indices.

[KevinduC]

C'est-à-dire ? Comment je peux faire en sorte que telle instance soit dessinée en trichant (Un billboard par exemple) et l'autre en modèle 3D complexe ? Je ne peux pas dire à mon vertex shader "Dessine un billboard" ou "Dessine le modèle 3D complexe" selon où se situe la caméra

Voilà un jeu fait avec 80 000-140 000 polygone et y'a plein d'arbre , et c'est jolie (et sur 24 Mo de RAM ) :

Comment ils arrivent à faire quelque chose d'aussi joli ? Lorsque j'applique une texture à un sol j'ai cet effet de répétition qui enlève le côté naturel

[LittleWhite]

Pour le sol, il y a plusieurs procédés (encore). Vous pouvez utiliser une texture dont les bords sont conçus que si vous répétiez la texture, vous ne voyez pas la bordure (principe de mosaïque) -> https://duckduckgo.com/?q=tileable+t...ges&iax=images .
Vous pouvez utiliser une texture (ou plutôt, plusieurs) que l'on va recouvrir l'une sur l'autre et cela, à différent endroits de la carte (voir les tutoriels de multitexturing).

Pour l'histoire des différents niveaux de détails. Eh bien, en réalité, on peut imaginer un vertex shader/fragment shader dédié aux modèles 3D et un second couple dédié au billboard. Vous aurez alors une boucle de rendu de la sorte :

Code :

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

1
2
3
4
5
utiliser le program shader pour les modèles 3D (glUseProgram)
dessiner les modèles 3D (un glDraw)
 
utiliser le program shader pour les billboard
dessiner les billboard (un glDraw)

En bref, les jeux, les programmes et autres embarquent une "grande" quantité de shader. Suivant ce qu'ils ont à dessiner, ils vont charger/préparer/utiliser le bon. D'ailleurs, généralement, c'est un shader par matérial. Il y a des programmes qui ont aussi des uber shader, qui sont capable de faire différents type de rendu suivant des flags envoyés par le CPU. Quelques fois, on peut même voir de la création de shader à la volée (même si en OpenGL, le processus de compilation pouvait être pénalisant. Mais avec les shaders binaires/précompilés, c'est moins problématique).

Bref, oui, vous pouvez avoir un shader pour chaque type de rendu que vous souhaitez . Un programme essaie de maintenir la barre des glDraw aussi basse que possible (c'est couteux), mais on peut aisément en compter une centaine par image.

[KevinduC]

Ah super ! Des textures seamless gratuites grande résolution, merci ! Sinon je viens d'utiliser une texture générée en Perlin Noise envoyée à mon fragment shader pour que ce dernier jongle entre deux textures selon la valeur du texel, on va dire que c'est un peu plus esthétique.

Sinon je comprends pas en quoi ton algorithme permet de choisir si l'on va dessiner le modèle 3D ou le billboard selon la position de la caméra. Ce que je veux dire c'est que chaque instance doit être au courant de la position de la caméra, je ne vais pas envoyer les coordonnées de la caméra en attribut dans le VBO, sinon aucun intérêt d'utiliser un VBO.

Edit : En fait je voudrais faire l'équivalent de ceci mais de manière optimisée :

Code :

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

1
2
3
4
5
6
7
8
9
for(int i=0; i<nbArbres; i++)
{
	const float distCam=...
 
	if(distCam<=50.0f)
		glDrawArrays(modele3D);
	else
		glDrawArrays(billboard);
}

[dragonjoker59]

C'est pas le shader qui choisit quoi afficher, c'est ton programme, lors de la préparation des draw calls.

[KevinduC]

Ce serait possible si la position de la caméra était fixe, mais comment faire si ce n'est pas le cas ?

[LittleWhite]

La position de la caméra, certes dynamique, est connue du CPU, ainsi que la position de chaque objet dans le monde. D'ailleurs la position de la caméra est utilisée pour créer la matrice de vue (avec des trucs tel que glm::lookAt). Donc, vous avez les deux positions (normalement, des vec3), vous pouvez donc faire une fonction de distance (généralement, la racine carré de la différence des carrés des composantes, mais sinon, surement glm::lookAt). Suivant le résultat, vous allez pouvoir dire : cet arbre sera un billboard et non un modèle 3D.
Et ce calcul (le if et tout), vous le faites pour chaque image (donc, dans la fonction de rendu).

(Généralement, on va gérer deux listes (ou N), une liste de billboard et une liste de modèle. Lorsque l'arbre est loin, on rajoute les informations nécessaires dans la liste des billboard. Sinon, dans la liste des modèles. Ensuite, lorsque l'on fait le rendu, on parcours les listes en question, pour les afficher comme il faut. Plus précisément, les listes permettent de générer le contenu des tampons à envoyer au GPU. Cela explique mon pseudo code.)

[KevinduC]

Donc il n'y a pas d'autre choix que d'aller modifier le contenu des VBO pendant le rendu ? Si c'est le cas aucun intérêt d'utiliser les VBO

[LittleWhite]

Ce n'est pas fini !
Il existe des tampons dédiés au streaming (on indique au GPU qu'ils vont souvent changer de contenu) et des tampons plus fixes. Après, vous pouvez mettre en place des mécanismes d'optimisation, tel que si pas de changement, pas de transfert. De plus, un VBO, c'est toujours mieux que les glVertex() d'OpenGL 1. En bref, vous avez encore beaucoup à découvrir .

[KevinduC]

Merci mais ça fait longtemps que j'ai délaissé glVertex() et OpenGL 2, encore heureux d'ailleurs ... J'aimerais en savoir plus sur ces tampons, en quoi est-ce qu'il permettent de choisir de dessiner tel ou tel modèle selon la position de la caméra ?