Probleme avec le multitexturing: limitation à 4 textures?

Salut tout le monde,

Je suis en train de faire un moteur 3D et j'ai fait un shader pour un rendu de terrain qui utilise 13 textures,
1 pour le terrain, 4 pour les colors map, 4 pour les masques et 4 pour les normals map.

Mon problème est que openGL detecte une erreur de type GL_INVALID_OPERATION dans glClientActiveTextureARB(GL_TEXTUREX_ARB) à partir de GL_TEXTURE8_ARB jusqu'a GL_TEXTURE12_ARB. ce qui fait que des zones noires correspondant aux textures non affichées son sur mon rendu

quand j' utilise glGetIntegerv(GL_MAX_TEXTURE_UNITS, & m_nNBTextureMax));
Pour connaitre le nombre de texture max OpenGL me retourne 4.
Pourtant les indices de texture vont de GL_TEXTURE0_ARB à GL_TEXTURE31_ARB

Ma carte graphique est plutôt ressente c'est une NVidia 8700 GT 512 Mo, elle devrai permettre plus que 4 ou 8 textures.:aie:
J'utilise aussi SFML comme bibliothèque de fenêtrage

Ce qui est très bizzard c'est qu'avec la démo précédente de mon moteur j'ai les mêmes erreurs venant d'openGL (GL_INVALID_OPERATION et textureMAx = 4) mais le shader fonctionne parfaitement. Le probleme ne vient donc pas de celui-ci.:aie:

la seule solution que j'ai à te proposer est de faire un rendu multi passes
en tout cas, soit ton rendu est impressionnant, soit tu t'y prend mal parceque 13 textures pour effectuer le rendu d'un terrain... :aie:

Bonjour,

Citation:

---

Pour connaitre le nombre de texture max OpenGL me retourne 4.
Pourtant les indices de texture vont de GL_TEXTURE0_ARB à GL_TEXTURE31_ARB

---

Les indices sont ce qui a été "prévu" par la spécification OpenGL, ca ne veut pas dire que ta carte supporte obligatoirement 32 textures.
Si OpenGL te dit 4, c'est que c'est 4, c'est tout a fait envisageable avec ta carte.
Perso j'utilise au boulot une Quadro FX 350M, qui elle aussi n'a que 4 unités de textures alors que ce n'est quand meme pas une antiquité...

Citation:

---

Envoyé par ShevchenKik

Si OpenGL te dit 4, c'est que c'est 4, c'est tout a fait envisageable avec ta carte.

---

Pourquoi alors OpenGL me dit GL_INVALID_OPERATION à partir de GL_TEXTURE8_ARB ? Ça me fait 8 et non pas 4

tu veux dire que tu n'as pas d'erreur en utilisant jusqu'à 8 unités de textures mais qu'au delà ca plante?

Si oui c en effet bizarre. Essaie d'installer glView, il te dira de maniere sûre ce dont ta carte est capable...

Citation:

---

Envoyé par ShevchenKik

tu veux dire que tu n'as pas d'erreur en utilisant jusqu'à 8 unités de textures mais qu'au delà ca plante?

Si oui c en effet bizarre. Essaie d'installer glView, il te dira de maniere sûre ce dont ta carte est capable...

---

Je viens de regarder avec glView
Effectivement j'ai bien Texture units = 4 ce qui explique le chiffre de 4 optenu avec glGetIntegerv(GL_MAX_TEXTURE_UNITS, & m_nNBTextureMax));

Je vais pas mettre toutes les infos que glView fournis, voici les pricipales

Renderer: GeForce 8700M GT/PCI/SSE2
Vendor: NVIDIA Corporation
Memory: 512 MB
Version: 2.1.1
Shading language version: 1.20 NVIDIA via Cg compiler
Max number of light sources: 8
Max viewport size: 8192 x 8192
Max texture size: 8192 x 8192
Max anisotropy: 16
Max samples: 32
Max draw buffers: 8
Max texture coordinates: 8
Max vertex texture image units: 32

Est ce que l'erreur à partir de GL_TEXTURE8_ARB serrait du à
Max texture coordinates: 8

Ce qui est bizarre c'est que j'arrive dans certaines de mes demos à rendre malgré les erreurs tout ce dont j'ai envie, un exemple par l'image ou j'ai 12 textures pour le rendu du terrain (4 pour les colors maps: sable, herbe1, herbe 2, roche, 4 pour les masque indiquant les zones ou les afficher, 4 pour les normal pour faire du bumpmapping dessus) + 1 pour le shadow mapping
http://img1.imagilive.com/1008/ScreenShot04.jpg

je rajoue une miage pour monter quand ça marche pas remarquez les zones noires:
http://img1.imagilive.com/1008/ScreenShotV3D.jpg

Euhhh et bien c'est bizarre tout ca...d'un côté il te dit que tu as 4 Texture units, mais de l'autre qu'il supporte jusque 8 coordonées de texture....

