Discussion :

[js89dextra]

Bonjour à tous,

Dans le cadre d'un projet, j'ai développé un outil de filtrage d'un nuage de points 3D par une caméra. Je m'explique. J'ai un nuage de points 3D. Ce nuage de points est réparti dans un octree. Je visualise ce nuage de points dans une fenêtre à l'écran. Dans cette fenêtre, en plus du nuage de points, j'affiche aussi une caméra C dont je peux changer la position (translation et rotation). Cette caméra est définie par ses paramètres intrinsèques (normal) ainsi qu'un plan near et far. Une fois sa position définie, je calcule le frustrum de la caméra, puis je calcule l'intersection de l'octree avec le frustrum. Enfin, pour toutes les cellules qui coupent le frustrum, j'extraie les points 3D contenus à l'intérieur. Je ne garde que ceux qui sont à l'intérieur du frustrum (après projection sur le plan focal de la caméra C) et je les colore en rouge pour les distinguer.

Çà marche bien et assez vite (avec mes jeux de données). Seulement, je trouve ça un peu lourd, et j'aimerais faire fonctionner le tout en temps réel (ou du moins, le plus rapidement possible). Je m'interroge donc sur la faisabilité d'une autre méthode que je vous décris ci dessous.

J'aimerais profiter de la rapidité du GPU, plutôt que de faire tous ces tests d'intersection (algorithme Separating Axis Test) sur le CPU. L'idée est de se passer de l'octree. En voilà les deux points principaux :

1. Je dessine dans un framebuffer la scène vue du point de vue de la caméra C (je connais les paramètres extrinsèques et intrinsèques, le plan far et near). Si j'ai bien compris, toutes les étapes de culling...etc seront faites par le gpu et beaucoup plus rapidement (fait par le matériel). A ce point, je me retrouve avec un framebuffer qui contient la projection de tous les points à l'intérieur du frustrum de la caméra C.

2. Même si le tout n'est pas tracé à l'écran, on peut quand même activer un zbuffer (par exemple) pour le framebuffer (je l'ai déjà fait dans un autre projet). De la même manière que le zbuffer contient la profondeur des points tracés, est-il possible d'activer un autre type de buffers (dans les versions plus récentes d'OpenGL) qui contiendrait l'indice des points tracés ? Cela me permettrait alors de lire simplement les pixels du framebuffer et de récupèrer les indices des points. On m'a dit qu'avec OpenGL 3 ou 4 (je ne sais plus exactement), il était possible d'associer des valeurs aux points 3D (dans mon cas, ce serait l'indice dans le nuage de points), et de récupérer ces valeurs pour les points tracés à l'écran.
(Ensuite, dans un deuxième temps, il faudrait aussi gérer le cas où plusieurs points se projettent sur le même pixel...)

Je ne sais pas si c'est très très clair. Ce deuxième point ne me paraît pas évident mais je suis sûr qu'il y a un moyen de remonter à l'indice des points affichés (avec des shaders ? Opengl 4 ?... ?). Si quelqu'un a une idée !

Merci d'avance

Bonne journée

JS

[LittleWhite]

Bonjour,

Si vous utilisez une technique de rendu différé (defered rendering), qui consiste en faire un premier rendu dans un buffer (FBO), puis d'utiliser cette/ces textures pour faire un traitement puis le rendu final, alors oui, vous allez pouvoir associer des données à chaque point/pixel.

Voici l'idée :

Vous faites un rendu dans un FBO et grâce à votre shader, vous remplissez une texture de couleur classique et une seconde texture contenant les index de vos points (le tampon de profondeur est rempli "automatiquement").
Ensuite, vous récupérez vos textures et vous en faites le traitement voulu.

Si plusieurs points se projettent sur le même pixels, bah, oui et non, c'est le tampon de profondeur qui joue et vous gardez que le point le plus proche. Mais cela ne vous arrange peut être pas.

Finalement, pour votre explication du frustrum culling, il faut que vous fassiez des tests afin de savoir s'il est plus rapide d'afficher tous les points, même ceux en dehors de l'écran que de faire les calculs du frustrum culling coté CPU. Si l'affichage est plus rapide dans tous cas, alors le frustrum culling ne sert à rien (ou est trop lent), mais ce serait assez étonnant.

[js89dextra]

Bonjour,

Merci pour votre réponse LittleWhite. Je vais essayer ça. Il y a quelques petites choses que je ne comprends pas encore.

Je n'ai pas trop compris votre dernier paragraphe :
Pour le moment, je fais le frustrum culling avec le CPU. Je pensais que ce serait forcément plus rapide de faire les calculs avec le FBO (calculs faits avec le pipeline graphique (?)). Ce n'est pas si évident d'après toi ? (oui, peut-être que s'il y a plusieurs millions de points...)

Sinon, concernant la projection de plusieurs points sur le même pixel, n'y a-t-il pas moyen de garder en mémoire tous les points qui se projettent sur le même pixel et de tous les traiter par la suite. (je ne suis pas très familier avec les shaders, c'est pour ça que je ne me rends pas trop compte).

Merci,

[LittleWhite]

Actuellement, je ne vois pas le moyen de garder l'information pour plusieurs points, alors que le pipeline peut en zapper volontairement pour des raisons de tampon de profondeur. Lorsque je dis "zapper", les optimisations qui sont dans nos cartes graphiques évite au maximum les calculs inutiles des points cachés par d'autres, que ce soit avant, ou après le fragment shader.

Pour le culling, disons que grâce à un octree ou similaire, le CPU ne va pas trop lentement. Je n'imagine pas que la carte graphique ou votre implémentation coté GPU, utilise un octree .
Pour les points, une fois passé le vertex shader et donc, que la carte sait que le point est en dehors de l'écran, alors il est zappé. Mais il faut passé le vertex shader et cela pour des milliers de points (au minimum, le calcul MVP * position du point). Il y aussi le coût (car c'est un des bottleneck courant) du transfert CPU -> GPU. Lorsque vous appliquez l'optimisation coté CPU, vous transférez moins de donner au GPU (en théorie).
Du coup, la question est : "est ce qu'il est plus rapide de balancer tout les points est laissé le GPU faire, ou n'afficher que les points utiles et faire de l'optimisation coté CPU ?". Le rapport n'est pas du tout sur et le mieux est de tester pour voir quelles est la meilleure méthode.

