Discussion :

[jamesb]

Bonsoir à tous,

Je me lance dans la création de moteurs de jeux en OpenGL, j'essaie d'abord de me documenter sur les bases, les traitements en computer graphics en général. Parmi tout ceci j'ai quand même une question qui reste sans réponse: Est-ce que les objets qui doivent être dessinés doivent être stockés (temporairement) au lieu d'être affiché directement ?

Il y a beaucoup d'algorithmes qui requièrent une vue globale de tout ce qui est à dessiner comme le "Frustum culling", le LOD ("Level of Details"), Raycasting (je suppose aussi). Ces algorithmes doivent bien traiter les données avant qu'elles soient affichées, sinon ça ne sert à rien justement. Il faut donc forcément que les objets soient stockés dans une structure de "mise en attente" pour pré-traitements, ou est-ce que je trompe ?

Si tel est bien le cas, quelles sont les structures que l'on utilise en général (sachant que je fais du C), les algorithmes. Auriez-vous des articles en parlant, des sources à lire svp ? Merci de m'éclairer dans cette obscurité sans fond.

[LittleWhite]

Bonjour,

Pour le frustrum culling, le calcul peut être fait avant l'affichage, à la volé. Il faudra juste se préparé une boite de collision, pour savoir si l'objet est dans l'écran ou pas.
Du coup, s'il n'est pas dans l'écran, on n'affiche pas. Point final

-> Donc pour un objet 3D, on calculera à l'avance une boite englobante, pour faire les calculs rapidement.

Le LOD, je crois qu'il est fait aussi à la volée par les shaders. Je ne suis pas à 100% sur là dessus. Sinon il peut aussi être fait par un post processing, selon le schéma suivante:

Rendu simple de la scène -> Tout dans une texture -> Affichage de la texture à l'écran avec un shader, le shader fait une operation de post processing ( LOD pour notre cas ) -> écran

[jamesb]

Merci de ta réponse

Bien, je commence à saisir. Il faut gérer les données/vertices lorsqu'on veut les dessiner.

Cependant, cela ne sera pas applicable de cette manière pour la gestion des collisions, non? On utilise des formes simple genre boite et paralléle à l'axe d'origine? Il faut stoquer ces boites pour tester?

Concernant les shaders, ce sera pas pour demain pour moi. J'ai beaucoup à faire avant.

[coda_blank]

Bonjour,

Pour le frustrum culling, le calcul peut être fait avant l'affichage, à la volé. Il faudra juste se préparé une boite de collision, pour savoir si l'objet est dans l'écran ou pas.
Du coup, s'il n'est pas dans l'écran, on n'affiche pas. Point final

-> Donc pour un objet 3D, on calculera à l'avance une boite englobante, pour faire les calculs rapidement.

Le LOD, je crois qu'il est fait aussi à la volée par les shaders. Je ne suis pas à 100% sur là dessus. Sinon il peut aussi être fait par un post processing, selon le schéma suivante:

Rendu simple de la scène -> Tout dans une texture -> Affichage de la texture à l'écran avec un shader, le shader fait une operation de post processing ( LOD pour notre cas ) -> écran

je ne vois pas bien comment on peut faire du LOD a la volée, par LOD on entend bien un chargement différent de mesh/textures/animation selon la distance, non ? comment faire cela dans les shaders ? à moins que tu ne té réfères à la tesselation, mais c'est assez couteux il me semble

et je comprends encore moins la notion de LOD après le rendu

[LittleWhite]

et je comprends encore moins la notion de LOD après le rendu

Première passe, on fait le rendu de la scène ( pas de problèmes dessus ).On sauvegarde aussi le buffer de profondeur,
Deuxième passe, on floutte ce qui est a une distance qui ne nous plait pas ( utilisation du buffer de profondeur pour connaitre les distances, floutage en faisant une moyenne des pixels alentours de celui qui est vérifié ( merci le rendu vers texture ).

Pour le chargement des données, c'est tout au début, on charge une textures, et on fait un mipmapping dessus, pour faire plus ou moins de détails selon la distance.

Cependant, cela ne sera pas applicable de cette manière pour la gestion des collisions, non? On utilise des formes simple genre boite et paralléle à l'axe d'origine? Il faut stoquer ces boites pour tester?

La gestion de collision est faite du coté CPU, ce qui veut dire, avant même d'executer les fonctions d'affichages.
Forme simple comme des boites oui, mais pas de besoin nécessaire. On stocke les boites, avec les objets ( pour eviter de les régénérés à chaque image ).

[jamesb]

Ca ressemble plus au Depth of field qu'au Lod, qui consiste à dessiner moins de poly lorsqu'un objet est loin (exemple la sphère).

Sinon pour la structure des boites, vous faites simplement deux x, y, z, minimum et maximum et vous les stoquer dans un tableau de toutes les boites, par exemple? Ou alors vous séparez les boites d'objets mobiles?
Quand tu dis avec l'objet, c'est pas très précis puisque pour le moment je n'ai pas structure contenant chaque objet à dessiner. Aussi faut il calculer la boite selon un axe local de l'objet, ca évite de recalculer la boite pour une translation, parcontre pour une rotation?

Merci encore.

[coda_blank]

Ca ressemble plus au Depth of field qu'au Lod, qui consiste à dessiner moins de poly lorsqu'un objet est loin (exemple la sphère).

Merci encore.

hum, en effet LittleWhite, je crois que tu m'as décrit le depth of field et non pas le level of details, celui-ci permettant de limiter le nombre de vertex envoyés au GPU avant le rendu afin d'éviter de rendre des détails qui ne seront pas visible à l'oeil nu

[LittleWhite]

Oui je pense que j'ai faux.

Pour le LOD je ne sais pas le faire :s.

Pour les rotations, oui, il faudra recalculer la boite. Sinon, on peut aussi utiliser une sphère de collision, qui est moins précise.
Quand je dis, attaché à l'objet, d'un point de vue du design de l'application. Sinon, oui je garde juste les points en min et max. ( Qui sont généré au début, qui sont dans les coordonnées de l'objet ).