Tiens en vérifiant chez moi c pareil en fait... je l'interprète comme ca (si quelau'un peut confirmer / infirmer, merci):

Tu n'as que 4 TU sur ta carte, donc 4 textures que tu peux charger simultanement. Par contre tu peux sauvegarder jusque 8 coordonées de texture par vertex. Par exemple ca peut te faire 2 jeux de coordonnées par texture disponible. Il doit y avoir d'autres utilités mais comme je viens a l'instant de me rendre compte de cette "particularité"...

Je viens de tester sur une vielle machine avec une carte PowerVR KYRO 64 (je sais c'est vieux) et j'obtiens
Texture units = 4
Max texture coordinates = 0

Quelqu'un peu-il expliquer le sens de ces paramètres?

je mets le reste du test:

Renderer: PowerVR KYRO
Vendor: Imagination Technologies
Memory: 64 MB
Version: 1.2.1
Shading language version: N/A
Max number of light sources: 8
Max viewport size: 2048 x 2048
Max texture size: 1024 x 1024
Max anisotropy: 2
Max samples: 4
Max draw buffers: 0
Max texture coordinates: 0
Max vertex texture image units: 0

Citation:

---

Euhhh et bien c'est bizarre tout ca...d'un côté il te dit que tu as 4 Texture units, mais de l'autre qu'il supporte jusque 8 coordonées de texture....

---

Oups, suis-je bête...en fait c'est simple, 2 coordonnées (u et v) pour chaque texture, fois 4 = 8 coordonnées...;)

Citation:

---

Je viens de tester sur une vielle machine avec une carte PowerVR KYRO 64 (je sais c'est vieux) et j'obtiens
Texture units = 4
Max texture coordinates = 0

---

Là par contre, je ne sais pas pourquoi tu n'as pas de coordonnées de texture si tu as 4 unités de texture (elles sont implémentées physiquement sur ta carte graphique, chacune étant chargée de stocker une texture et de l'appliquer à une ou plusieurs géométries, pour répondre à ta question :)). Peut être un probleme de driver? OpenGL 1.2 supporte les textures en tout cas donc si ta carte a des Texture units...?

Citation:

---

la seule solution que j'ai à te proposer est de faire un rendu multi passes

---

Tu peux aussi essayer de mettre des textures "côte à côte" dans une ou plusieurs textures plus grandes puis jouer avec les coordonnées de texture pour appliquer la bonne

Les cartes style geforce 8 peuvent lire beaucoup plus de textures "simultanément". Et ce n'est pas lié non plus au nombres d'unités de lecture physique, les unités séparées servent uniquement pour le "parallélisme", les accès depuis les shaders sont "virtualisés". C'est évident si l'on pense que les cartes bas de gamme récentes ont le même nombre d'"entrées programmables" pour les textures que les cartes haut de gamme récentes tout en ayant beaucoup moins d'unités de texturage physiques. La seule différence est la rapidité (deux unités de texture peuvent traiter l'adressage et le filtrage deux fois plus vite qu'une).

C'est à dire que le hardware va lire le numéro de "texture" et va demander à une unité de texture libre de lire cette texture à partir des infos qui sont inscrites dans un registre hardware. C'est le nombre de ces registres hardware et les limites du modèle de programmation (aussi appelée IA) qui va limiter le nombre total de textures distinctes que l'on peut lire en une seule passe de pixel shader/vertex shader.

Pour les texture coordinates c'est encore différent. Les texture coordinates dans les hardware modernes sont devenus un concept distinct d'une texture au point où dans Direct3D par exemple on ne les appelle plus texture coordinates mais "interpolated attributes".

Après le problème dans l'esprit des gens est dû, je crois, au modèle de programmation obsolète que présente OpenGL. OpenGL a gardé le mode de programmation de l'époque où le fait de pouvoir faire du multi-texturing était une feature qui valait le coup d'être mentionné. Aujourd'hui, une texture c'est juste une resource ou base de donnée qui est adressée via un registre temporaire dans un shader/programme.

Pour une vue plus moderne referez vous à arb_fragment_program par exemple :
http://www.opengl.org/registry/specs...nt_program.txt

LeGreg

Oh sinon,

MAX_TEXTURE_IMAGE_UNITS_ARB = 32
sur geforce 8

Et bien plus si l'on prend en compte les texture arrays (supportées par geforce 8 depuis deux ans).

http://developer.download.nvidia.com...ture_array.txt

Bien entendu ces limitations seront peut-etre arbitraires à l'avenir.. mais qui vivra verra.

LeGreg

C'est TRES deconseillé de dépasser 2 textures en multitexturing ... Sauf si tu ne cherches pas à diffuser ton programme (bien sûr).
ma 8600 ne dépasse 4 textures, pourtant, elle ne date que d'un an et demi.

Il te reste le rendu en 2 passes (pour un terrain, ça peut être une alternative .. Horrible pour des modèles ).

Pour ma part, j'utilise 2 textures (pour un terrain 4096*4096, déjà très lourd):
- un texture de base 512*512 que j'ai généré de façon procédurale
- une détail map, aussi de 512*512 (plus petit, ça marche aussi)

