Discussion :

[KevinduC]

Bonjour, je débute avec Irrlicht et j'ai un léger souci : Lorsque je lance mon appli en plein écran l'image est déformée. Cela vient du fait que mon écran est en 16/9, la solution consisterait à récupérer le ratio de l'écran et de l'appliquer à la caméra au moyen de la méthode "setAspectRatio()", mais cela fait près de 2h que je cherche et je n'ai pas trouvé de solution pour récupérer le ratio (Voire la résolution) de l'écran. Jusqu'à présent j'utilisais SDL et la fonction "SDL_GetVideoInfo()" et ça fonctionnait sans problème.

Qu'est-ce que vous pourriez me conseiller ?

[KevinduC]

Bon c'est de pire en pire ici : En attendant de trouver une solution à ce problème j'en constate un autre : Irrlicht semble moins tolérant que OpenGL, jusqu'à présent j'utilisais l'API seule car mes maps étant de plus en plus lourdes, mes programmes devenaient rapidement lents. Et bien j'ai le plaisir de constater que c'est encore pire avec Irrlicht : Ce dernier ne supporte pas plus de 140 000 vertices ; au-delà, il affiche un beau message d'erreur : "Too many vertices for 16bit index type". Je suis déçu, moi qui m'attendait à résoudre mes problèmes de map lourde avec des moteurs graphiques (Irrlicht utilise ici la version 4.3 de OpenGL). Finalement ce moteur ne semble pas valoir grand-chose ...

[Kannagi]

Ce n'est pas que Irrlicht est limité à 140k vertices mais qui est limité à 65535 index vu que l'erreur est explicite : "Too many vertices for 16bit index type"
Je ne sais pas si on peut modifier cela.
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".

[KevinduC]

D'accord et comment je fais pour mes projets qui nécessitent des maps lourdes ? Je laisse tomber ? J'obtenais un meilleur résultat avec OpenGL 2.1

[Kannagi]

Je n'utilise pas Irrlicht donc je pourrais pas de dire !

J'obtenais un meilleur résultat avec OpenGL 2.1

Si tu parle de meilleur résultat en terme de performance ça m'étonnerai , OpenGL 4.2 permet de mieux exploiter le GPU que OpenGL 2 qui est déconseillé

[KevinduC]

J'ai l'impression que pour une même map les graphismes étaient meilleurs avec OpenGL 2.1, et je pouvais allouer assez de mémoire pour 1 000 000 de vertices.

[KevinduC]

Imaginons que je décompose ma map en plusieurs noeuds de scène, sachant que je peux faire la même chose avec les VBO sous OpenGL 2.1, quelle est la meilleure solution d'après toi ? Irrlicht ou les VBO ?

Edit : Voici deux captures d'écran de la même map :


(OpenGL 2.1)


(Irrlicht)

Comment expliquer avoir une meilleure qualité avec OpenGL 2.1 qu'avec Irrlicht ?

[Kannagi]

Ne le prend pas mal , mais je trouve que pour 140k vertices c'est particulièrement moche
Sinon j'ai l'impression que le contraste est moins élever entre les deux images.

Comment expliquer avoir une meilleure qualité avec OpenGL 2.1 qu'avec Irrlicht ?

Si Irrlicht ne te convient pas ne l'utilise tout simplement pas

[KevinduC]

Non je le prends pas mal ^^ Il n'y a pas 140k vertices ici, je n'ai pas pu faire un rendu avec ce nombre-là justement.

Je m'attendais à avoir un meilleur résultat avec un moteur graphique, je ne comprends pas pourquoi je constate le contraire.

Sinon tu n'as pas répondu à ma question : VBO vs Irrlicht, lequel l'emporterait selon toi ?

[Kannagi]

Je m'attendais à avoir un meilleur résultat avec un moteur graphique, je ne comprends pas pourquoi je constate le contraire.
VBO vs Irrlicht, lequel l'emporterait selon toi ?

Ben d'un coté les moteurs graphiques s'il sont beau , c'est surtout parce qu'ils sont de plus en plus capable de bien gérer la lumière et dans ton code/affichage tu n'en fait aucun
Tu pourrais utilise Unreal Engine que t'aurai pas une amélioration significative de ton rendu (et je vais te dire un 'secret' l’œil humain est plus sensible a la lumière que a la couleur )

