2016-04-08 3 views
0

Existe-t-il certaines restrictions de format que les textures doivent également respecter?Restrictions du format OpenGL Textures

Je suis le chargement des fichiers TGA et les dessiner avec le shader fragment suivant:

varying vec2  v_texCoord; 
uniform sampler2D s_texture; 
uniform vec4  vColor4; 

void main() 
{ 
    vec4 tmpColor = texture2D(s_texture, v_texCoord); 

    tmpColor.r = vColor4.r; 
    tmpColor.g = vColor4.g; 
    tmpColor.b = vColor4.b; 

    gl_FragColor = tmpColor; 
} 

Je trouve que les images 16x16 afficher OK. 64x16 affichage OK. 72x16, 80x16 et 96x16 ne fonctionnent pas.

Je fournirai plus d'informations, y compris les fichiers TGA si nécessaire.

+2

Utilisez-vous OpenGL ou OpenGL ES? Il y avait des restrictions sur les textures dont ils avaient besoin pour être une puissance de deux dans les deux dimensions. Toutefois, cette restriction a été supprimée d'OpenGL après la version 2.0. Avec OpenGL ES et WebGL, cette restriction peut toujours exister (à moins que votre implémentation ne prenne en charge une extension supprimant la restriction). – radical7

+0

@ radical7 J'utilise OpenGL ES2.0. Cela aurait du sens ce que vous dites. Donc, après 64x16, il faudrait 128x16 et 256x16 etc? – SparkyNZ

+0

juste aller avec 2^n comme 2 4 8 16 32 64 128 256 512 1024 .. Il est évident. – Sung

Répondre

0

72, 80 et 96 ne sont pas des puissances de deux; cette exigence a peu à voir avec le format de données dans OpenGL ES. Cette exigence est réellement omniprésente même dans le bureau GL moderne, où elle peut dépendre du format de données utilisé. Les données de texture non compressées dans (bureau) OpenGL 2.0 ou supérieur peuvent avoir des dimensions non-puissance-de-deux. Cependant, les données de texture compressées nécessitent toujours des tailles de bloc multiples de 4, les fonctions de transfert de pixels continuent à supposer un alignement de données de 4 octets pour chaque ligne d'une image, les textures à virgule flottante peuvent également nécessiter deux, et ainsi de suite. De nombreuses bibliothèques d'images conçues pour GL vont réellement redimensionner les données à une puissance de deux, ce qui peut résoudre chacun des problèmes discutés ci-dessus. Ce n'est pas toujours la manière la plus appropriée (cela peut être extrêmement inutile) de résoudre les problèmes de dimension, mais elle peut être appliquée universellement à n'importe quel problème de dimension commun.

+0

Oui, toutes les textures que j'utilise sont compressées. – SparkyNZ

+0

"* Les données de texture non compressées dans (bureau) OpenGL 2.0 ou version supérieure peuvent avoir des dimensions non-puissance-de-deux. *" Non, *** toutes les textures dans le bureau OpenGL 2.0+ peuvent avoir des 2 dimensions, compressées ou non. Les tailles de blocs n'ont rien à voir avec la taille de la texture, puisque les blocs partiels ne sont pas interdits par la spécification OpenGL. La spécification indique clairement comment les formats compressés par bloc fonctionnent pour les textures dont les tailles ne sont pas divisibles par la taille du bloc. Donc, votre réponse ne s'applique qu'à OpenGL. –

+0

Ce commentaire est complètement confus et vérifiable. Les textures DXTn en tant qu'exemple simple génèrent 'GL_INVALID_OPERATION' si vous tentez d'allouer une banque de données avec des cotes non bloquées.Les autres formats compressés ont leurs propres règles discutées dans leurs spécifications d'extension respectives. Et bien sûr, cela ne s'applique qu'à OpenGL, j'essaie de garder mes réponses pertinentes pour les API en cours de discussion. Si vous voulez discuter de Vulkan, Direct3D ou d'une autre API, soyez mon invité, mais je ne vois pas quelle valeur cela ajoutera à la question. –