Opengl y tipo float

[JL10]

Por qué se insiste en el uso de tipo de datos "float" preferentemente a los de double?, habiendo funciones OpenGL que permite el uso de variables con tipo double?.

No entiendo. Tengo un libro que recomienda el uso de float y sin embargo hace referencia a funciones para "double".

Me podéis aclarar este misterio?.

Gracias

JL10

[Lex]

...

[zupervaca]

http://es.wikipedia.org/wiki/Double

[Vicente]

Yo supongo que es algo parecido a lo que dice Lex, si los procesadores hasta ahora han sido de 32 bits, pues supongo que manejar un float (32 bits) es mucho más eficaz que manejar un double (64 bits). Pero no es que tenga una base científica en lo que digo :p

Un saludo!

Vicente

[Ithaqua]

Para enviar muchos datos de golpe a la tarjeta (mallas por ejemplo) el formato de los datos es bastante crítico.
Échale un ojo a los tests de rendimiento que se publican en algunas webs acerca de los formatos de vértice, en la web de nvidia por ejemplo había cosillas en los docs de vertex buffer objects. Sin tener en cuenta otros aspectos, para empezar con double estás moviendo el doble de cantidad de memoria que con floats :)

[JL10]

Para enviar muchos datos de golpe a la tarjeta (mallas por ejemplo) el formato de los datos es bastante crítico.
Échale un ojo a los tests de rendimiento que se publican en algunas webs acerca de los formatos de vértice, en la web de nvidia por ejemplo había cosillas en los docs de vertex buffer objects. Sin tener en cuenta otros aspectos, para empezar con double estás moviendo el doble de cantidad de memoria que con floats :)

Esto justificaría por qué todos los ejemplos de codigo donde hay tratamiento masivo de vertices están con primitivas  OpenGl en float. Por lo que cuentas, entonces usar variables double tiene justificación para aquellos casos que requiera extrema precisión de datos. Por lo general con float es más que suficiente.

Gracias a todos

[Elvis Enmanuel]

De hecho se le puede pasar un HALF_FLOAT para las normales que no requieran tanta precisión, ahora mísmo el tamaño de los datos es uno de los principales cuellos de botella de las GPUs

ains

[JL10]

...para las normales que no requieran tanta precisión...

ains

Elvis, ...puedes ponerme algún ejemplo para ese caso?. Y por favor, ¿como se obtiene un HALF_FLOAT?.

Un saludo

[marcode]

No me suena lo de HALF_FLOAT, lo que sí es cierto es que se pueden pasar words o bytes, no solo floats y doubles.

en la función: glNormalPointer(  GLenum type,  GLsizei stride,  const GLvoid *pointer);

si type es GL_BYTE, el valor 127 equivaldría a 1.0f, y -127 a -1.0f, de manera que tendríamos un rango aceptable de variacion de normales a un mínimo coste.

Nunca lo he probado por lo que no estoy seguro de que esto funcione exactamente así, aunque no le veo otro sentido. A ver si alguien más puede ampliar este asunto.

[zupervaca]

¿Alguna grafica trabaja internamente con double? a parte de que un doble es el doble de bits que un float como se ve en el link que puse, esto es a tener en cuenta tambien, ya que si las graficas trabajan con float, el driver tendra que realizar una conversion de tipo. Esto tambien se debe aplicar cundo se envia GL_BYTE (byte), etc.

[JL10]

¿Alguna grafica trabaja internamente con double?...

Entonces, por tu pregunta, ¿crees que no hay de momento ningún fabricante de gráficas que empleen el double?. ¿Será porque no hay necesidad, o demanda en el mercado?. Entonces vuelvo a mi pregunta inicial. ¿Por qué OpenGL tiene primitivas para tipos double?. ¿Será para abarcar todos los tipos de datos?. ¿O en previsión de un futuro uso extensivo del double?.

El tema es si merece la pena hacer código con tipos double o float.

[zupervaca]

Yo creo que no, mas o menos tenemos las pruebas delante nuestra, por ejemplo, los shaders trabajan con floats, en concreto con grupos de 4 (x, y, z, w).
Creo y solo creo, no estoy diciendo nada seguro, que los creadores de opengl se quisieron adelantar un poco al futuro que venia, y es que viendo unos años atras realmente no se ha avanzado tanto, ahora mismo con el ritmo real que se llevaba hace unos años deberiamos estar todos con micros de 64 bits y trabajando con double en vez de float, pero me parece que el tema de compatibilidades, y sobre todo el tema del $$$dinero$$$ impide el avance, ya lo decian:
- O vendemos el stock o nos lo comemos
- Para que vender lo ultimo si puedes ir vendiendo pasos intermedios, vease usb1.0 al 2.0; bluethoot 1.0 al 2.0, etc. y ahora aplicalo a micros, graficas, etc.
En definitiva se avanza rapidamente, pero el dinero impide un avance mucho mayor del esperado.

[seryu]

Tened en cuenta que OpenGL no es un API solo para videojuegos. No todas las aplicaciones pueden permitirse el mismo grado de error.

[JL10]

Cierto, OpenGL se usa, y de hecho su antecesor GL, en ámbitos científicos y técnicos. donde la precisión es importante.

[zupervaca]

De poco sirve tanta precision, un ejemplo sencillo, en el arkaretro 3.0 la pelota tiene velocidades inferiores a un pixels, todos saben que el j2me no tiene tipos de datos float ni double, ¿como lo hago? pues muy sencillo, uso variables tipo int multiplicados por un factor, que luego al dibujar los sprites los divido por ese mismo factor, ejemplo:

Código [Seleccionar] Expand


int xspeed8 = 1 << 8;
int x8 = 0;
while(..){ x8 += xspeed8;};
dibujar( x8 >> 8, .., .., .... )

De esta manera xspeed8 y x8 tendran valores mutiplicados 256, mientras que para dibujar uso los valores reales, es decir los dividos por 256, si quiero mas precision pues puedo usar otro factor, pero al final esta claro que a nivel inferior de pixel no se puede dibujar.
En definitiva, podemos trabajar sin floats y sin doubles en 3d, ya que precisamente existen los factores de escala, es decir, el valor 1 podria ser interpretado por 0.1 o por 0.000000001, etc.
En direct3d podrias tener la misma precision si usas double en tu codigo y haces el casting a float antes de dibujar, exactamente tendrias que hacer lo que hace el driver de ogl, no obstante lo dicho, esto no implica que dentro de unos años la cosa cambie y se comience a usar double internamente en las graficas.