Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 22
  1. #1
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut Stockage de la géométrie

    Bonjour

    Petite question concernant le stockage de la géométrie dans une classe Mesh.
    J'ai vu différentes façon de faire. Certains moteur de rendu stockent les informations liées aux sommets (position, couleur, normale...) ainsi que les indices dans une classe Mesh via des conteneurs (std::vector) du genre
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    class Mesh
    {
    public:
        Mesh();
        ~Mesh();
        ...
    private:
        std::vector<Vertex> m_vVertices;
        std::vector<int> m_vIndices;
    };
    Et d'autres vont plutôt stocker directement des buffers du style
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    class Mesh
    {
    public:
        Mesh();
        ~Mesh();
        ...
    private:
        VertxBuffer* m_pVertexBuffer;
        IndexBuffer* m_pIndexBuffer;
    };
    Quelles différences cela fait-il exactement ?

    Kromagg
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  2. #2
    screetch
    Invité(e)

    Par défaut

    Ben ca depend de la classe VertexBuffer. En theorie c'est peut etre seulement une classe similaire a vector.

    mais je pense que c'est une classe qui encapsule des donnees GPU et la difference est donc que les donnees du mesh seraient stockees sur la memoire du GPU au lieu de la memoire du CPU.

  3. #3
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par screetch Voir le message
    Ben ca depend de la classe VertexBuffer. En theorie c'est peut etre seulement une classe similaire a vector.

    mais je pense que c'est une classe qui encapsule des donnees GPU et la difference est donc que les donnees du mesh seraient stockees sur la memoire du GPU au lieu de la memoire du CPU.
    Dans cet exemple il s'agit bien de données stockés côté GPU (VBO OpenGL par exemple). Quelle différence cela fait-il de stocker les données du mesh directement en mémoire GPU au lieu de la mémoire CPU ? Est-ce que c'est plus optimisé pour les transferts CPU/GPU ?
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  4. #4
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Bonjour,

    Comme le dit screetch, on ne connait pas vraiment ce que fait la classe VertexBuffer.

    Sinon, si seulement les ID des buffers coté GPU sont gardés, cela posera une contrainte supplémentaire. En effet, il sera un peu plus dur de faire changer la mesh (que ce soit couleur, tex coord ou positions des points) facilement, si on ne garde pas toutes les données coté CPU. En effet, il n'est pas possible de lire les données du mesh stockés sur le GPU.

    Ce que je veux dire par là, c'est que l'on est presque tout le temps obligé de garder les données de la mesh coté CPU (sauf si la mesh est statique et que l'on sait que l'on ne la mettra pas à jour et donc, qu'elle restera inchangée coté GPU).
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  5. #5
    screetch
    Invité(e)

    Par défaut

    Citation Envoyé par Kromagg Voir le message
    Est-ce que c'est plus optimisé pour les transferts CPU/GPU ?
    c'est plutot le contraire; ce qui est optimise c'est la rapidite de l'acces du GPU a ces donnees de vertex, donc c'est mieux pour le rendu
    en revanche, ces donnees etant sur le CPU, chaque fois que tu veux les changer (en gros) elles sont rapatriees sur la memoire du CPU avant d'etre modifiees puis renvoyees au GPU, autant dire que c'est long.

    en general il y a des mecanismes de double ou triple buffer qui sont ajoutes alors ce qui se passe precisement derriere l'interface VertexBuffer est tres difficile a comprendre.

  6. #6
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par LittleWhite Voir le message
    En effet, il sera un peu plus dur de faire changer la mesh (que ce soit couleur, tex coord ou positions des points) facilement, si on ne garde pas toutes les données coté CPU. En effet, il n'est pas possible de lire les données du mesh stockés sur le GPU.
    Il me semblait pourtant que les fonctions comme glMapBuffer/glUnmapBuffer (avec flag GL_READ_ONLY) permettaient de récupérer le contenu de nos buffers et donc les données du mesh stockées sur le GPU.
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  7. #7
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Oui en effet, j'avais oublié car je n'ai pas l'habitude de le faire (et dire que je me demandais comment faisait gDEBugger ).

    Je pense que cela apporte quelques difficultés en plus, dans le sens, il faut savoir combien de données doivent être lues (donc la taille a du être conservée quelque part) et puis comme a pu le dire screetch, l'échange GPU <-> CPU a tendance à être lent, donc à éviter (éviter, dans le sens, en faire le moins possible).
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  8. #8
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Ok maintenant en rapport avec tout ça je vais prendre l'exemple de l'animation skeletal. Cette technique peut être implémentée de deux façon :
    - sur CPU où tout les calculs sont effectués (transformations de bones et déplacement des sommets)
    - sur GPU où la mise à jour des sommets est effectué via un vertex shader auquel on envoi les matrices de transformation du/des bones ainsi que les poids associés pour un sommet données.

    Dans mon premier exemple comme les calculs sont effectués côté CPU je dois mettre à jour les données stockés sur le GPU (sommets). Dans cet exemple on voit bien l'utilité de stocker les sommets côtés CPU car en effet nous n'avons pas besoin de récupérer sur le CPU les données du GPU, de les mettre à jour puis de les renvoyer au GPU.

    Dans mon second exemple les calculs sont effectués côté GPU, donc la je dois récupérer mes données stockées sur le GPU pour mettre à jour celle qui sont sur le CPU.

    Dans ces deux exemples est-ce que les transferts CPU/GPU sont équivalents en terme de performances ?
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  9. #9
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Dans le second exemple, nous ne sommes pas obligés de remonter les données au CPU. Je veux dire, que si le CPU veut continuer la transformation, il continue à modifier la matrice, le GPU continuera la transformation en application. (en fait la transformation coté GPU n'est pas du tout sauvegardé (les positions transformés sont calculés dans le vertex shader puis passés à travers le pipeline, mais ne sont pas mis en mémoire). Ainsi, il n'est même pas possible de récupérer les points transformés pour les redonner au CPU)
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  10. #10
    screetch
    Invité(e)

    Par défaut

    Il y a plusieurs types de vertex buffer qui sont organises differement selon ce que tu veux faire avec.
    Tu peux specifier comment tu vas utiliser les buffer lors de leur construction et il y a en gros 3 modes (je soupconnes que la plupart des drivers n'implementent que deux, voire un seul...)
    - read only, envoyes au GPU une fois et ne changent jamais
    la plupart des meshs sont comme ca
    - read-write, envoyes une fois de temps en temps au GPU pour rafraichissement
    par exemple, la vegetation est comme ca; on stocke les mesh d'herbe dans un buffer et lorsque la camera bouge et change de region, on ajoute des donnees dans le buffer; mais on en ajoute pas toute les frame en general
    - read-write, envoyes au GPU une fois par frame; il y a quelques donnees comme ca, qui sont generees sur le CPU a chaque frame, pour etre franc la j'ai pas d'exemple mais je crois que c'est legitime


    en revanche, on ne lit (quasiment) jamais les donnees du GPU sur le CPU, ca se passe presque toujours dans la direction CPU->GPU.


    dans ton exemple d'animation skeletal, tu envoies les donnees au GPU une fois (le squelette en question, dans une pose determinee) et le vertex shader se charge de transformer les bones a chaque frame selon les poses que tu envoies au GPU chaque frame. Donc dans ce cas, les VertexBuffer sont constants, mais il y a un Buffer (soit un groupe de variables Uniform, soit, encore mieux, un UniformBufferObject) qui est envoye au GPU toute les frame. C'est le cas optimal en general car le VertexBuffer est bien plus gros que le UniformBuffer, et que le GPU calcule les transformations de bone plus vite que le CPU.

  11. #11
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par screetch Voir le message
    - read-write, envoyes au GPU une fois par frame; il y a quelques donnees comme ca, qui sont generees sur le CPU a chaque frame, pour etre franc la j'ai pas d'exemple mais je crois que c'est legitime
    La je pense que tu veux dire write-only ?

    Citation Envoyé par screetch Voir le message
    en revanche, on ne lit (quasiment) jamais les donnees du GPU sur le CPU, ca se passe presque toujours dans la direction CPU->GPU.
    Je ne suis pas sur d'avoir compris cette phrase. Tu veux dire que l'on transfert les données du CPU vers le GPU (write) mais que l'on ne lit quasiment jamais les données stockées sur le GPU depuis le CPU (read), c'est ça ?

    Concernant mon exemple d'animation squeletale, les sommets du mesh sont déplacés à chaque frame. Donc comment je fait si par exemple je veux mettre à jour la boîte englobante de mon mesh avec ces nouvelles données de sommet ? (calcul qui est effectué côté CPU quand je traverse mon graphe de scène)
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  12. #12
    screetch
    Invité(e)

    Par défaut

    Citation Envoyé par Kromagg Voir le message
    La je pense que tu veux dire write-only ?
    non, je crois que c'est plus facile si je dis:
    cas 1: read often, write once
    cas 2: read often, write sometimes
    cas 3: read often, write often
    les vertex buffer sont toujours lus tres souvent par la carte graphique



    Citation Envoyé par Kromagg Voir le message
    Je ne suis pas sur d'avoir compris cette phrase. Tu veux dire que l'on transfert les données du CPU vers le GPU (write) mais que l'on ne lit quasiment jamais les données stockées sur le GPU depuis le CPU (read), c'est ça ?
    tout a fait

    Citation Envoyé par Kromagg Voir le message
    Concernant mon exemple d'animation squeletale, les sommets du mesh sont déplacés à chaque frame. Donc comment je fait si par exemple je veux mettre à jour la boîte englobante de mon mesh avec ces nouvelles données de sommet ? (calcul qui est effectué côté CPU quand je traverse mon graphe de scène)
    je pense que c'est tres peu performant de transformer tous tes vertex sur le GPU puis de les transferer sur le CPU pour avoir une boite englobante. Le poin d'etranglement des applications c'est souvent le transfert de donnees, pas le calcul lui meme.

    Je verrais deux ou trois solutions:
    * une approximation ou on a une boite englobante trop grande qui est en gros la boite englobante maximale (on peut du coup la precalculer). Ce qui est souvent fait d'ailleurs, c'est de prendre la boite englobante du personnage non anime (souvent en position T) est la boite englobante maximale
    * on calcule la boite englobante en animant quelques vertex, pas tous; on a un calcul beaucoup plus rapide evidemment. par exemple, un vertex de la main, un vertex du coude, les pieds, les hanches et la tete, et hop on a une boite englobante. animer 5 vertex c'est pas comme animer le perso entier
    * on a une carte graphique evoluee et lorsqu'on transforme le vertex, on met a jour la bounding box sur le GPU et on transfere cette bounding box sur le CPU (c'est toujours couteux mais on est deja dans du plus acceptable)

    peut etre il y a des gens plus creatifs que moi pour resoudre ce probleme cependant
    moi je partirais sur la premiere solution, c'est souvent suffisant.

  13. #13
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par screetch Voir le message
    non, je crois que c'est plus facile si je dis:
    cas 1: read often, write once
    cas 2: read often, write sometimes
    cas 3: read often, write often
    les vertex buffer sont toujours lus tres souvent par la carte graphique
    D'accord donc il s'agit des politiques OpenGL quand on créé un VBO.

    Citation Envoyé par screetch Voir le message
    * on a une carte graphique evoluee et lorsqu'on transforme le vertex, on met a jour la bounding box sur le GPU et on transfere cette bounding box sur le CPU (c'est toujours couteux mais on est deja dans du plus acceptable)
    Et oui c'est une bonne idée, il s'agit ici de ne transférer que 2 sommets (24 octets) pour chaque mesh, je pense que c'est relativement acceptable.

    Citation Envoyé par screetch Voir le message
    peut etre il y a des gens plus creatifs que moi pour resoudre ce probleme cependant
    moi je partirais sur la premiere solution, c'est souvent suffisant.
    Ou alors on stocke directement la taille de la boîte englobante du mesh (pour chaque frame) dans le fichier mesh, comme c'est le cas pour les fichiers md5mesh de Doom 3 si je ne me trompe pas et puis on interpole côté CPU si nécessaire.
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  14. #14
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Pour les boites englobantes, je me disais que la mise à jour n'avait pas à être effectuée nécessairement à chaque frame. Je veux dire, il se peut que le moteur de collision ou la mise à jour du monde soit plus lent que le nombre d'images par FPS. Mais bon, cette hypothèse est un peu faiblarde pour dire que comme ça on a "plus de temps pour calculer les collisions".

    Sinon, on part d'une boite englobante qui est vraiment une boite englobante dans laquelle toutes les animations entrent (genre une grosse AABB/OBB classique).
    Ensuite, on peut avoir des boites englobantes par ensemble de membre (genre, jambe gauche, droite, torse, tête), auquel on appliquerai les transformations pour les membres correspondants (ainsi, là, on a que 5 transformations à faire).
    Ensuite, on peut faire un truc plus parfait ou l'on appliquera les matrices de chaque membre compris dans la sous section déterminée par le test précédent. Ainsi, on reste à un haut niveau de réalisme, tout en évitant de transformer toutes la mesh coté CPU.

    Et si vraiment on a besoin de l'optimisation, on utilise un système de cache qui permet une fois la boite de collision du test 3 calculée, de ne pas la recalculée.

    Enfin, c'était une proposition

    (Si on utilise le GPU pour calculer la boite passante, ça veut dire obligatoirement que l'on dépend d'une frame, pour faire nos tests de collisions ?)
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  15. #15
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Citation Envoyé par LittleWhite Voir le message
    Pour les boites englobantes, je me disais que la mise à jour n'avait pas à être effectuée nécessairement à chaque frame. Je veux dire, il se peut que le moteur de collision ou la mise à jour du monde soit plus lent que le nombre d'images par FPS. Mais bon, cette hypothèse est un peu faiblarde pour dire que comme ça on a "plus de temps pour calculer les collisions".
    C'est vrai que la mise à jour du moteur physique ne se fait pas à chaque frame. Je crois qu'en général cette mise à jour se fait à un temps fixe, par exemple toute les x milliseconds. D'ailleurs si je prend l'exemple de Unity3D, il y a une fonction FixedUpdate spécialement faite pour ça.
    Function FixedUpdate in Unity3D

    Citation Envoyé par LittleWhite Voir le message
    Ensuite, on peut faire un truc plus parfait ou l'on appliquera les matrices de chaque membre compris dans la sous section déterminée par le test précédent. Ainsi, on reste à un haut niveau de réalisme, tout en évitant de transformer toutes la mesh coté CPU.

    Et si vraiment on a besoin de l'optimisation, on utilise un système de cache qui permet une fois la boite de collision du test 3 calculée, de ne pas la recalculée.
    Je n'ai pas très bien compris ton raisonnement. Est-ce que tu pourrais détailler un petit peu plus ?

    Citation Envoyé par LittleWhite Voir le message
    (Si on utilise le GPU pour calculer la boite passante, ça veut dire obligatoirement que l'on dépend d'une frame, pour faire nos tests de collisions ?)
    Oui je pense que l'on dépend d'une frame. Comme le moteur physique n'est pas mise à jour toutes les x frames mais toutes les x milliseconds on peut se retrouver à faire des calculs de collisions sur une boite englobante calculée 2-3... N frames avant, mais est-ce que cela pose vraiment un problème, je ne suis pas sûr.
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  16. #16
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Je n'ai pas très bien compris ton raisonnement. Est-ce que tu pourrais détailler un petit peu plus ?
    Le concept du cache ? ou le truc jute avant.
    Enfin, bref, je vais essayer d'expliquer à nouveau.

    Pour faire une détection encore plus précise, il faudra appliquer la transformation sur chaque membre animable / animée. Les premiers tests permet de faire une première approximation généraliste, ce qui permettra d'éviter de tester tous les membres un par un, mais de tester que les membres qui sont concernées (un peut comme dans les hiérarchie de partitionnement d'espace).
    Ensuite, je parlais d'un système de cache. Car une fois que l'on arrive au membre à tester, il faut transformer tous les points (appliquer la matrice du mouvement, sur les points). Comme ceci peut être lourd, on va faire le calcul une fois et on gardera le résultat dans un cache afin de ne pas le recalculé une seconde fois, si en a besoin.
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  17. #17
    Membre actif Avatar de Kromagg
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2008
    Messages
    275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : août 2008
    Messages : 275
    Points : 170
    Points
    170

    Par défaut

    Je me demande également dans les jeux vidéo type FPS, est-ce qu'ils utilisent une boîte englobante générale ou est-ce qu'ils en ont une pour chaque partie du corps, ceci afin de faciliter les tests d'intersections lors des shoots ?
    C'est dans ses rêves que l'homme trouve la liberté cela fut, est et restera la vérité! (John Keating - Le cercle des poètes disparus)

  18. #18
    Responsable 2D/3D/Jeux

    Avatar de LittleWhite
    Homme Profil pro Alexandre Laurent
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    16 986
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexandre Laurent
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 16 986
    Points : 88 545
    Points
    88 545

    Par défaut

    Je pense qu'ils continuent d'utiliser les deux. La boite englobante, ça permet de faire des recherches de collision plus rapidement et les boites plus petites pour que cela soit plus précis. Et puis, ensuite une fois que l'on a eu la précision voulue, on peut faire un lancer de rayon (détection rayon / triangle) pour avoir une précision maximale.
    Vous souhaitez participer à la rubrique 2D / 3D / Jeux ? Contactez-moi
    La rubrique a aussi un blog !

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  19. #19
    screetch
    Invité(e)

    Par défaut

    pour la physique, il y a une boite englobante histoire de voir tres vite ou pas si il y a une collision possible ou pas.
    si une collision est possible, en general le personnage est modelise (en physique, pas en rendu) avec des cylindres; un gros cylindre pour le corps, un cylindre par membre et une sphere pour la tete. seuls ces cylindres sont animes.
    la detection de collision ne se fait pas souvent au triangle pres, car c'est trop couteux car il faut animer chaque triangle.

    la boite englobante est souvent calculee au large, car c'est seulement une optimisation. c'est dunc un compromis entre le calcul de l'update de la boite englobante, et le gain pour les tests de collisions evites.

  20. #20
    Expert Confirmé Sénior
    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    4 958
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 4 958
    Points : 7 141
    Points
    7 141

    Par défaut

    Citation Envoyé par Kromagg Voir le message

    Quelles différences cela fait-il exactement ?

    Kromagg
    Salut je conseillerais d'utiliser la solution avec des std::vector
    Si tu définis ceci
    VertxBuffer* m_pVertexBuffer;
    IndexBuffer* m_pIndexBuffer;
    1 tu est dépendant de l'API graphique...
    par exemple si tu utilises Direct3d comme l'API graphique change fréquemment tu seras obligé de réecrire du code.

    L'important c'est de faire des classes génériques de géométrie 3d.

    A ce moment-là il suffit d'appeler la méthode Dessine() ou Draw()d'une classe Video et là tu parcours les Indices et Vertices Buffer
    2-de toute façon à l'affichage dans le rendu des objets tu seras obligé constamment de verrouiller les VertexBuffer et IndexBuffer pour accéder à leur contenu et dessiner
    Parce que rien ne garantit que ces objets VB et IB aient une adresse mémoire constante,l'OS et la carte graphique peuvent très bien les déplacer en mémoire

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
  •