+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 25 sur 25
  1. #21
    Inactif


    Homme Profil pro
    Inscrit en
    novembre 2008
    Messages
    5 308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 308
    Points : 15 143
    Points
    15 143

    Par défaut

    Citation Envoyé par oxyde356 Voir le message
    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)

  2. #22
    Membre Expert Avatar de oxyde356
    Homme Profil pro
    Ingénieur Recherche Imagerie
    Inscrit en
    février 2006
    Messages
    798
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Recherche Imagerie

    Informations forums :
    Inscription : février 2006
    Messages : 798
    Points : 1 023
    Points
    1 023

    Par défaut

    Citation Envoyé par gbdivers Voir le message
    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 )

    Citation Envoyé par gbdivers Voir le message
    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

    Citation Envoyé par gbdivers Voir le message
    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...
    Je ne vois vraiment pas ce qui te fais dire ça, onUpdate() et onRender() sont des fonctions membres et partagent des données communes.

    Citation Envoyé par gbdivers Voir le message
    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.

  3. #23
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 973
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 973
    Points : 13 635
    Points
    13 635

    Par défaut

    Citation Envoyé par oxyde356 Voir le message
    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.
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  4. #24
    Membre expérimenté Avatar de TNT89
    Inscrit en
    juillet 2007
    Messages
    358
    Détails du profil
    Informations personnelles :
    Âge : 25

    Informations forums :
    Inscription : juillet 2007
    Messages : 358
    Points : 573
    Points
    573

    Par défaut

    Citation Envoyé par oxyde356 Voir le message
    @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...

    Citation 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)...

  5. #25
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 973
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 973
    Points : 13 635
    Points
    13 635

    Par défaut

    Citation Envoyé par TNT89 Voir le message
    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
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •