Discussion :

[LapinGarou]

bonjour bonjour...

J'ai des questions un peu "newbies", ou un peu pointues, à vous de voir

Pure C++ :
Le bit shifting est il toujours d'actualité sous C++ ? Est il plus rapide de faire un shift qu'une division ? (genre division par 256 ou >>8) Est ce toujours d'actualité ou bien avec les processeurs d'aujourd'hui cela est devenu inutile, comme les fixed points vs float...

OpenGL:
Comment marche la fonction glFrustrum? Je veux dire, vaut'il mieux l'utiliser ou me programmer mon propre frustum ? Sera-ce plus rapide ? (et que dire de gluPerspective ?)

Quel algo vous me conseillieriez pour l'affichage de heightmap ? RAOM, geomipmapping, Quadtree... ou bien rien, ça passe très bien suivant le nombre de polygones...

J'ai trouvé un algo qui utilise les fragment shaders pour l'occlusion des parties invisibles, mais cela ne va t'il pas me pomper de la bande passante pour l'affichage du reste ?

Rho làlà, que de questions... ça va peut être servir pour la FAQ qui sait ?

[Laurent Gomila]

Le bit shifting est il toujours d'actualité sous C++ ? Est il plus rapide de faire un shift qu'une division ? (genre division par 256 ou >>8) Est ce toujours d'actualité ou bien avec les processeurs d'aujourd'hui cela est devenu inutile, comme les fixed points vs float...

S'il s'agit d'une portion de code critique ça peut être intéressant, sinon ne te prends pas la tête avec ça. Il y a peu de chances que ce soit ce qui va ralentir ton moteur 3D. Et si les opérandes sont des constantes connues à la compilation, je pense que c'est le genre d'optimisation que le compilo peut effectuer assez facilement.

Comment marche la fonction glFrustrum? Je veux dire, vaut'il mieux l'utiliser ou me programmer mon propre frustum ? Sera-ce plus rapide ? (et que dire de gluPerspective ?)

Ces fonctions ne font que construire une matrice adéquate ; aucune raison de s'inquiéter de leur temps d'exécution. Et qu'est-ce qui te fait penser que tu pourrais en écrire une version plus rapide ?

Quel algo vous me conseillieriez pour l'affichage de heightmap ? RAOM, geomipmapping, Quadtree... ou bien rien, ça passe très bien suivant le nombre de polygones...

ROAM, geomipmaps, ... sauf cas très particulier, ces méthodes ne sont plus d'actualité vu la puissance de calcul du hardware actuel.
Quadtree, octree toujours utiliser une structure de partitionnement (voir FAQ 3D), c'est la base pour des performances correctes sur des grosses scènes.

J'ai trouvé un algo qui utilise les fragment shaders pour l'occlusion des parties invisibles, mais cela ne va t'il pas me pomper de la bande passante pour l'affichage du reste ?

Ca dépend de beaucoup de choses... Globalement l'occlusion culling est très couteux quoiqu'il arrive, il faut juste trouver la technique la plus adéquate pour chaque situation.

[mat.M]

bonjour bonjour...

J'ai des questions un peu "newbies", ou un peu pointues, à vous de voir

Pure C++ :
Le bit shifting est il toujours d'actualité sous C++ ? Est il plus rapide de faire un shift qu'une division ? (genre division par 256 ou >>8) Est ce toujours d'actualité ou bien avec les processeurs d'aujourd'hui cela est devenu inutile, comme les fixed points vs float...

Ouais je suis d'accord avec Loulou24 si tu veux optimiser en assembleur....
Mais maintenant les CPU font des calculs aisément en virgule flottante etc...
Faire un shift pour une grosse boucle ça peut être intéressant....

[LapinGarou]

Ok merci pour ces precisions.
Concernant glFrustum, c'est pour savoir si le clipping est déjà partie intégrante, ou bien si il faut que je code moi même le clipping, comme je le vois dans beaucoup de tutoriels en pdf...

