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
...
http://es.wikipedia.org/wiki/Double
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
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 :)
Cita de: IthaquaPara 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
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
Cita de: Elvis Enmanuel...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
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.
¿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.
Cita de: zupervaca¿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.
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.
Tened en cuenta que OpenGL no es un API solo para videojuegos. No todas las aplicaciones pueden permitirse el mismo grado de error.
Cierto, OpenGL se usa, y de hecho su antecesor GL, en ámbitos científicos y técnicos. donde la precisión es importante.
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:
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.
Cita de: zupervaca...esto no implica que dentro de unos años la cosa cambie y se comience a usar double internamente en las graficas.
Tienes toda la razón Zupervaca, posiblemente no haga falta tanta precisión, pero puede que al final el mercado nos lo inponga el uso de double porque a lo mejor llegue a ser más eficiente su uso.
Me has hecho recordar una pequeña anécdota que me ha sucedido hace 1 año. Conocí a un profesional en software de defensa en equipos críticos para aviones de combate. Y este señor me contó que el hacía software con aritmética de enteros. Yo me quedé sorprendido y pensé en lo atrasados que estaban. No lo entendía lo que me explicó. Pero ahora gracias a esta introdución que has hecho Zupervaca creo haber entendido la problemática y el trabajo de aquel profesional. Podía trabajar con fiabilidad, estabilidad y con más rapidez que con cualquier CPU moderna de operaciones en coma flotante. (!Qué besugo soy!, menos mal que me aguanté la risa en aquel instante porque si no hubiese pasado por ignorante).
Solo me falta que Elvis Enmanuel nos aclare lo del HALF_FLOAT.
Hace no mas de uno o dos años, unos compañeros de clases y yo tuvimos un problema interesante usando Float en lugar de Double
(Sobretodo porque la escuela toadvía usa Borland Turbo C++ >_>)
Sucede que estábamos resolviendo un problema clásico que involucraba dar cambio al usuario, entre cuyas denominaciones se encotnraban las monedas de 5 centavos.
El problema fue que cuando una cantidad quedaba en... por ejemplo:
$34.55
El turbo C++ estaba terco en que la cantidad era
$34.54999999 ...
Cambiamos los tipos de datos a Double y problema resuelto.
Según la propia ayuda de este anciano turbo C++, el float es de 32 bit, cosa que a todos nos pareció suficiente para 2 miserábles digitos.
Sinembargo, no fue así...
Desde entonces nos quedó la maña de usar siempre double en lugar de float :(
Más vale que sobre y no que falte XD
@zupervaca: has descubierto el maravilloso mundo del punto fijo.
@ALRAZ: _nunca_ se usa punto flotante para trabajar con dinero, sea la precisión que sea. Pregunta a cuaquier economista y te dirá porque.
Yo cuando he trabajado con cifras monetarias he usado siempre enteros, haciendome a la idea de que el número representa céntimos.
Realmente solo hace falta decimales en el momento de presentar externamente la cifra como euros.
half_float_nv o algo asín
La cosa está en crearse una textura de flotantes y almacenar allí la geometría y/o normales, para después interpretarla en el shader (geometry buffers) pero creo recordar que sólo se podía hacer con el shader model 3.0
ains
La gracia del punto flotante es que la precision es mayor cerca del 0 y menor cuanto mas te alejas, con lo que trabajamos con errores relativos de precision, es decir, que una milesima te importa mucho si trabajas con valores pequeños y te da igual si trabajas con millones.
Si estais haciendo un programa cientifico, p.e. un visor 3d de un cuerpo, puede interesarte ir desde una escala de 2m (cuerpo completo) a una de micrometros, con lo que la precision es muy importante (tema de redondeos, acordaos de lo de 35.55 = 35.549999) y pueden ser necesarios los 64bits.
El tema de usar float extensivamente es por lo que ya han dicho: suficiente precision para gran numero de aplicaciones, mayoria de micros de 32bits y sobre todo que es el doble de tamaño. De hecho, en OpenGL se nota mucho usar indices de 32 a 16 bits. Probadlo.
Y los half float simplemente son 16bits en vez de 32. Osea, suficiente precision para algunas cosas y la mitad de tamaño. En deferred shading o hdr y estas cosas, creo que se usa bastante para ahorrar espacio en los g-buffers.
Cita de: tiutiuLa gracia del punto flotante es que la precision es mayor cerca del 0 y menor cuanto mas te alejas, con lo que trabajamos con errores relativos de precision, es decir, que una milesima te importa mucho si trabajas con valores pequeños y te da igual si trabajas con millones.
Gracias por tus aclaraciones tiutiu, en especial lo relativo a la importancia del tamaño de los índices. No había caído encuenta.
Quería preguntarte, ¿entonces, con respecto a la precisión del float, hay que tener algún cuidado especial cuando manejemos un Z-buffer en el que se almacenan distancias pequeñas y muy grandes a la vez?.
Citar@zupervaca: has descubierto el maravilloso mundo del punto fijo
Pense que todos los programadores conocian estas cosas, yo llevo usandolo desde el amiga 500
Editado:
Citarprogramabas en un amiga? que envidia..
Y en un commodore 128 empece mis andaduras :wink:
programabas en un amiga? que envidia..
Esta claro que cualquier operacion con coma flotante acarrea problemas de precision, es el ejemplo clásico de usar un double como variable para un contador..
Lo del fixed point la verdad es que el pan de cada dia en consolas..
El tema de doubles y floats en OpenGL según tengo entendido tiene su origen en que internamente OpenGL trabaja con floats, con lo cual si tu le pasas doubles no solo no aumentarás la precisión sino que penalizará el rendimiento debido a las conversiones de tipos que OpenGL hará por ti para pasar los datos a float.
De todas formas, hay veces que es necesario trabajar con doubles en tu aplicación para no perder precision en los cálculos (eso ocurre al menos en simulación que es donde yo trabajo). Posteriormente puede ser que debas trabajar también con coordenadas relativas a un cierto offset, me explico, si tienes una base de datos a nivel mundial de terreno (imaginate el flight simulator) no puedes pintar en OpenGL en las coordenadas (10000000,10000000,5000), bueno, en realidad si que puedes, sin embargo cuando estes volando te darás cuenta que todo empieza a temblar por la perdida de precisión. Puedes probarlo, hazte una pequeña aplicación que coloque una serie de puntos en unas coordenadas muy grandes y haz que tu cámara avance, notaras como los puntos cobran vida y empiezan a temblar.
Supongo que la nueva generación de tarjetas donde internamente se procesan los datos con mucha mas precisión (nVidia GeForce 7: Full 128-bit studio-quality floating point precision through the entire rendering pipeline) harán cambiar este panorama, pero hasta entonces habrá que tener todo esto en cuenta.
Espero haber arrojado un poco de luz.