[Opengl] Texture disparait

Salut,

Lorsque je m'éloigne trop d'un mur que j'ai créée il disparait.

Vous me direz que c'est normal, mais là en fait je suis pas beaucoup éloigné quand il disparait.

Y a t'il un code à rajouté pour régler ça ???

Soit c'est un problème dû au mipmapping (problème que tu n'aurais pas eu si tu utilisais mon loader...enfin bref ^^), soit c'est la région de clipping qui n'est pas bien définie, regarde au niveau du dernier paramètre de gluPerspective, il correspond à la plus grande distance par rapport à la caméra que peut prendre un point tout en restant visible.

Si c'est pas ça, ça doit être le mipmapping, donc soi tu utilises mon loader soit tu modifies le tien pour utiliser gluBuild2DMipMaps...

---------------------------------------------------------
Patience et longueur de temps font plus que force ni que rage....
Coucous flingueurs 3D : http://www.freewebs.com/cf3d/

Merci c'était bien le dernier paramètre de gluPerspective.

C'est pas génant pour le prog de mettre ce dernier param trop élevé ???

Plus il est élevé et plus ça ralenti le jeu ?

C'est quoi le mipmapping ???

Plus c'est élevé, plus il "regarde loin", ça dépend en fait du nombre de polygones qui composent ton monde...Si ça n'est pas gênant de tout afficher tu peux laisser à une valeur très grande mais c'est déconseillé ^^

Le mipmapping, c'est le fait qu'OpenGL change de texture utilisée suivant sa distance par rapport à la caméra.
Quand tu appelles gluBuild2DMipmaps, GLU, via OpenGL, construit des "mipmaps", c'est-à-dire qu'à partir de la texture que tu passes en paramètre (par exemple, une texture 256x256), il en fait une copie 2 fois plus petite (128x128), et l'enregistre comme mipmap de level 1.
Il fait ça jusqu'à 2x2 (ou 1x1 mais ça m'étonnerait...enfin pourquoi pas ^^).

Comme ça, quand l'objet texturé est loin de la caméra, OpenGL préfèrera utiliser la texture 128x128 à la place de la texture 256x256; ça rendra mieux.

J'espère que je suis clair...

---------------------------------------------------------
Patience et longueur de temps font plus que force ni que rage....
Coucous flingueurs 3D : http://www.freewebs.com/cf3d/

Ah ok .

Oui tu as été très clair !

Je vais me renseigner un peu plus là dessus.
@++++++++

Funto66 > reduire la profondeur du frustum permet juste d'economiser en fillrate, tous les polygones sont rendu (toutes les glVertex que tu invoque ou tous ce qu'il ya dans tes vertex buffer sera dessiner, par definition tous les vertex passant par le pont agp sont rendu, la carte graphique n'est pas capable de determiner les polygones visibles, contrairement au rendu des texel)
sinon pourquoi on s'enmerderait a mettre au points des systemes de partitionnements & co :)

le plus important avec le parametre de profondeur, c'est de consideré la precision du z-buffer qui diminura si on l'augmente (nombre de valeur fixe mais champs de vision plus profond)
la precision diminu de maniere exponentiel en s'eloignant de la camera et il peut y avoir des effets desagreable de polygones qui se chevauchent (le test de profondeur n'est plus assez precis pour determiner si un polygones en cache un autre)

en principe on essay toujours de trouver un compromis, par exemple si on doit afficher un monde tres grands et qu'il n'y a pas (ou rarement) d'objets dans l'envirronement proche (cas typique d'un simulateur de vol), on augmente la distance du premier plan de clipping pour reduire la profodeur effective du champs de vision et donc pour avoir une meilleur precision sur les objets lointains

pour un debut, il faut d'abord fixer la distance du plan proche (ca depend de ton moteur, par exemple pour un doom like ca sera lié au systemes de collision/deplacement), et ensuite faire varier la distance du plan lointain (ce qu'il est necessaire pour voir toute ta scene), apres c'est juste une question d'echelle

Ok, pour le Z-buffer je savais pas que ça 'laffectait.

Par contre, laisse-moi émettre un doute sur ce que tu dis au sujet du frustum : quand je faisais mon système de heightmaps, changer le champ de vision affectait les performances; de même, quand je regardais un endroit "vide", les FPS étaient à leur maximum, mais ils diminuaient quand je regardais toute la heightmap...
Ce ne serait pas plutôt toutes les positions des vertexs qui seraient calculées mais les opérations de texturage/lumière...etc qui seraient effectuées selon si le polygone coupe le frustum ou pas?

---------------------------------------------------------
Patience et longueur de temps font plus que force ni que rage....
Coucous flingueurs 3D : http://www.freewebs.com/cf3d/

ben comme je l'ai dit tu gagne en fillrate, en gros ta scene est chargé en texel et plus tu voit la difference en regardant rien

je sais pas si l'eclairage joue, a priori ca fais partie du rendu mais les carte graphiques doivent gerer ca sans pertes de performances (je sais pas si l'eclairage par vertex est considerer comme dual texturing ? a priori non)

Dual texturing?? Ben l'éclairage c'est l'éclairage, les textures c'est autre chose...on a bien un glEnagle(GL_TEXTURE_2D) et un glEnable(GL_LIGHTING) qui sont différents ^^ (maintenant c'est peut-être lié au niveau hardware ça dépend de la carte graphique aussi).

fillrate, tu traduis par quoi exactement?

---------------------------------------------------------
Patience et longueur de temps font plus que force ni que rage....
Coucous flingueurs 3D : http://www.freewebs.com/cf3d/

en fait pour dual texturing je sais que c'est pas ca mais je me demandais comment se traduisais l'eclairage par vertex pour la cg (de toutes facon je pense que ca se fais sans perte)

le fillrate c'est le taux de remplissage de la carte graphique (comme son nom l'indique)

comme le polygone rate ou triangle rate qui se mesure en million de triangle par seconde, le fill rate se mesure en texel par seconde et en pixel par seconde, ca indique la capacité du rendering engine du processueur de la carte graphique

gagner en fillrate c'est tout betement etre moins limité par le rendu, avoir un rendu plus rapide (comme c'est le cas en regardant aucune texture ou en baissant la resolution...)

pour ta carte (rage fury 32mo ?) le moteur de rendeur du rage 128 possede 2 pipeline (2 unité en paralelle) pouvant rendre un pixel texturé en single texturing, pour le dual texturing, les 2 unité de textures sont combinée et le blending ne se fais que sur un seul pipeline d'ou un fillrate divisée par 2, c'est pour ca que je me demandais si dans ton cas l'eclaraige pouvais egalment joué

ps : les cartes d'aujourd'hui gere le dualtexturing sans perte de perf :)