Moteur 3D gratuit Qt/OpenGL (astrophysique)

Bonjour à tous.

Je cherche actuellement à développer une appli scientifique/grand public de visualisation 3D. Je cherche à mettre la main sur un moteur 3D qui réponde aux critères suivants :
- gratuit
- basé sur OpenGL
- maintenu/updaté
- très important : facile à installer/compiler sur Windows et Linux
- le but visé est l'intégration dans un QGLWidget (Qt)
- permettant des zooms à des échelles très grandes (typiquement facteur 10^6 entre l'échelle la plus grande et la plus petite)

Je n'ai pas besoin d'avoir un très bon rendu de "modèles", par contre je cherche quelque chose qui permette de faire des choses sympa avec l'éclairage/brouillard/gaz.

Le moteur idéal serait un espèce d'hybride entre celui de Google Earth et celui de Eve Online...

Quel moteur serait selon vous le plus adapté ?

Merci beaucoup :ccool:

Bonjour,

Citation:

---

Envoyé par Kaluza

Je cherche à mettre la main sur un moteur 3D qui réponde aux critères suivants :
- gratuit
- basé sur OpenGL
- maintenu/updaté
- très important : facile à installer/compiler sur Windows et Linux
- le but visé est l'intégration dans un QGLWidget (Qt)
- permettant des zooms à des échelles très grandes (typiquement facteur 10^6 entre l'échelle la plus grande et la plus petite)

---

Alors moi je ne vais pas etre objectif hein, mais je peux te parler d'Open Scene Graph qui regroupe tous ces avantages.
L'integration Qt est dejà fournie dans les examples.

Citation:

---

Envoyé par Kaluza

Je n'ai pas besoin d'avoir un très bon rendu de "modèles", par contre je cherche quelque chose qui permette de faire des choses sympa avec l'éclairage/brouillard/gaz.

---

Par contre a part le fog et la gestion des 8 lumieres de base, je ne sais pas trop quelles sont les possibilités d'OSG sur ce point...

Citation:

---

Envoyé par Kaluza

Le moteur idéal serait un espèce d'hybride entre celui de Google Earth et celui de Eve Online...

---

Peux tu être plus précis, parce que dans un cas l'application tourne en temps interactif et dans l'autre cas en temps réel, et Qt et le temps réel ne font pas bon ménage.

Bonjour,

OGRE répond à tous les critères donnés. Gratuit, open source, DirectX ou OpenGL au choix, facile à intégrer dans Qt (dans un QGLWidget ou plus récemment dans QML - voir qmlogre). De même, je propose OGRE parce que je le connais bien.

Citation:

---

Envoyé par oxyde356

Qt et le temps réel ne font pas bon ménage.

---

Qu'entends-tu par là exactement ?

J'entends par là que les performances sont loin d'être au rendez-vous.

J'avais pensé à OGRE aussi, mais je ne sais pas s'il gère bien les gros facteurs de zoom... Par contre, il sais très bien gérer les très grosses scène (type simulateur de vol) :ccool:

Citation:

---

Envoyé par oxyde356

J'entends par là que les performances sont loin d'être au rendez-vous.

---

???
Par rapport à quelles critère?
http://labs.qt.nokia.com/2009/07/30/three-new-babies/
http://qt.nokia.com/about/news/autod...t-even-better/

Et bien en faisant une application minimaliste qui ne fait qu'ouvrir une fenêtre opengl et la gérer en temps réel où dedans il y a une scène pas forcément complexe et bien les performances (temps de rendu d'une scène en comptant bien entendu la gestion de la fenêtre, des messages par qt etc...) sont vraiment mauvaises par rapport à de l'api windows/mfc, sdl, glut, sfml ... (vsync désactivée bien entendu), suffit de faire un petit benchmark ça se vérifie vite et c'est bien dommage, Qt est de loin le framework le mieux conçu que je connaisse (avec GLM mais ça c'est juste une lib :P).
D'ailleurs il me semble que dans les nombreux samples livrés avec Qt il n'y en a pas un seul en temps réel, il n'y a que de l'intéractif (réaction à un évènement) bref ce pourquoi Qt a été conçu.

En te basant sur QGlWidget? sur les dernières version de Qt?
L'eventloop principale peut prendre un certain temps mais de là à tous plomber ça m'étonne. Je voie mal Maya être passé à Qt si c'était autant le cas.

Sinon, pour Qt 4.8 ils ont prévue du multi thread :
http://labs.qt.nokia.com/2011/06/03/...opengl-in-4-8/

Oui QGLWidget et j'avais dl la dernière version il y a même pas deux mois. Je ne m'étais pas basé sur la technique du timer pour appeler l'update de ma scène, je l'appelé explicitement dès qu'il y avait de l'idle (comme dans les autres API quoi).
Je n'ai moi même pas compris comment ça se fait que ça plombé autant les perfs (genre dans les 20% si je me souviens bien), surement les signaux/slots qui bouffent beaucoup (rien qu'à voir ceux de boost ça fait mal :/). Maya j'imagine que ce n'est pas du temps réel mais du temps interactif, et vu le confort qu'apporte Qt j'imagine que dans leur cas ça vaut le coup.

Je travaille sur une application critique OpenGL/QT en ce moment et je ne rencontre pas ce problème...
J'ai testé il y a un an une application Glut contre une application QT et je n'avais pas remarqué de différence non plus...

Tu gères ta scène comment? Avec un moteur ou à la "main"? Sans le rendu direct?

Citation:

---

Envoyé par oxyde356

je l'appelé explicitement dès qu'il y avait de l'idle (comme dans les autres API quoi).

---

C'est à dire ?

Citation:

---

Envoyé par TNT89

Je travaille sur une application critique OpenGL/QT en ce moment et je ne rencontre pas ce problème...
J'ai testé il y a un an une application Glut contre une application QT et je n'avais pas remarqué de différence non plus...

---

Et bien j'aimerais bien savoir comment ! Après avoir fais plusieurs bench j'avais choisis SDL qui affiché les meilleurs performances et parce que ces autres caractéristiques me convenaient bien mais si je me suis trompé et que Qt n'a pas à rougir niveau perf je fonce dedans. Mais à ce jour je n'ai pas trouvé de bon exemple en temps réel pour pc qui visait les perfs et qui montré que Qt savait gérer ce genre de choses.

Citation:

---

Envoyé par TNT89

Tu gères ta scène comment? Avec un moteur ou à la "main"? Sans le rendu direct?

---

Pour le bench c'était vraiment à la main (un petit scene graph et du gl pipeline fixe) mais le but après c'est d'y intégrer mon moteur. Qu'est ce que tu entend par rendu direct ? ça peut vouloir dire tellement de choses :P

Citation:

---

Envoyé par yan

C'est à dire ?

---

Je dois t'avouer que je me souviens plus exactement mais en gros si je me souviens bien il y a deux techniques, une basé sur un timer qui appelle la fonction d'update (je ne l'ai pas implémenté), et une autre qui consistait à appelé la fonction d'update je ne sais plus où dans une fonction qui était appelé à chaque fois que la boucle des messages était finit en gros, comme dans les autres API quoi.

Dans tous les cas si vous avez des samples ou tutos sur Qt et le temps réel je suis preneur, n'hésitez pas !!!

@TNT89 : quand tu parle d'application temps réel critique tu veux dire que ton application doit répondre le plus vite possible à un instant 't' précis ou plutôt elle doit pouvoir faire le plus de cycle possible comme dans le cadre d'un jeu ?

Citation:

---

Envoyé par oxyde356

Je dois t'avouer que je me souviens plus exactement mais en gros si je me souviens bien il y a deux techniques, une basé sur un timer qui appelle la fonction d'update (je ne l'ai pas implémenté), et une autre qui consistait à appelé la fonction d'update je ne sais plus où dans une fonction qui était appelé à chaque fois que la boucle des messages était finit en gros, comme dans les autres API quoi.

---

Tu as peut être fait un truc comme

Code:

---

1 2 3 4 5

while(true) { ... QApplication::processevent(); }

---

qui est tout simplement une boucle infinie qui va prendre tout le cpu pour rien.

Citation:

---

Dans tous les cas si vous avez des samples ou tutos sur Qt et le temps réel je suis preneur, n'hésitez pas !!!

---

les démo de Qt OpenGl ?

Pour revenir à la question de base, tu peux regarder Coin3D (OpenInventor) et
glc_lib

Citation:

---

Envoyé par yan

Tu as peut être fait un truc comme

Code:

---

1 2 3 4 5

while(true) { ... QApplication::processevent(); }

---

qui est tout simplement une boucle infinie qui va prendre tout le cpu pour rien.

---

Non quand même >< j'esseyerai de retrouver dès que j'aurais un peu de temps (autant que tu mette ta solution non je pourrais te dire si c'est ce que j'ai fais)

Citation:

---

Envoyé par yan

les démo de Qt OpenGl ?

---

Il ne me semble pas que les démos qt opengl soient en temps réel, l'affichage ne se fait que quand un évenement est détecté.

Citation:

---

Envoyé par oxyde356

Il ne me semble pas que les démos qt opengl soient en temps réel, l'affichage ne se fait que quand un évenement est détecté.

---

C'est quoi pour toi du temps réel?

Eh bien quand les animations, les actions, réagissent visiblement à la même vitesse que dans le monde réel :roll: Hors pour simuler des interactions complexes, mécanique des fluides, etc. il peut-être difficile de rester temps réel, ou sinon les approximations d'intégrales vont en pâtir, du coup si on peut éviter de perdre de précieuses ms à cause d'un framework peut-être pas conçu pour ce genre de situation c'est toujours mieux.
Ma définition te convient-elle ?

Citation:

---

Envoyé par oxyde356

Eh bien quand les animations, les actions, réagissent visiblement à la même vitesse que dans le monde réel :roll:

---

Donc un niveau de FPS assez élevé pour que les animation reste fluide pour l'oeil.

Citation:

---

Envoyé par oxyde356

Hors pour simuler des interactions complexes, mécanique des fluides, etc. il peut-être difficile de rester temps réel, ou sinon les approximations d'intégrales vont en pâtir, du coup si on peut éviter de perdre de précieuses ms à cause d'un framework peut-être pas conçu pour ce genre de situation c'est toujours mieux.

---

C'est surtout un problème d'optimisation et de parallélisme.
Qt à la base ne fait qu’exécuter une eventloop. Ce que tu fait avec SDL, MFC ou autre avec une boucle. Regarde bien les exemples fournient par Qt, il y en as plusieurs qui correspondent à ta définition de "temps réelle".


Si tu retrouve ton bench, on trouvera peut être une explication.

Les exemples "temps réel" livrés avec Qt utilisent un QTimerEvent pour déclencher l'update. Dans l'exemple il fixe l'intervalle à 20ms. Dans la doc ils disent que si l'on met cet intervalle à 0ms l'action est lancé dès que la pile d'évènement est vide mais dans un même temps ils disent que la précision sur la plupart des plateformes est de 20ms. Cette précision intervient quand l'intervalle est > 0 ou bien même quand elle est égal à 0 ?
Dans tous les cas ça me redonne envie de bencher histoire d'être sûr ^^

J'ai retrouvé mon Bench, donc je n'utilisais pas de QTimerEvent je faisais ça :

Code:

---

1 2 3 4 5 6 7

void GLWidget::paintGL() { onUpdate(); // fonction membre perso onRender(); // fonction membre perso   update(); // QWidget::update() }

---

En gros je mets à jour ma scène puis j'appelle la méthode update qui ajoute un event à la pile des events pour dire que le qwidget doit être remis à jour (une boucle de jeu quoi, traitement des events puis mis à jour de la scène et on recommence). So, what's wrong ? ^^