Moteur 3D gratuit Qt/OpenGL (astrophysique)

[gbdivers]

Envoyé par oxyde356

Eh bien quand les animations, les actions, réagissent visiblement à la même vitesse que dans le monde réel 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 ?

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 ?

Je comprend ton idée mais ça me pose problème

Diminuer l'intervalle à moins de 20 ms (50 FPS) n'a aucun intérêt puisque de toute façon, on ne percevra pas les images supplémentaires (en gros. on peut en effet augmenter un peu le FPS pour la qualité de rendu des animations rapides dans les jeux mais aucun intérêt non plus de monter à 1000 FPS).

Pour les calculs "temps réels" selon ta définition, dans le domaine scientifique, on privilègera la justesse des résultats. Et si le calcul ne peux pas être fait en temps réel, on changera la base de temps tout simplement. Et si on veut du temps réel quand même, on ne fera que les calculs en temps réel, pas l'affichage de toutes images (puisque le résultat ne sera pas visualisable).

Pour être concret, si tu veux étudier un phénomène d'écoulement qui dure 1/2 seconde avec un intervalle de temps de 5 µs, tu n'as aucun intérêt à afficher 100000 images en 1/2 seconde.

Code :

1
2
3
4
5
6
7
void GLWidget::paintGL()
{
	onUpdate(); // fonction membre perso
	onRender(); // fonction membre perso
 
	update(); // QWidget::update()
}

En voyant ça, j'ai l'impression que tu fais des calculs et du transferts de données vers le GPU à chaque rendu... A priori, le coût de la surcouche Qt dans ce cas (à voir le code de tes 2 fonctions membres) doit être vraiment négligeable par rapport au reste.


Pour revenir au problème Qt : celui-ci ne prend en charge que la partie CPU de l'application (events, boucles, signaux/slots, etc.) Si le programme est bien conçu, la totalité du rendu sera réalisé par le GPU et le coût apporté par Qt sera minime. Et dans le pire des cas, il faudra threader la partie QtOpenGL (ce qui est déjà possible sans attendre Qt 4.8... mais pas simple)

Pour en revenir à la question initiale, Qt peut tout à fait être utilisé pour des animations "scientifiques" mais par contre, ce n'est pas un moteur. Tu peux aussi regarder du côté de Qt3D (un nouveau module Qt en cours de dev qui ajoute beaucoup de choses aux fonctionnalités de base offerte par QtOpenGL)

[oxyde356]

Envoyé par gbdivers

Je comprend ton idée mais ça me pose problème

Diminuer l'intervalle à moins de 20 ms (50 FPS) n'a aucun intérêt puisque de toute façon, on ne percevra pas les images supplémentaires (en gros. on peut en effet augmenter un peu le FPS pour la qualité de rendu des animations rapides dans les jeux mais aucun intérêt non plus de monter à 1000 FPS).

L'intérêt ne se situe pas au niveau du rafraîchissement de l'affichage en soit (qui lui peut être asynchrone par rapport à la simulation d'ailleurs) mais de la mise à jour de la simulation (physique par exemple, avoir des petits intervalles c'est critique quand on fait des approximations d'intégrales )

Envoyé par gbdivers

Pour les calculs "temps réels" selon ta définition, dans le domaine scientifique, on privilègera la justesse des résultats.

J'ai tellement bouffé le topic de Kaluza que j'en avais oublié que c'était pour du scientifique

Envoyé par gbdivers

Code :

En voyant ça, j'ai l'impression que tu fais des calculs et du transferts de données vers le GPU à chaque rendu...

Je ne vois vraiment pas ce qui te fais dire ça, onUpdate() et onRender() sont des fonctions membres et partagent des données communes.

Envoyé par gbdivers

Pour revenir au problème Qt : celui-ci ne prend en charge que la partie CPU de l'application (events, boucles, signaux/slots, etc.) Si le programme est bien conçu, la totalité du rendu sera réalisé par le GPU et le coût apporté par Qt sera minime.

Oui sauf que je ne fais pas que du rendu, dans mon cas je dois gérer une scène très lourde. Là justement j'effectue un parcours de scène sur 10000 noeuds répartie dans un graphe de scène de profondeurs 5 et équilibré (pas cache friendly du tout [à la base c'était un benchmark de graphe de scène entre Object Oriented Design et Data Oriented Design]) du coup le CPU morfle pas mal.

C'est quand même dommage qu'il n'y est pas un gros bench comparatif des API comportant une gestion de fenêtrage et pouvant incorporer OpenGL. SDL, GLUT, SFML, Qt, API Windows, etc.

[yan]

Envoyé par oxyde356

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.

C'est un problème de plateforme et non de Qt. Ca veux dire qu'un intervalle < 20 ms ne sera pas précis sur la plupart des OS.
Et si tu m'est 0 la méthode sera appelé dés que l'eventloop sera vide et il n'y aura pas de "pause".

Code :

1
2
3
4
5
6
7
void GLWidget::paintGL()
{
	onUpdate(); // fonction membre perso
	onRender(); // fonction membre perso
 
	update(); // QWidget::update()
}

Tu schedule la mise à jour de la widget mais dans un "temps widget" qui n'est pas immédiat.

En principe, si tu veux fait un rafraîchissement "au plus vite" il faudrait plutôt faire un timer à 0 qui appel updateGl.

[TNT89]

Envoyé par oxyde356

@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 ?

Les deux...

Envoyé par gbdivers

Diminuer l'intervalle à moins de 20 ms (50 FPS) n'a aucun intérêt puisque de toute façon, on ne percevra pas les images supplémentaires (en gros. on peut en effet augmenter un peu le FPS pour la qualité de rendu des animations rapides dans les jeux mais aucun intérêt non plus de monter à 1000 FPS).

Là, par contre je dis non... L'oeil humain a une limite mais elle est très haute, dépend de la scène, etc... (vous avez déjà vu un flash d'appareil photo, et pourtant il dure moins de 20ms)...

[yan]

Envoyé par TNT89

Les deux...



Là, par contre je dis non... L'oeil humain a une limite mais elle est très haute, dépend de la scène, etc... (vous avez déjà vu un flash d'appareil photo, et pourtant il dure moins de 20ms)...

Y avais un super article donnée sur le forum y as quelque jours, mais je ne le retrouve pas
[edit]
ha ben voila :
http://www.developpez.net/forums/d10...e/#post5953032