Oui Crisot, il faut que le développeur l'implémente dans le monteur de jeu mai,s l'utilisateur à tout de même le contrôle sur l'effet (et donc le choix de l'ajouter ou pas) Et, c'est ce que je voulais dire !

Hello

> En fonction de la taille du polygone, le GPU va toujours utiliser la version la plus petite possible pour maximiser les performances.
T'es sûr de ça ? J'arrive pas en trouver la confirmation dans les specs opengl...
Moi, intuitivement, j'aurai cru qu'il prenait toujours la plus grande pour pas perdre de détails... (je veut dire si le "pas" est entre deux mipmaps il prend la plus grande des deux)
Mais ça change pas grand chose car je pense plutot que le problème venait du fait qu'il traitait tout linéairement par segment horizontaux, un pixel après l'autre
Genre une face comme ceci, réprésentant un mur gauche de ton couloir, aplati dans le sens horizontal
12
3456A
BCDEF
GHIJKL
MNOPQ
RSTUV
WX
Alors il traite les pixels dans mon ordre alphabétique et donc prend toujours la plus petite mipmap comme tout les segments horizontaux (comme BCDEF) sont serrés dans ce sens. Si il prenait la face dans son ensemble (cad élargie en vertical) il verrait que c'est une plus grosse mipmap qu'il faut

Je pense que pour chaque pixel l'Anisotropic doit prendre
* les 4 texels autour (=bilinear=linear en x + linear en y)
* des 2 mipmaps autour du "pas" (trilinear)
* pour le "pas" horizontal Et le "pas" vertical (anisotropic)
soit 16 texels = oupps !!!

Ca bouffe pas de trop de bande passante cet Anisotropic ? T'aurais pas eu plutot intérêt à découper tes murs "en bandes de papier peints" moins larges ???

Alain

texels: pixels d'une texture.
Ici 16 texels vont donner un seul pixel à l'écran....

Message édité par : thellier / 07-01-2013 14:05

@Thellier :
Je ne pense pas qu'OpenGL prenne toujours la plus petite texture pour optimiser.
C'est toi qui choisi quand tu appliques ta texture au modèle (ou à la création de cette dernière en mémoire) :

void glTexParameterf( GLenum â target,
â GLenum â pname,
â GLfloat â param);
void glTexParameteri( GLenum â target,
â GLenum â pname,
â GLint â param);

target
Specifies the target texture, which must be either GL_TEXTURE_1D, GL_TEXTURE_2D, GL_TEXTURE_3D, or GL_TEXTURE_CUBE_MAP.

pname
Specifies the symbolic name of a single-valued texture parameter. pname can be one of the following: GL_TEXTURE_MIN_FILTER, GL_TEXTURE_MAG_FILTER, GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD, GL_TEXTURE_BASE_LEVEL, GL_TEXTURE_MAX_LEVEL, GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T, GL_TEXTURE_WRAP_R, GL_TEXTURE_PRIORITY, GL_TEXTURE_COMPARE_MODE, GL_TEXTURE_COMPARE_FUNC, GL_DEPTH_TEXTURE_MODE, or GL_GENERATE_MIPMAP.

param
supplies a function for minifying the texture as one of the following:

GL_NEAREST
Returns the value of the texture element that is nearest (in Manhattan distance) to the center of the pixel being textured.

GL_LINEAR
Returns the weighted average of the four texture elements that are closest to the center of the pixel being textured. These can !!!include!!! border texture elements, depending on the values of GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T, and on the exact mapping.

GL_NEAREST_MIPMAP_NEAREST
Chooses the mipmap that most closely matches the size of the pixel being textured and uses the GL_NEAREST criterion (the texture element nearest to the center of the pixel) to produce a texture value.

GL_LINEAR_MIPMAP_NEAREST
Chooses the mipmap that most closely matches the size of the pixel being textured and uses the GL_LINEAR criterion (a weighted average of the four texture elements that are closest to the center of the pixel) to produce a texture value.

GL_NEAREST_MIPMAP_LINEAR
Chooses the two mipmaps that most closely match the size of the pixel being textured and uses the GL_NEAREST criterion (the texture element nearest to the center of the pixel) to produce a texture value from each mipmap. The final texture value is a weighted average of those two values.

GL_LINEAR_MIPMAP_LINEAR
Chooses the two mipmaps that most closely match the size of the pixel being textured and uses the GL_LINEAR criterion (a weighted average of the four texture elements that are closest to the center of the pixel) to produce a texture value from each mipmap. The final texture value is a weighted average of those two values.

D'ailleurs, comme toi je n'ai rien trouvé dans les specs d'OpenGL qui puisse confirmer que ce soit le cas (ou pas) :p
Sachant qu'en plus, lorsque tu crées ta texture, tu peux la créer SANS mipmap level. Ce qui fait qu'il est forcé (dans ce cas là) d'utiliser la texture de base pour le rendu.

Maintenant, pour l'anisotropic filtering :
http://en.wikipedia.org/wiki/Anisotropic_filtering
Le mieux c'est carrément de lire le wiki qui décrit comment ça fonctionne.
J'ai pas tout compris mais bon ... c'est déjà mieux que rien :p