Pour recalculer les ombres en fonction des heures de la journée (par exemple) dans un tableau de glColor, c'est pas si mal !!

Une seule passe, et ma foi, c'est acceptable !!

Le tout en VBO + système d'indices + frustrum culling + GUI (embryonnaire :mouarf:), j'arrive a peu près à un FPS de 50/70 sachant que j'ai également de l'eau dynamique + ciel et pas mal de modèles ensemble.

en quoi est-ce déconseillé de dépasser 2 textures ? c'est bien la première fois que j'entend ça !!
un jeu pas trop récent comme farcry utilise déjà plus de 4 textures en simultané

essaies donc de travailler avec 1 passe de 4 textures au lieu de 2 passes de 2 textures, tu va gagner en fluidité comme en claquant des doigts

En reprenant mon code j'arrive maintenant à afficher mon terrain sans zones noires avec toutes mes textures. Il y avait une merde de mon coté:aie:

Sinon dans les jeux récent les modeles utilisent beaucoup de textures: color map, bump map, height map, gloss map, shadow map ... et il peut y en avoir plus. On dépasse facilement les 4 textures

Finalement je n'ai toujours pas compris pourquoi openGL me crache encore des erreurs alors que ca fonction quand même. Peut être que l'on est moins limité en utilisant des shaders.

Citation:

---

Envoyé par Syl_20

Finalement je n'ai toujours pas compris pourquoi openGL me crache encore des erreurs alors que ca fonction quand même. Peut être que l'on est moins limité en utilisant des shaders.

---

Relis ce que j'ai écrit :
tu confonds texture coordinates (le set de nombres X, Y, Z qui sont passés et interpolés du vertex au pixel) et texture images (la base de donnée addressable en 1D/2D/3D qui contient l'information de couleur).

glClientActiveTextureARB() -> la limite c'est le nombre de "texture coordinates" qui est de 8 sur ta geforce 8.

glActiveTextureARB() -> la limite c'est le nombre de "texture image units" qui est de 32 sur ta geforce 8.

La faute à qui ? La faute à OpenGL et son interface de programmation moyen âgeuse. Sérieusement ça devrait être considéré comme un service au public de déconseiller aux débutants de démarrer par la programmation OpenGL..

LeGreg

C'est une bonne nouvelle que tu ais réussi à resourdre ton problème de "zones noires"

A mon avis, le driver OpenGL ne retourne pas l'information exacte qu'il devrait, la faute au constructeur, ou plutot aux développeurs des drivers
Je pense qu'il s'agit donc d'une anomalie dans le driver, tu peux essayer de les mettre à jour

Citation:

---

Envoyé par shenron666

A mon avis, le driver OpenGL ne retourne pas l'information exacte qu'il devrait, la faute au constructeur, ou plutot aux développeurs des drivers
Je pense qu'il s'agit donc d'une anomalie dans le driver, tu peux essayer de les mettre à jour

---

Je me répète mais 4 est la bonne valeur pour MAX_TEXTURE_UNITS. Arb_multitexture est une extension obsolète qui a été supplantée par arb_fragment_program.

LeGreg

si 4 est la bonne valeur, à quoi fait-elle référence ?
comment connaitre le nombre max de textures combinables ?

Citation:

---

Envoyé par shenron666

comment connaitre le nombre max de textures combinables ?

---

Je l'ai écrit trois messages plus haut :

MAX_TEXTURE_IMAGE_UNITS_ARB = 32

Citation:

---

Envoyé par shenron666

si 4 est la bonne valeur, à quoi fait-elle référence ?

---

Elle fait référence à un mode de programmation obsolète appelé ARB_MULTITEXTURE. Ce mode de programmation est conservé pour les vieilles applications ou celles qui ne veulent pas évoluer. Afin d'éviter d'overloader le sens de MAX_TEXTURE_UNITS qui est toujours utilisé par ces vieilles applications, arb_fragment_program a donc introduit deux nouvelles valeurs MAX_TEXTURE_IMAGE_UNITS_ARB, MAX_TEXTURE_COORDS_ARB avec chacune leur signification précise et des valeurs différentes (32 pour la première et 8 pour la seconde sur Geforce 8).

Voilà pour la troisième ou quatrième fois dans le meme thread :/

LeGreg

désolé de te faire répéter ce que tu n'as pas clairement expliqué précédemment
de même je ne suis pas d'accord sur plusieurs points :
- arb_multitexture n'est PAS obsolète
- arb_fragment_program par contre si, il y a le glsl maintenant
- arb_fragment_program n'est pas un "remplacement" de arb_multitexture, les 2 extensions se complètent

sinon opengl est très bien pour les débutants, surtout comparé à direct3d qui est très lourd
le problème des débutants, c'est les tutoriaux qui sont obsolètes, on ne devrait plus commencer par apprendre à coder en glvertex et commencer au moins en GL1.5 voire en 2.0