"VBO vs Irrlich" Pour moi ça n'a aucun sens parce qu''il est fort probable que Irrlicht utilise des VBO en interne.
(Et peut être qu'il utilise DirectX donc sur Windows DirectX a toujours était plus rapide que OpenGL )

[KevinduC]

Ok. Je vais voir ce que ça donne avec un éclairage alors.

"VBO vs Irrlicht", je veux dire par là : Quelle serait selon toi la meilleure solution entre OpenGL seul avec disons 100 VBOs dans un frame et 100 noeuds de scène dans un frame avec Irrlicht ?

[Mat.M]

D'accord et comment je fais pour mes projets qui nécessitent des maps lourdes ? Je laisse tomber ? J'obtenais un meilleur résultat avec OpenGL 2.1

essayer de regarder dans le code source de Irrlicht mais l'optimisation & hiérarchie des objets de l'imagerie doit certainement être bloquée.
Pour ce qui est de récupérer la résolution du bureau rien dans la documentation ?

Ce dernier ne supporte pas plus de 140 000 vertices ; au-delà, il affiche un beau message d'erreur : "Too many vertices for 16bit index type". Je suis déçu, moi qui m'attendait à résoudre mes problèmes de map lourde avec des moteurs graphiques (Irrlicht utilise ici la version 4.3 de OpenGL). Finalement ce moteur ne semble pas valoir grand-chose ...

la solution est : soit d'aller bidouiller dans le code source de Irrlicht et tout recompiler les bibliothèques et dll mais bon courage
Parce que si tu modifies quelque chose dans le code source ça risque d'avoir des répercussions dans tout le reste du code et cela risque de le rendre bancal.

Soit de programmer directement avec Open GL version X et là tu fais ce que tu veux.

C'est la raison pour laquelle je ne suis pas trop fana d'utiliser des "moteurs de jeu" ou de rendu graphique, je préfère me cogner directement à Direct 3D ou Open GL

[Kannagi]

Je ne comprend pas meilleurs solution par rapport à quoi ? utilisation ? performance ? autre ?

[Mat.M]

Imaginons que je décompose ma map en plusieurs noeuds de scène, sachant que je peux faire la même chose avec les VBO sous OpenGL 2.1, quelle est la meilleure solution d'après toi ? Irrlicht ou les VBO ?

au vu des captures d'écran le projet dans lequel tu est lancé semble être un simulateur de train.
Donc si tu veux simuler un train en 3d là il faut adopter des stratégies d'optimisation et hierarchie spatiale ( en écrivant cela je suppose ne rien t'apprendre et tu dois le savoir ) pour éviter d'afficher trop de polygones.
Or Irrlicht est plutôt orienté jeux genre FPS
Après c'est certain comme l'affirme Kannagi il faut jouer sur les lumières pour avoir des contrastes.

[KevinduC]

Je ne comprend pas meilleurs solution par rapport à quoi ? utilisation ? performance ? autre ?

Plutôt performance.

au vu des captures d'écran le projet dans lequel tu est lancé semble être un simulateur de train.
Donc si tu veux simuler un train en 3d là il faut adopter des stratégies d'optimisation et hierarchie spatiale ( en écrivant cela je suppose ne rien t'apprendre et tu dois le savoir ) pour éviter d'afficher trop de polygones.

Bien vu, un simulateur de conduite de TGV ^^ Je ne vois pas trop ce que tu veux dire, tu parles de décomposer la map en noeuds de scène comme je le disais (Plutôt que de tout faire rentrer dans un seul noeud) ?

[KevinduC]

Kannagi, il n'y a pas que l'éclairage : Regarde bien l'aspect des traverses et des poteaux de caténaire sur les deux captures d'écran.

[Kannagi]

Plutôt performance.

Je ne connais pas Irrlicht , après vu que tu utilise OpenGL 2.1 certaine fonction sont loin d’être 'rapide' par exemple gltraslatef/glrotatef/gltranslatef , si tu les utilise 1000 fois , il est probable que Irrlicht fait mieux.
De même comme je l'ai dit s'il utilise DirectX , il sera beaucoup plus rapide que OpenGL et même entre OpenGL 2.1 et 4.2 y'a de grosse différence , notamment les Vertex Array Object qui permettent une bonne optimisation.
De plus je rajouterai que tu dois sûrement faire l'opération viewModel*viewProjection coté GPU est plutôt une mauvaise chose (vu que si tu as 140 000 vertices , tu le fera 140 000 fois ) alors que si tu le fait coté CPU ben tu le fera qu'une fois (enfin tu le fera x fois le nombre d'objet).

Kannagi, il n'y a pas que l'éclairage : Regarde bien l'aspect des traverses et des poteaux de caténaire sur les deux captures d'écran.

Je te l'ai dit que la seule différence que je vois entre les deux étant un probleme de contraste , pour les poteaux c'est surtout l'impression qu'ils n'ont pas de textures/couleurs.

Apres si Irrlicht te convient pas change , utilise Ogre3d par exemple

[KevinduC]

De plus je rajouterai que tu dois sûrement faire l'opération viewModel*viewProjection coté GPU est plutôt une mauvaise chose (vu que si tu as 140 000 vertices , tu le fera 140 000 fois ) alors que si tu le fait coté CPU ben tu le fera qu'une fois (enfin tu le fera x fois le nombre d'objet).

Je ne sais pas, c'est Irrlicht qui répartie les tâches entre CPU et GPU si je ne m'abuse.

Apres si Irrlicht te convient pas change , utilise Ogre3d par exemple

Je vais d'abord voir si ma solution consistant à décomposer la map en noeuds de scène fonctionne. Jusqu'à présent Irrlicht ne m'a pas déçu bien au contraire : Chargement de meshs (Animés ou pas) via des fichiers .x, .3ds, .md2, .obj ..., générateur de particules intégré, gestion éclairage plus aisé qu'avec OpenGL (Et puis c'est un bon moyen de travailler le C++). Ce serait dommage de s'arrêter en si bon chemin.

[Mat.M]

Bien vu, un simulateur de conduite de TGV ^^ Je ne vois pas trop ce que tu veux dire, tu parles de décomposer la map en noeuds de scène comme je le disais (Plutôt que de tout faire rentrer dans un seul noeud) ?

oui c'est cela même.
Bonne chance pour ce projet qui a l'air d'être intéressant.

[KevinduC]

Bonne chance pour ce projet qui a l'air d'être intéressant

Merci. Pour te dire à la base j'étais sous OpenGL 2.1 à coups de glBegin() et glEnd(), c'était rapidement devenu lent ^^