@+
Message édité par : AmiDARK / 07-01-2013 14:20
Message édité par : Creols / 07-01-2013 16:02

Toujours à contredire hein...

Le GPU se base bien sur le plus petit coté pour choisir le mipmap. Si il se basait sur le plus grand coté, il prendrait un plus grand mipmap. Il n'y aurait donc pas de perte de détails comme c'est le cas, et l'anisotropic filtering n'existerait pas.

Je ne l'ai lu nul part, dans aucune spécification, aucune doc OpenGL, aucun site web. J'ai ouvert mes yeux, et j'ai constaté.



Regardez cette image, il n'y a AUCUN moyen d'obtenir la qualité de droite sans anisotropic filtering. AUCUN, si ce n'est de carrément désactiver le mipmaping. Parceque les MIPMAP choisis à gauche sont toujours basés sur la hauteur, et donc très sous-évalués pour la largeur.
Message édité par : Crisot / 07-01-2013 19:20

Citation : thellier?
Ca bouffe pas de trop de bande passante cet Anisotropic ? T'aurais pas eu plutot intérêt à découper tes murs "en bandes de papier peints" moins larges ???

Le trilinear se base sur 8 textels (4 textels dans 2 mipmap) alors que le bilinear ne se base que sur 4 textels. Pourtant, le trilinear est plus performant que le bilinear, de par l'utilisation fréquentes de textures plus petites et plus rapides à parcourir.

De la même manière, l'anisotropic est un peu moins performant que le trilinear de par l'utilisation des textures anisos qui sont généralement plus larges/hautes que les mipmap de base. Mais la perte de performances s'arrête là, ça reste tolérable et pas pire qu'un bilinear sans mipmap.

Par contre ça bouffe une chiée de vram.

Edit: Et j'ajoute que nos générations de vieilles cartes ne sont pas capables d'interpoler 2 niveau de mipmap lorsque l'anisotropic filter est activé. On retrouve donc le vieu problème de "hard transition line" entre les changements de mipmap qu'on avait en bilinear mipmap il y a 20 ans. Mais ça fait retomber à 8 textels.
Message édité par : Crisot / 07-01-2013 19:39

Hello
Mais moi je suis comme AmiDark j'adore la polémique c'est mon coté anarchiste...

>Regardez cette image,[...] les MIPMAP choisis à gauche sont toujours basés sur la hauteur, et donc très sous-évalués pour la largeur.

[En admettant que la route soit une seule face...]
Si c'étais le cas alors la partie basse où il y a le "28" serait aussi floue que la partie haute de la route alors que les "28" sont identiques ==> preuve que la linéarisation (tracage des pixels) se fait à l'horizontal et que le choix des mipmaps se fait pour chaque pixel

>Le GPU se base bien sur le plus petit coté pour choisir le mipmap. Si il se basait sur le plus grand coté
J'ai jamais dit ça : le GPU fait l'estimation pour chaque pixel du segment à tracer = c'est bien ça le problème il prend pas en compte le plus grand coté de la face comme il devrait...

Au lieu de te pignoler sur l'anisotropic n'oublie pas de faire les monstres dans ton jeu sinon ce sera trop chiant ;-P

Bonne nuit

Alain

Thellier :
Au lieu de te pignoler sur l'anisotropic n'oublie pas de faire les monstres dans ton jeu sinon ce sera trop chiant ;-P
Celle là ... Elle était trop facile ;)

Après discussion avec Hans de Ruiter, si Karlos fait l'implémentation des nouveaux filtres dans l'API de Warp3D. Je pourrais tenter de modifier le MiniGL pour qu'il puisse demander à Warp3D l'activation du filtrage anisotropique. Je lui soumettrais alors la version modifiée de MiniGL pour qu'il puisse la faire valider.



Message édité par : AmiDARK / 07-01-2013 22:12

Citation : Crisot?

Edit: Et j'ajoute que nos générations de vieilles cartes ne sont pas capables d'interpoler 2 niveau de mipmap lorsque l'anisotropic filter est activé. On retrouve donc le vieu problème de "hard transition line" entre les changements de mipmap qu'on avait en bilinear mipmap il y a 20 ans. Mais ça fait retomber à 8 textels.

Quand tu parles de générations de vieilles cartes, est-ce que cela englobe les Radeon HD7xxx qui sont des cartes actuelles et maintenant supportées par le pilote de Hans de Ruiters ?
le pilote de Hans est 2D pour l'instant.

>nos vieilles cartes ne sont pas capables d'interpoler 2 niveaux de mipmaps lorsque l'anisotropic filter est activé. On retrouve donc le vieux problème de "hard transition line"

Tu te complais dans le jargon, tu dois etre prof ou chercheur ;-P

Allez moi aussi je sors un mot dans mon domaine favori (écologie & botanique) "Ecotype" à vous de chercher la définition.... ;->

Bref t'es en train de nous dire que nos cartes ne supportent pas l'anisotropic filtering ...

baf baf baf... on vivra sans ... déjà on a pas eu la fin du monde en 2012 ...


Alain

/me qui adore voir les combats de catch dans la boue de 2 mentals 5 :p
(comprenne qui pourra)