Discussion :

[ZiZouJH]

Alors voilà j'étais en train de coder tranquillement sous OpenGL en voulant mettre un carré en rouge.

Le codage à adopter en rvb était alors 1 0 0.

Vu que ce sont des entiers je me suis dit que j'allais utiliser glColor3i (oui je suis radin j'économise au maximum quand je code )

Et bien je suis tombé sur ce que je crois être un bug d'OpenGL et pendant quelques heures (oui je sais je suis le seul con à utiliser glColor3i) j'ai même cru que ça ne fonctionnait tout simplement pas.

La documentation de ce que j'ai pu en lire spécifie qu'on l'utilise exactement comme glColor3f mais avec des entiers au lieu des flottants. C'est à dire qu'on ne peut mettre que 0 ou 1 pour chacun des composantes.

J'ai donc appelé glColor3i(1, 0, 0);
Le carré apparaît noir... Je me suis alors dit qu'il fallait partir sur une base de 0 à 255 par composante. Même résultat avec glColor3i(255, 0, 0);

J'ai alors pensé que ça venait peut-être de moi ; je me suis lancé dans des recherches de fou (et là j'ai remarqué par la même occasion sur google que personne n'utilisait cette fonction réellement dans son code) et j'en suis venu à la conclusion que la fonction était bugguée et ne servait en fait qu'à faire ce que ferait une simple void glBlack(void);

Mais têtu comme je suis j'ai continué mes tests en récupérant la variable d'environnement glut de la couleur courante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
glColor3i(2147483647, 0, 0);
int couleurs[4];
glGetIntegerv(GL_CURRENT_COLOR, couleurs);
printf("couleur : %d %d %d %d\n", couleurs[0], couleurs[1], couleurs[2], couleurs[3]);

Cela renvoyait 1 0 0 et 2147483647 soit 2^32 / 2 - 1, c'est-à-dire la limite supérieur des entiers signés !
La valeur de l'alpha étant par défaut fixée à 1 (totale opacité), je me suis dit qu'en fait glColor3i ne travaillait pas sur un intervalle [0;1] mais sur [0;2^sizeof(int) / 2 - 1]. Je ne vous cache pas que j'ai mis du temps à le comprendre.
Chose étrange, lorsqu'on récupère les paramètres en flottant avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
glColor3i(2147483647, 0, 0);
float couleurs[4];
glGetFloatv(GL_CURRENT_COLOR, couleurs);
printf("couleur : %f %f %f %f\n", couleurs[0], couleurs[1], couleurs[2], couleurs[3]);

J'ai bien 1.000000 0.000000 0.000000 1.000000 qui s'affiche !

J'ai pensé que cela venait de ma machine ou du compilateur (Visual Studio .NET) mais j'ai testé sur une machine complètement différente avec Dev-C++ et version moins récente de GLUT. Le résultat était le même...

On peut appliquer le même raisonnement pour glColor3ui mais avec cette fois un intervalle [0;4294967295] puisque 2^32 - 1 est la borne supérieur des entiers non signés.

