Discussion :

[zedrummer]

Bonjour
Je souhaite faire un affichage type jukebox sur mon écran avec les étiquettes (avec les noms des morceaux) qui font 180° de rotation sur l'axe X quand on change de page pour afficher les morceaux de la page suivante.
Le truc, c'est que j'ai une texture de la taille de l'écran qui est affichée pour remplir parfaitement l'écran (avec des cases pour les étiquettes) et mes étiquettes à afficher dans ces cases et qui donc tournent sur elles-mêmes en leur centre sur l'axe X quand on change de page. Je vois bien comment afficher la texture pour qu'elle remplisse parfaitement l'écran en utilisant la 2D et un vertex shader de type

Code :

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

1
2
3
4
 
    vec2 vertexPosition = vPosition - vec2(screenwidth/2,screenheight/2); // ramener le 0,0 au centre de l'écran
    vertexPosition /= vec2(screenwidth/2,screenheight/2); // ramener les coordonnées sur un intervalle [-1;1]
    gl_Position =  vec4(vertexPosition,0,1);

mais je sèche un peu pour afficher ça en 3D pour que ça remplisse parfaitement l'écran, que les étiquettes remplissent parfaitement les cases quand l'angle de rotation est nul ou 180°, les valeurs à donner en z en particulier aux vertices pour être sûr que le glm::perspective (j'utilise GLM pour mes matrices) ne me considère pas les coordonnées devant le near plane et du coup ne les affiche pas.
Merci bien de votre aide
David

[LittleWhite]

Bonjour,

D'après moi, vous devriez faire deux passes :

1. l'affichage des éléments "fixes" ;
2. l'affichage des éléments rotatifs (les étiquettes).

Après, peut être que j'ai mal saisi, mais sans capture, un peu dur à voir .

[Mat.M]

mais je sèche un peu pour afficher ça en 3D pour que ça remplisse parfaitement l'écran
David

bonsoir chercher dans un moteur de recherche bien connu "open gl view frustum culling"
Donc il faut extraire les plans du champs de vue et déterminer si les "vertices" appartiennent aux plans

[zedrummer]

Tout d'abord, merci beaucoup à vous 2 de vos réponses.
@LittleWhite:
Un schéma fait avec ma main gauche de droite est



Le souci avec l'approche "afficher les éléments fixes en 2D et les étiquettes en 3D" reste le même: comment faire pour que les étiquettes rentrent pile poil dans leur cadre 2D et quand elles ne tournent pas, qu'elles remplissent exactement les boîtes qui leur sont réservées?

@Mat.M: Je comprends la démarche, mais alors comment je fais?:
- Il faut que je choisis un z pour le plan de l'écran au hasard pour qu'il soit dans view frustum mais suffisamment loin/près pour que quand les étiquettes sont à 90°, elles soient entièrement entre le near et le far plane?
- Le z du near et far plane correspondent exactement à ce qui est fourni dans le glm::perspective?
- Et après, du coup, je dois faire par tâtonnement pour dans ce plan z déterminer depuis quel x/y jusqu'à quel x/y on reste dans le view frustum? Mais je ne suis jamais sûr que le pas que j'ai pris pour mon tâtonnement m'emmène sur le premier/dernier point de l'écran.

Merci encore
David

[Kannagi]

Pour moi , tu ne doit pas utiliser la Perspective, je tenterais de le faire en othogonal tout simplement.

bonsoir chercher dans un moteur de recherche bien connu "open gl view frustum culling"

Moi même je ne vois pas le rapport avec le view frustum culling et son soucis ?

[zedrummer]

En considérant que le dessin ci-dessous est le frustum, si j'arrivais à avoir les coordonnées des vecteurs en rouge:



j'arriverais facilement à trouver leur intersection avec le plan z=k, mais je ne sais pas récupérer ça du view frustum.

[Kannagi]

Le view frustum culling ,c'est une optimisation qui n'est pas faite par OpenGL (ni même aucune autre API , c'est au programmeur de décider de le faire )
C'est juste faire la transformation de perspective coté CPU , et ensuite tu regarde si les points sont hors de l'écran (en général ton model 3D possède une box pour éviter de faire des milliers de test) , si le model est hors de l'écran tu économise des draw call (et du coup des calculs GPU aussi vu qu'il va faire la transformation de perspective obligatoirement).

Alors comme je l'ai déjà codé , l'algo/code de la transformation de perspective est :

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
 
Vector3 LMP3D_TransformPerspectiveFPU(float* matrix,Vector3 vec)
{
	register float x,y,z;
 
	x = vec.x;
	y = vec.y;
	z = vec.z;
 
	vec.x = (matrix[0+0]*x) + (matrix[4+0]*y) + (matrix[8+0]*z) + (matrix[12+0]);
	vec.y = (matrix[0+1]*x) + (matrix[4+1]*y) + (matrix[8+1]*z) + (matrix[12+1]);
	vec.z = (matrix[0+2]*x) + (matrix[4+2]*y) + (matrix[8+2]*z) + (matrix[12+2]);
	w     = (matrix[0+3]*x) + (matrix[4+3]*y) + (matrix[8+3]*z) + (matrix[12+3]);
 
	if(w != 1.0f)
	{
		w = 1.0f/w;
 
		vec.x *= w;
		vec.y *= w;
		vec.z *= w;
	}
 
	return vec;
}

vec.x/vec.y donne les coordonnés de l'écran et vec.z donne la valeur pour le Zbuffer.

[zedrummer]

D'accord, j'avais lu ça.
Mais par contre n'y a-t-il pas moyen facilement de récupérer les coordonnées des vecteurs en rouge ainsi que la coordonnée de leur origine, SVP?

[Kannagi]

Moi je répondais juste pour le View frustrum culling et mes doutes sur ce que t'apporte le View frustrum culling à ton problème :p

Pour ton dessin ,je ne sais pas ce qu'il représente.

[zedrummer]

C'est le viewing frustum, le rose est le near plane, le jaune, le far plane.
Si j'ai ces coordonnées, je peux déterminer facilement les 4 coins du plan z=k et donc j'ai ma surface à dessiner pour que mon plan corresponde parfaitement à l'écran.
Merci

[Kannagi]

Pas sur de comprendre , les valeur du near/far sont déterminé dans ta matrice de projection.

[zedrummer]

Bah sur le dessin le volume correspond exactement au volume du viewing frustum, effectivement déterminé grâce à glm::perspective (équivalent de glPerspective) et j'aimerais pouvoir en déduire les coordonnées 3D des 4 coins du near plane (limité au viewing frustum) et de ceux du far plane (ou, c'est pareil, des vecteurs directeurs qui vont des 4 coins du near plane vers le far plane).