Pour l'occlusion :
En fait, je cherche un algo qui me permette de ne pas calculer les triangles cachés sans passer par les quadtree ni rien de si compliqué (c'est pour un exposé, alors si je me noie dans le compliqué...) : j'en élimine avec le back face culling, mais par exemple: je suis au pied d'une montagne, derrière se trouve une colline. En mode WireFrame, je vois que des triangles de la collines sont rendus, alors qu'au rendu final texture, ils sont invisibles, cachés par ceux de la montange OpenGL affichant de zfar à znear j'en conclu.
Comparer les coordonnes ecran et tenant compte compte du z de chaque coin ou passer par un algo "painter" ?

[Laurent Gomila]

Concernant glFrustum, c'est pour savoir si le clipping est déjà partie intégrante, ou bien si il faut que je code moi même le clipping, comme je le vois dans beaucoup de tutoriels en pdf...

glFrustum ne fait que construire une matrice. Le clipping est bien entendu géré par le hardware.

En fait, je cherche un algo qui me permette de ne pas calculer les triangles cachés sans passer par les quadtree ni rien de si compliqué (c'est pour un exposé, alors si je me noie dans le compliqué...) : j'en élimine avec le back face culling, mais par exemple: je suis au pied d'une montagne, derrière se trouve une colline. En mode WireFrame, je vois que des triangles de la collines sont rendus, alors qu'au rendu final texture, ils sont invisibles, cachés par ceux de la montange OpenGL affichant de zfar à znear j'en conclu.
Comparer les coordonnes ecran et tenant compte compte du z de chaque coin ou passer par un algo "painter" ?

L'occlusion culling ce sera de toute façon compliqué. Voir la FAQ 3D à ce sujet.

[LapinGarou]

ok, donc si le clipping est hardware, je n'ai pas à m'en soucier, donc ils en parlent dans les tutoriaux seulement pour être exhaustif.
J'ai déjà lu les FAQ, mais les liens sur l'occlusion ne parlent que d'occlusion quand on a des arbres binaires, des quadtree, etc, il n'y a rien sur des idées d'algo. Je vais me le coder tout seul dans mon coin je crois bien
ou bien j'ai loupé quelque chose sur l'occlusion query ?

[Laurent Gomila]

Oui, tu as loupé la Q/R qui en parle dans la FAQ :
http://jeux.developpez.com/faq/3d/?p...LING_occlusion

Tu devrais également jeter un oeil aux autres Q/R de cette page, j'ai l'impression que tu mélanges un peu tout.

[shenron666]

ok, donc si le clipping est hardware, je n'ai pas à m'en soucier, donc ils en parlent dans les tutoriaux seulement pour être exhaustif.

Attention à ce que disent certains tutoriaux, parfois ils confondent "clipping" et "frustum culling" ou autre algo
- le "clipping" est géré en hardware par la carte mais intervient tardivement dans le pipeline
- le "frustum culling" sert à déterminer des portions de polygones qui ne sont pas dans le frustum de visibilité pour ne pas les envoyer inutilement et ce n'est pas géré en hardware

ps: on dit frustum, avec 1 seul R comme glFrustum
http://en.wikipedia.org/wiki/Frustum

[LeGreg]

Pure C++ :
Le bit shifting est il toujours d'actualité sous C++ ? Est il plus rapide de faire un shift qu'une division ? (genre division par 256 ou >>8) Est ce toujours d'actualité ou bien avec les processeurs d'aujourd'hui cela est devenu inutile, comme les fixed points vs float...

Ben réponse de normand. Si tu dois sacrifier beaucoup de généralité pour tout rapporter à des puissances de deux, alors tu es probablement perdant.

Combien de divisions tu fais par frame, est-ce que tu ne peux pas transformer tes divisions en multiplications ?
Est-ce que tu travailles en float ou en integer ? Si tu travailles en float il vaut mieux diviser que de faire la conversion float->int->float.

Un shift c'est rapide. Plus rapide qu'une division. Mais sans contexte cette information ne sert à rien..

OpenGL:
Comment marche la fonction glFrustrum? Je veux dire, vaut'il mieux l'utiliser ou me programmer mon propre frustum ? Sera-ce plus rapide ? (et que dire de gluPerspective ?)

Comme on dit, glFrustum et gluPerspective ça sert juste à mettre en place ta matrice de projection. Donc le faire toi-meme ça veut juste dire créer ta matrice à la main.. Rien de plus.

Quel algo vous me conseillieriez pour l'affichage de heightmap ? RAOM, geomipmapping, Quadtree... ou bien rien, ça passe très bien suivant le nombre de polygones...

Tout dépend de tes besoins.. En général les méthodes semi statiques marchent bien avec les hardware actuels. Par semi statiques on parle des méthodes qui ne modifient pas tous les sommets à chaque frame.

Pour les besoins avancés quelquechose comme les geometric clipmaps ?
http://research.microsoft.com/~hoppe/#geomclipmap

J'ai trouvé un algo qui utilise les fragment shaders pour l'occlusion des parties invisibles, mais cela ne va t'il pas me pomper de la bande passante pour l'affichage du reste ?

Vu le peu de détails que tu donnes, on peut difficilement deviner si cela va pomper de la bande passante ou pas

LeGreg

[LapinGarou]

Ok, vous confirmez ce que j'avais intuitivement compris à propos du Frustum.

Pour ma question sur l'occlusion, j'ai trouvé du code sur codesampler ici :
http://www.codesampler.com/oglsrc/og...cclusion_query
Je précise j'ai une Nvidia 6200, pas ATI, et pour le moment je me concentre sur le code nv, pas un truc qui marche sur tous pc. (je verrai ça plus tard).

Edit : J'ai pris un screenshot de ce qui m'embête dans mon programme : le rendu de triangles inutiles comme vous pouvez le voir. On grimpe une colline, mais les autres triangles derrières non éliminés pas le BFculling sont quand même affichés.

[shenron666]

On grimpe une colline, mais les autres triangles derrières non éliminés pas le BFculling sont quand même affichés.

Il y a l'utilisation d'un octree combiné à l'occlusion query qui peut t'aider dans ce cas
fais une recherche dans la faq sur les octree

[LapinGarou]

Justement, j'aimerai savoir si il y a un truc plus simple, ou si je suis obligé de m'y mettre.

[Ti-R]

Avec une heightmap, tu peux faire un truc de scioux pour gérer ton problème.

Ce n’est pas le truc forcément super simple à mettre en place.

En gros, c'est du traitement d'image de ta heightmap.
Tu sais ou se trouve les sommets de ta heighmap. Tu sais ou est la caméra, l'angle de la caméra. Avec un "simple" calcul de projection 3D vers 2D ensuite tu peux calculer suivant la hauteur de chaque sommet si le sommet suivant serra ou non dans le champ de la caméra, cela va éliminer tous les sommets non utile à ta vue. Première problème, cela va enlever plus de sommets que nécessaire, car certaines arrête vont disparaître, donc il faut re-parcourir l’image pour afficher un rang de 1 sommet connexe à chaque sommet affichable. Deuxième problème… c’est du traitement d’image, donc c’est assez lourd, et donc tu ne peux pas le faire à chaque frame.

Sinon Octree, sinon un ROAM, sinon regarde ce lien aussi http://www.vterrain.org/

[LapinGarou]

Tu as décris ce à quoi je pensais, mais j'ai abandonné quand je me suis vraiment penché sur le problème : trouver tous les vertex qui sont dans le frustum (là déjà c'est galère, faut tenir compte du clipping pour ceux qui sont sur les bords), calculer leur projection, et comparer par rapport à l'arrête la plus haute, etc... le etc en fait, c'est parce que j'ai la fumée qui sort des oreilles, je vais perdre plus de temps à coder ça qu'à comprendre ROAM ou les quadtree.