[js89dextra]

Justement, je crois qu'il est possible de passer tous les points au gpu une première fois et les laisser dans des mémoires du gpu, puis de faire les traitements sur ces points (plus de passage cpu->gpu à chaque fois). C'est bien ça ?

Dans ce cas, je passe toujours mon vertex shader qui d'appliquera aux points dans la mémoire du gpu. C'est ça ?

Et non, je n'ai pas d'octree implémenté côté gpu... :-P

[p3ga5e]

Salut ,

Si le but de tester, si un point se trouve dans le champ de ta camera C, sert uniquement à définir sa couleur de rendu pour le distinguer, alors pose toi la question de l’intérêt de vouloir récupérer cet information coté CPU !

Car tu peux très bien te passer d’un FBO , en utilisant 2 projetions dans ton vertex shader : tous d’abord dans le repère/plan de ta camera C pour déterminer la couleur, puis dans le repère/plan de ta fenêtre de rendu !

Un truc du genre :

Code GLSL :

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
attribute vec3 position;
uniform mat4 ViewCameraC;
uniform mat4 ViewMainCamra;
uniform mat4 projectionCameraC;
uniform mat4 projectionMainCamra;
 
const vec4 RedColor =  vec4(1.0,0.0,0.0,1.0);
const vec4 WhiteColor =  vec4(1.0,1.0,1.0,1.0);
varying vec4 color;
 
// Vertex Shader
void main() 
{
	vec4 pos = projectionCameraC * ViewCameraC * vec4( position, 1.0 );
	color = (abs(pos.x)<=1.0 && abs(pos.y)<=1.0)? RedColor : WhiteColor; 
 
	gl_Position = projectionMainCamra * ViewMainCamra * vec4( position, 1.0 );
}
 
// Pixel Shader
void main() 
{
	gl_FragColor = color;
}

[js89dextra]

Salut p3ga5e,

Oui effectivement, je pourrais faire quelque chose du genre. Mais j'aimerais surtout récupérer les indices des points pour pouvoir ensuite appliquer des calculs sur cette partie du nuage visible par la caméra C.