Avoir les coordonnées (x,y,z) des points en rouge ici en fonction de ce que je fournis à glm:perspective(field_of_view, rapport_hauteur_sur_largeur, zNear, zFar) (ou de la matrice retournée par cette fonction):

[Mat.M]

Je vois bien comment afficher la texture pour qu'elle remplisse parfaitement l'écran en utilisant la 2D et un vertex shader de type
mais je sèche un peu pour afficher ça en 3D pour que ça remplisse parfaitement l'écran
Merci bien de votre aide

attention des coordonnées bitmaps en 2d donc en pixels c'est pas du tout la même chose que des coordonnées dans l'espace en 3d..que l'on soit bien d'accord là-dessus
Un vecteur en 3d dans l'espace d'une part il est normalisé et d'unité 1 dans un repère orthonormé.
C'est ce que montre votre image dans votre intervention précédente avec les 3 vecteurs X,Y,Z et donc l'oeil de la caméra, tout le monde est d'accord ?
Après pour calculer la normalisation d'un vecteur en fonction d'un near plane et far plane ehh là faut voir l'API Open GL.

Le souci avec l'approche "afficher les éléments fixes en 2D et les étiquettes en 3D" reste le même: comment faire pour que les étiquettes rentrent pile poil dans leur cadre 2D et quand elles ne tournent pas, qu'elles remplissent exactement les boîtes qui leur sont réservées?

encore une fois il faudrait préciser si les coordonnées sont en pixels ou bien en coordonnées 3d...pour moi c'est fou.
Si tout est en rendu 3d dans un repère orthonormé pour que les éléments s'ajustent bien il suffit de différencier l'élément le plus grand avec ceux plus petits

Moi même je ne vois pas le rapport avec le view frustum culling et son soucis ?

j'ai suggéré cela à la question de savoir comment la texture de fond remplisse bien l'écran.
Je me suis mal exprimé en fait c'est la logique inverse, il faut utiliser la méthode du "clipping" donc déterminer les dimensions du champs de vision et calculer les extrémités max de la texture 2d

[zedrummer]

attention des coordonnées bitmaps en 2d donc en pixels c'est pas du tout la même chose que des coordonnées dans l'espace en 3d..que l'on soit bien d'accord là-dessus.

On est d'accord, mais si j'arrive à avoir des coordonnées 3D pour mon plan, je peux quand même très facilement projeter dessus ma bitmap pour qu'elle remplisse parfaitement ce plan et donc l'écran.
Seulement, comme je l'ai dit avant, pour avoir ce plan, il me faut les coordonnées des coins des 2 plans znear et zfar. D'où ma question: comment obtenir les coordonnées 3D de ces 8 points (bon du coup, j'ai le znear et zfar, me manque juste les x et y des 8 points).

[dragonjoker59]

Une seule solution facile, pour faire ce que tu souhaites faire : utiliser une projection orthographique, et pas un frustum.

[zedrummer]

Pardon, j'aurais dû l'écrire ici, j'ai eu ma réponse sur le forum de khronos.org ici https://community.khronos.org/t/disp...to-the-screen/ grâce à GClements:

The matrix generated by glm::perspective always has the form

Sx 0 0 0
0 Sy 0 0
0 0 C D
0 0 -1 0

where Sx=cot(fov/2)/aspect and Sy=cot(fov/2); C and D are determined from the near and far distances and don’t affect this calculation. Rather than calculating Sx and Sy, you should read them from the matrix generated by glm::perspective.

So you have:
xclip = Sx*xeye
yclip = Sy*yeye
wclip = -zeye

The edges of the view frustum are defined by the equations
xclip = -wclip (left)
xclip = wclip (right)
yclip = -wclip (bottom)
yclip = wclip (top)

In eye space, these become
Sx*xeye = zeye => xeye = zeye/Sx (left)
Sx*xeye = -zeye => xeye = -zeye/Sx (right)
Sy*yeye = zeye => yeye = zeye/Sy (bottom)
Sy*yeye = -zeye => yeye = -zeye/Sy (top)

IOW, just divide ±zeye by Sx and Sy to get the left/right/top/bottom edges in eye space. Note that zeye is negative for points in front of the viewer, i.e. -zfar < zeye < -znear.

Et ça marche parfaitement.