Donc c'est vraiment un bug d'OpenGL ou alors quelque chose de non documenté (ce dont je doute puisqu'il n'est pas vraiment pratique pour la machine d'utiliser des si gros nombres). Autre hypothèse : mes drivers nVidia sont buggués mais ça m'étonnerait tout de même.

Si quelqu'un peut me rectifier ou ajouter des choses qu'il n'hésite pas !

Après toutes les heures passées là-dessus je n'ai pas voulu approfondir sur glColor3iv, glColor3uiv, glColor3b, glColor3ub, glColor3bv et glColor3ubv mais il y a fort à parier que le problème soit similaire.

[bafman]

deja si il y a un bug ce sera obligatoirement de tes driver nvidia etant donné que c'est chaque constructeur qui implemente sa version d'openGL...

et est ce que tu a activé l'eclairage ??? si c'est le cas, c'est l'eclairage openGL qui specifie les glColor a l'envoi de chaque vertex donc les tiens n'auront aucun effets, et la couleur courante risque effectivement d'etre changée...

[ZiZouJH]

Je tiens tout d'abord à préciser que je viens de faire le test sur une troisième machine.
Récapitulation des plateformes de test :
- p4 2.8 + gf4ti4200 + windows server 2003 + visual studio .net 2003
- p3 500 + tnt2m64 + windows server 2003 + dev-c++ 5
- p3 500 + ati rage pro intégrée à la cm + voodoo² + windows xp pro + dev-c++ 5

Même résultat sur les 3 plateformes...

Non je n'ai pas activé l'éclairage, donc pas de souci à ce niveau là, d'autant plus qu'un glColor3f(1.0f, 0.0f, 0.0f); fonctionne sans problème (de même qu'un glColor3d(1.0, 0.0, 0.0)

A priori l'opengl32.dll n'est pas le même sur la troisième plateforme (ni sur les deux premières étant données que les versions de drivers ne sont pas les mêmes il me semble) donc à part un bug OpenGL (je sais que je suis fou de dire ça) je ne vois pas trop d'autre possibilité....

Si des personnes ici pouvaient tester ce serait cool...

[charly]

Et tu sur que ce n'est pas plutot une erreur de programation :
j'eplique , sous deplhi , les entiers sont sous 24 bit il me semble ( dsl si je me trompe ) or je suppose que sous vc++ et devc++ c'est la même chose , par conscéquant , le type integer , ne serait pas equivalent , ce qui pourrait expliquer ,les valeurs acabadabrantes retourné .

C'est juste une proposition

[ZiZouJH]

Et bien en C/C++ les entiers sont codés sur 32 bits (tout comme les flottants) donc je ne sais pas trop...
L'intervalle est de -2147483648 à 2147483647 pour les entiers signés (int ou long) et de 0 à 4294967295 pour les entiers non signés (unsigned int).
Je n'ai aucune expérience de Delphi mais toi apparemment si, alors si tu pouvais expérimenter ce serait sympa
Et même admettant que ce que tu dis est juste, ça prouve qu'il y a un bug : une fonction d'une librairie doit fonctionner de la même manière d'un langage de programmation à un autre.

[charly]

oui oui , je suis daccord , bon je vais tester le code sur ma plateforme et je verrais bien
Enfin , je suis pas sur que les entier soit en 24bits sous delphi hein , je dois surement me tromper !!

[ZiZouJH]

C'est cool si tu peux tester
Effectivement 24 bits ça me paraît bizarre mais après tout pourquoi pas
J'attends avec impatience les résultats de tes tests.

[ZiZouJH]

UP !

alors charly qu'est-ce que ça donne :

[ZiZouJH]

bon ben c'est mort si personne ne réagit...

[amaury pouly]

J'espère qu'il n'est pas trop tard, j'ai essayer de faire mon propre code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
#include <SDL/SDL.h>
#include <windows.h>
#include <gl/gl.h>
int main(int Arg_N, char ** Arg_V){
SDL_Event event;
float theta = 0.0f;
SDL_Init(SDL_INIT_VIDEO);
SDL_SetVideoMode(600, 300, 0, SDL_OPENGL | SDL_HWSURFACE | SDL_NOFRAME);
glViewport(0, 0, 600, 300);
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClearDepth(1.0);
glDepthFunc(GL_LESS);
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_SMOOTH);
glMatrixMode(GL_PROJECTION);
glMatrixMode(GL_MODELVIEW);
for(int done = 0; !done;){
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
glTranslatef(0.0f,0.0f,0.0f);
glRotatef(theta, 0.0f, 0.0f, 1.0f);
glBegin(GL_TRIANGLES);
//glColor3f(1.0f, 0.0f, 0.0f);
//glColor3ub(255,0,0);
glColor3i(255,0,0);
 
glVertex2f(0.0f, 1.0f);
//glColor3f(0.0f, 1.0f, 0.0f);
//glColor3ub(0,255,0);
 
glColor3i(0,255,0);
 
glVertex2f(0.87f, -0.5f);
//glColor3f(0.0f, 0.0f, 1.0f);
//glColor3ub(0,0,255);
 
glColor3i(0,0,255);
 
glVertex2f(-0.87f, -0.5f);
glEnd();
theta += .5f;
SDL_GL_SwapBuffers();
SDL_PollEvent(&event);
if(event.key.keysym.sym == SDLK_ESCAPE)done = 1;}
SDL_Quit();
return(0);}

et j'obtient un écran noir alors que avec glColor3f et glColor3ub cela marche parfaitement . Je ne sais pas d'où vient le pb parce que c'est la première fois que j'utilsie glColor3i . C'est très bizarre .[/img]

[ZiZouJH]

donc ça confirme ma théorie

[funkeejeffou]

Salut,

C'est peut etre un vieux post mais désolé, il fallait que je reponde.
Déja je trouve pretentieu de ta part que tu affirmes l'existence d'un BUG d'une librairie réputée et ayant fait ses preuves(milieu professionnel et commercial entre autre) sur une fonction si basique. Je pense aussi que le fait que le résultat etait le même chez plusieurs personnes, ainsi que le fait d'avoir tester sur plusieurs configurations différentes aurait du t'amener à cette réflexion :
"Il s'agit du mode de fonctionnement de glColori".

En gros, si tu cherches sur google(comme tu le dis si bien), tu trouve la manpage de glColor référencée en premier lieu et plusieurs fois. Celle ci t'explique une chose claire. Les couleurs codée en flottante vont de 0.0f à 1.0f. Jusque la, on est d'accord. Pour ce qui concerne les valeurs entières(8bits, 16 bits ou 32 bits),le 0.0f sera représenté par la PLUS PETITE valeur codable dans ce format; de même 1.0f sera codé par la PLUS GRANDE valeur dans ce format.
Donc c simple :
Pour un char : -128 à 127
unsigned char : 0 à 255
short int : -32768 à 32767
etc.......

Aussi, j ai une petite remarque : 2^32 / 2 = 2^31, voila c est tout...

Bref, je confirme "ta théorie", sans vouloir t'offusquer tu ne sais pas lire une documentation, et je suis etonné que personne n'est réagis à ce post...

[bafman]

plus de precision

For the versions of glColor*() that accept floating-point data types, the values should typically range between 0.0 and 1.0, the minimum and maximum values that can be stored in the framebuffer. (Values ouside the range [0,1] are clamped to the range [0,1] when used directly, but aren't clamped when used to modify lighting material parameters.) Unsigned-integer color components, when specified, are linearly mapped to floating-point values such that the largest representable value maps to 1.0 (full intensity), and zero maps to 0.0 (zero intensity). Signed-integer color components, when specified, are linearly mapped to floating-point values such that the most positive representable value maps to 1.0, and the most negative representable value maps to -1.0 (see Table 5-1 ). Floating-point values are mapped directly. Neither floating-point nor signed-integer values are clamped to the range [0,1] before updating the current color. However, color components are clamped to this range before they are interpolated or written into a color buffer.

tiré du red book...

[ZiZouJH]

Bon déjà ce n'était pas prétentieux et si j'ai osé affirmer ça c'est en l'ayant testé assez longtemps pour le constater. Comme je l'ai plus ou moins dit je trouvais ça curieux. Si le mot bug te choque, rassure toi je l'ai utilisé pour faire réagir les gens, même s'il est vrai que devant le peu de choses que j'ai pu trouver concernant cette fonction j'ai eu quelques doutes...

Concernant la manpage (à quand une version pdf du bluebook...) dont tu parles je la trouve très obscure. Aussi, j'ai vu de nombreux exemples sur le net où les personnes utilisaient et affirmaient dans leurs tutoriels que ça allait de 0 à 255 (ce qui me paraissait logique étant donné qu'on ne peut représenter que 256 niveaux d'intensité par composante de couleur).

(au passage, oui je sais que 2^32 / 2 = 2^(32-1) = 2^31, et alors ?)

Alors si on se base sur ce que tu dis (et ce que dit la manpage) cette fonction est une aberration puisque de nombreuses valeurs ne servent à rien. Et même si ça fonctionne de manière cohérente je ne vois en rien l'utilité de cette fonction qui oblige à utiliser des nombres assez immenses...

Je n'ai rien contre les programmeurs d'OpenGL, au contraire, je trouve cette bibliothèque géniale, enfin je ne vais pas sortir tous les arguments qu'a OpenGL car tu les connais sûrement aussi bien voire mieux que moi. Mais il faut reconnaître que pour cette fonction c'est un peu n'importe quoi...

[bafman]

non ce n'est pas n'importe quoi...
ou a tu vu que les composantes des couleurs etait codé uniquement sur 256 chiffre ? c'est faux... les composantes des couleurs sont codé sur 256 en 24 bits !!!

le moteur de l'unreal warfar3 utilise des texture en 64 bits donc il peuvent tout a fait si ils le veulent fair des couleurs ou chaque composante est codé sur 16 bits soit 65536 valeurs par composantes...

Contrairement a DirectX, la norme openGL est prevu sur le tres long terme, en parti a cause de son orientation professionnelle, ils on donc prevu a l'avance la possibilité d'evolution du matriel, c'est tout.

[ZiZouJH]

ah dans ce cas je m'incline je ne pensais pas que c'était possible

(au fait, évite d'écrire 24 "bites" )

[amaury pouly]

mais alors juste une question, comment on fait pour la faire marcher, j'ai essayé avec plein de valeurs et cela ne marche jamais ?

[ZiZouJH]

concrètement pour glColor3i il faut donner pour chaque paramètre une valeur entre -2147483648 (pour une intensité de couleur nulle) et 2147483647 (pour une intensité de couleur maximale)
enfin apparemment je suis le seul à trouver ça bizarre...

[amaury pouly]

ok mais alors 0 c'est l'intermédiaire donc pas du noir

[ZiZouJH]

c'est du noir pour glColor3ui, enfin je me rappelle plus, à retester avec glColor3i...