Bon et bien j'ai ajouté une source de lumière et la map apparaît entièrement noire, alors que je me réjouissais il y a qqs heures que Irrlicht permettait de gérer plus facilement l'éclairage que OpenGL ... De plus en plus déçu
Bon et bien j'ai ajouté une source de lumière et la map apparaît entièrement noire, alors que je me réjouissais il y a qqs heures que Irrlicht permettait de gérer plus facilement l'éclairage que OpenGL ... De plus en plus déçu
Salut KevinduC si tu retournes avec Open GL as-tu pensé à des techniques comme le View Frustum ?
Je ne connais pas, qu'est-ce que c'est ?
Le View Frustum et notamment le Frustum Culling cela consiste à créer une sorte de volume en 3d où seuls les polygones et objets 3d donc sont affichés.
C'est comme si on prenait un appareil photo ou caméra tout ce qui sort du champs de vision n'est pas représenté.
Il doit certainement exister des tutos pour Open GL voire même sur DVP![]()
Si tu parle de Viewing frustum culling alors Irrlicht doit le faire j'imagine.
Sinon il est facile a faire , mais pour cela il ne faut pas utiliser glu et glrotatef etc ,donc d'utiliser a la main la matrice de projection et de view , ensuite il faut l'appliquer sur une Box et voir si elle se trouve bien a l'écran (et donc de choisir de ne pas l'afficher quand elle est hors de l'écran).
Mais pour cela il ne faut pas utiliser de grosse map comme je l'ai dit auparavant
Le second point , c'est mauvais de mettre une trop grosse map comme model 3D parce que cela empêche de faire comme optimisation le "Viewing frustum culling".
Je vois le principe mais le faire à la main me semble délicat : A chaque frame il faudrait calculer la position de chaque vertex par rapport à la caméra, ça risque de ramer
Euh wat ?
La matrice de projection se calcul qu'une seule fois par frame , celle du view se calcul par le nombre de model que tu as !
Et justement le calculer sois meme est plus rapide , vu la m**** qu'est le code de glu et glrotatef/gltranslatef
Ensuite il faut pas le faire a chaque vertex de ton model , mais sur une Box (donc un truc qui représente 8 vertex ).
D'accord mais si je veux connaître la position des objets par rapport à la caméra je suis obligé de faire le calcul pour chaque vertex de chaque objet (Si au moins un vertex de l'objet est dans la box alors il est visible)
Non tu as mal compris , une Box représente juste les 'limites max' de ton model 3D , tu n'a jamais besoin de calculer chaque vertex et si la box est a l'écran alors tu affiche ton model ,sinon tu ne l'affiche pas tout simplement.
Ah d'accord, je pensais que tu parlais de la zone de visibilité de la caméra
Oui enfin c'est délicat quand même : Par exemple il faudrait que je définisse un VBO pour chaque poteau de caténaire, un autre pour la voie ...
Et c'est quoi la différence entre les deux ?
Parce que ce que tu affiche a l'écran est justement la zone de visibilité de la caméra !
Exact pour cela que OpenGL 3 a fait des VAO pour éviter le nombre d'appel !
Bref , OpenGL cache une bonne partie de la pipeline 3D (surtout les premières version 1 et 2 ) donc peut être pour ça que tu comprend mal ce que je raconte , comme le dit Mat doit y'avoir des tuto qui t'explique le fonctionnement , sauf si tu utilise un moteur 3D (Ogre 3D , Unreal engine , Unity autre) qui possède ce genre d'optimisation en interne.
Non non j'ai compris le principe du frustum culling finalement, c'est pourquoi j'ai passé deux jours à coder des fonctions permettant de charger des fichiers .obj dans un ou plusieurs VBOs ^^, il me reste à déterminer les fameuses box et leurs 8 vertices. Au passage je suis conscient qu'on s'éloigne beaucoup du sujet initial mais je profite d'être en contact avec vous pour poser une question qui n'a certes rien à voir : J'ai un vague projet qui nécessiterait d'utiliser des périphériques tels que casque de réalité virtuelle et accéléromètres, je me doute bien que SDL ne prend pas en charge cela, pourriez vous m'indiquer s'il est possible de coder soi-même l'interface avec mon programme ?
Partager