¿Cómo puedo visualizar un escenario enorme con OpenGL?
Me explico, estoy empezando a trastear con las 3D y no sé si mi duda es una chorrada o no.
Lo que tengo es un escenario enorme, digamos de unas 10000x10000 unidades (o más) y no consigo configurar los parámetros de la vista para que se vea bien del todo.
Lo ideal sería que los planos de corte fueran 0 - 10000, pero si hago eso los polígonos se muestran como les da la gana, mostrándose los más alejados sobre los más cercanos.
Si pongo 1 - 10000, el efecto es menos desastroso, pero aun así se siguen montando los polígonos.
Solo se ve bien si pongo 10 - 10000, pero entonces tengo otro problema: el plano cercano lo tengo a 10 y los polígonos me desaparecen antes de acercarme a ellos (nooo). Esto solo serviría si estuviera siempre desde el aire.
¿Hay alguna solución?
no te acerques demasiado a ellos, si ves cualqier programa 3d, cuando 'entras' dentro de un modelo, el poligono en el que estas metido solo se dibuja hasta cierta distancia de la camara.
En cualquier FPS puedes pegarte a una pared.
Deberia funcionar bien con 1-10000. ¿Cómo creas la matriz de proyección?
Poner el valor 0 como mínimo de clipping me dio problemas en clase de programación gráfica. Es una gilipollez, pero a mí se me solucionó poniendo 0.000001. Prueba suerte ;)
Lo normal es que el near plane sea más o menos 1.0.
Otra cosa que podría estar causando el problema son los bits que le hayas puesto al depth buffer (16, 24, 32).
Por lo que dices doy por hecho que tienes activado el depth buffer y que lo limpias en cada frame.
En lo referente a que poniendo un near plane de 10 se cortan los polígonos cuando te acercas, si implementas detección de colisiones, podrías ponerle un radio de 10 a la esfera que engloba la cámara. De esa forma evitarías el recorte de polígonos a esa distancia (lo que no sé es si 10 sería una distancia que no permitiría acercarse demasiado a los polígonos...).
Saludos.
CitarDeberia funcionar bien con 1-10000. ¿Cómo creas la matriz de proyección?
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
gluPerspective( 45.0f, 800.0f/600.0f, 10.0f, 10000.0f );CitarEs una gilipollez, pero a mí se me solucionó poniendo 0.000001
A mí no <_<
CitarOtra cosa que podría estar causando el problema son los bits que le hayas puesto al depth buffer (16, 24, 32).
¿Cómo sé lo que tengo y cómo lo cambio?
CitarPor lo que dices doy por hecho que tienes activado el depth buffer y que lo limpias en cada frame.
Sí, o no lo vería bien aunque cambiara los planos.
Citar
En lo referente a que poniendo un near plane de 10 se cortan los polígonos cuando te acercas, si implementas detección de colisiones, podrías ponerle un radio de 10 a la esfera que engloba la cámara. De esa forma evitarías el recorte de polígonos a esa distancia (lo que no sé es si 10 sería una distancia que no permitiría acercarse demasiado a los polígonos...).
Psé... esas 10 unidades son metros. No poder acercarte a menos de 10 metros de una pared queda algo rarillo :huh:
1) Un near plane demasiado pequeño, da errores, nada de 0.00001, con eso solo conseguiras que la mitad de las targetas muestren glitches.
2) Una distancia extremadamente grande entre el near plane y el far plane, tb da problemas. Para eso, opengl acepta floats, doubles, etc. Es decir, nada de 1/10000, escalalo de forma correcta. Yo trabajo normalmente con 0.5f / 100.0f, y no tengo ningun problema.
3) Chequea de cuantos bits es el depth buffer que te devuelve ChoosePixelFormat.
Con esto todo deberia irte bien, a no ser que tengas algun bug no asociado al depth buffer.
Por cierto, esto de arriba lo explica cualquier tutorial/libro de iniciación a opengl, a ver si leemos mas...
1.0 = 1 metro ¿?
entonces 10000 = 10km!!!!!
no crees que quieres ver demasiado lejos? :P
Un truco (un pelin cutre y complicao) seria dibujar todo lo que estuviera a mas de 1000 (por ejemplo) con un near de 1000 y un far de 10000 (por ejemplo) y despues limpiar el z-buffer y dibujar encima todo lo que estuviera a corta distancia (con un near de 0.25 y un far de 1000).
No deberias de tener problemas si no te "rallas" con las distancias :P
Y si aun asi quieres rayarte dale mas profundidad al z-buffer.
haz un
glClearColor(0.0f, 0.0f, 0.0f, 0.0f) ;
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Citar
Una distancia extremadamente grande entre el near plane y el far plane, tb da problemas. Para eso, opengl acepta floats, doubles, etc. Es decir, nada de 1/10000, escalalo de forma correcta. Yo trabajo normalmente con 0.5f / 100.0f, y no tengo ningun problema.
Vale, digamos que lo escalo todo... ¿0.01? 100 veces más pequeño, ¿no? entonces 0.5*100 = 50m ^_^, creo que no soluciono mucho.
Ya he probado a escalarlo, pero si reduzco el mapa y reduzco el plano cercano... como que me quedo igual: Sigo sin poder pegarme a una pared.
Citar
Por cierto, esto de arriba lo explica cualquier tutorial/libro de iniciación a opengl, a ver si leemos mas...
Me imagino que mis distancias dan problemas por los planos de corte, pero en ningún sitio he visto nada de eso.
Citar
no crees que quieres ver demasiado lejos?
Precisamente por eso planteo el problema. Quiero ver 10Km de distancia. Si estuviera a pie no sería un gran problema, pero quiero verlo también desde el aire y necesito verlo todo.
Citar
glClearColor(0.0f, 0.0f, 0.0f, 0.0f) ;
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Ya lo hago.
A ver si esto me ayuda:
Como ya he dicho, estoy pez en esto, así que... ¿por qué no es lo mismo 10-10000 que 1-1000?
Si pongo 10-10000, se ve todo perfecto (salvo que no pueda acercarme a menos de 10 de un muro), pero si pongo 1-1000 se ve todo fatal.
¿No es la misma distancia? :blink:
Citar¿por qué no es lo mismo 10-10000 que 1-1000?
Porque no es lo mismo si cobras 300€ al mes que si cobras 600€? Simplemente, la cantidad es diferente!
En un ordenador, y en todos los sistemas digitales que conozco, el sistema de numeracion es finito, a diferencia de la realidad, con lo cual estas limitado a ciertas cantidades, y hay ciertos errores de precisión (por ejemplo el Epsilon de los floats, etc, etc).
Si hubieras leido algun tutorial, o tuvieras unos minimos conocimientos de programacion, sabrias que 16 bits de depthbuffer, proporcionan baja precision, con lo cual la distancia near plane - far plane no puede ser abismal (ni la precisión en ella). Aunque deberia sobrarte si no haces algo muy tocho. Escala el m* escenario, y pones un near plane mas pequeño, y podras acercate a la dichosa pared. Yo lo he programado centenares de veces, y funciona. Si no es asi, es el momento de comprarte un libro de opengl, y leerlo tranquilamente, yo lo hice en su momento, y es lo mejor.
Cita de: "sés"Citar
no crees que quieres ver demasiado lejos?
Precisamente por eso planteo el problema. Quiero ver 10Km de distancia. Si estuviera a pie no sería un gran problema, pero quiero verlo también desde el aire y necesito verlo todo.
Entonces aumenta el near y el far conforme la camara va dejando el suelo.
En el suelo; near = 0.25 far = 1000
A media altura; near = 10 far = 5000
A mucha altura; near = 100 far = 10000
por ejemplo :-)
Eso seria para dibujar el suelo.
Si despues quieres dibujar cosas en el cielo; borrar el depth buffer, asigna nuevos valores para el near/far y dibuja.
Cita de: "shash"
Porque no es lo mismo si cobras 300€ al mes que si cobras 600€? Simplemente, la cantidad es diferente!
A lo que me refería es que con 10-10000 se ve bien y con 1-1000 no.
10000 - 10 = 9990
1000 - 1 = 999
¿No se supone que la distancia entre los planos es menor y debería dar menos problemas?
Cita de: "shash"
Si hubieras leido algun tutorial, o tuvieras unos minimos conocimientos de programacion, sabrias que...
Vaya, tenemos a un "tío guay" que viene de la demoescene y se cree la repanocha. Tres mensajes en el foro y ya estás haciendo de menos a los demás. Mola.
He leído tutoriales (más bien estoy leyendo), entre ellos el de nehe, que es por el que más me guío, y no he visto nada sobre la precisión de los planos y de que haya que ponerlos pequeñitos.
También te puedo asegurar que sé programar perfectamente. No sé si serás tan bueno como quieres aparentar, pero te aseguro que no necesito los consejos de ningún prepotente.
Cita de: "shash"
Aunque deberia sobrarte si no haces algo muy tocho.
Si leyeras desde el principio, o tuvieras unos mínimos conocimietos de lectura, sabrías que mi problema es precisamente por que quiero hacer algo tocho.
Cita de: "shash"
Escala el m* escenario, y pones un near plane mas pequeño, y podras acercate a la dichosa pared.
Vaya, de nuevo no has leído. Como ya expliqué, si tengo 10 unidades = 10m., si escalo todo (digamos 0.1) y reduzco el plano cercano (digamos 0.1), 0.1 unidad será = 10m, por lo que me quedo igual. Eso se aprende en el cole cuando te enseñan a multiplicar.
Quizás sea el momento de comprar una cartilla y una tabla de multiplicar, y leerlo tranquilamente, yo lo hice en su momento, y es lo mejor.
Una guía de buenas maneras tampoco te vendría mal. Baja esos humos.
Tu problema es que te acabas la resolución del depthbuffer como bien han dicho, juegos como operation flashpoint al tener escenarios tan grandes lo que hacen es usar el W-Buffer que equivale a 1 / Z-buffer, de esta manera la Z cercana a la camara tiene más precisión que la Z que está lejos (obvio si tenemos en cuenta que solo quieres precisión en los objetos cercanos).
De todos modos no veo otra solución si no quieres usar W-Buffer (del que no se gran cosa más) que hacer dos pasadas como comentaban antes, :/
Y shash, no te sobres tanto en tus respuestas que no veo yo que demuestras saber mucho más que él
Gracias, hablaré con mi amigo google a ver que me cuenta.
No son humos ni prepotencia. Yo me pase mis años en una academia aprendiendo C, despues por mi cuenta aprendi pascal, ensamblador (del 8086, del z80, fpu, mmx), C++ y java. Luego escribi un motor 3D por rasterizado por software, luego uno por voxel, un raytracer en tiempo real, 3 motores en opengl, las prods que puedes ver en nuestra web (menos una en la q solo hice 1 pequeña utilidad) y un emulador de gameboy sin terminar, sin comentar un sinfin de utilidades varias. Hablo asi, pq he perdido muchos, muchos años detras del compilador, encerrado en mi habitacion.
Guiarse por los tutos de nehe es un error, yo lo hice cuando me pase a opengl, y acabas mas liado que otra cosa. Comprarse un libro, o leerse el redbook tranquilamente es el camino a seguir. Tener una buena base de programacion es indispensable, meterse a programar un engine sin ella, es acabar liado otra vez. Si puedes, domina mas de un lenguaje, es mejor. La mayoria de los problemas de la programacion grafica los solucionas mas por la experiencia escribiendo programas "normales" que por otra cosa.
Y si, llevo 3 mensages en "estos" foros, aunque eso no significa que no los haya leido desde hace tiempo :P
Mira, simplemente, tienes un problema de precision. Las correciones te las he dicho, escala el tamaño, y yasta. Sino, es algun problema con el pixelformat que usas.
Si por algo no funciona asi, te puedo pasar un ejemplo q muestra q mis palabras son correctas, no tengo problema en subir unos shots de muestra, con los valores usados en la creacion de la matriz de proyeccion.
CitarSi leyeras desde el principio, o tuvieras unos mínimos conocimietos de lectura, sabrías que mi problema es precisamente por que quiero hacer algo tocho.
Alguien que quiere hacer muy tocho, no tiene problemas con el near plane... No es problema de lectura, es ignorarla :P
CitarQuizás sea el momento de comprar una cartilla y una tabla de multiplicar, y leerlo tranquilamente, yo lo hice en su momento, y es lo mejor.
Una guía de buenas maneras tampoco te vendría mal. Baja esos humos.
Ejem, digamos que mejor no comento esta idiotez... No tengo nada que demostrar :)
CitarY shash, no te sobres tanto en tus respuestas que no veo yo que demuestras saber mucho más que él
Ejem, sigue el link de mi firma si quieres ver cosas mias, o en www.pouet.net :P
Cita de: "shash"No son humos ni prepotencia. Yo me pase mis años en una academia aprendiendo C, despues por mi cuenta aprendi pascal, ensamblador.... Luego escribi un motor 3D por rasterizado por software, luego uno por voxel, un raytracer....un emulador de gameboy ... un sinfin de utilidades varias.
(ses)
Vaya... *mira a todos los del foro*. Seguro que aquí nadie ha hecho algo parecido...
Cita de: "shash"
Hablo asi, pq he perdido muchos, muchos años detras del compilador, encerrado en mi habitacion.
Pues sal, hay mundo ahí fuera. Incluso gente que sabe como tú y más y no alardean de ello. La prueba en este foro.
Cita de: "shash"
Guiarse por los tutos de nehe es un error, yo lo hice cuando me pase a opengl, y acabas mas liado que otra cosa.
Quizás ese sea mi error. Como dije desde el principio: estoy empezando con OpenGL.
Cita de: "shash"
Tener una buena base de programacion es indispensable, meterse a programar un engine sin ella, es acabar liado otra vez. Si puedes, domina mas de un lenguaje, es mejor. La mayoria de los problemas de la programacion grafica los solucionas mas por la experiencia escribiendo programas "normales" que por otra cosa.
No quiero hacer ningún motor 3D. Ya domino varios lenguajes, entre ellos ese ensamblador y, creeme, tengo bastante experiencia.
Cita de: "shash"
Alguien que quiere hacer muy tocho, no tiene problemas con el near plane... No es problema de lectura, es ignorarla :P
(ses)
Cita de: "shash"
Ejem, digamos que mejor no comento esta idiotez...
Sí, es una idiotez. NOTA: He repetido tus palabras...
Cita de: "shash"
No tengo nada que demostrar :)
Pues te empeñas de una forma muy curiosa en hacerlo.
Cita de: "shash"
Ejem, sigue el link de mi firma si quieres ver cosas mias, o en www.pouet.net :P
¿Ves? :P
Ok, no quiero seguir con esta dinamica, no soy muy amigo de los flamewars. No soy ni mucho menos el mejor coder que conozco, ya lo sé. Espero que corrijas tu bug, cuando termines tu engine, ya lo vere si se hace publico. Esto me pasa por intentar ayudar...
Eso te pasa por intentar ayudar.... con prepotencia (que es lo unico que te ha sobrado)
Rafa
HEy chicos, trankilos, daros una ducha fría, salir un poco por ahi, y dejar de "discutir".
No soy muy experto en opengl, apenas empiezo, asi que no te voy a decir has esto o haz lo otro. Simplemente voy a tomar una idea que ya te han puesto por aqui. La sólucion parece estar en ir variando las escalas........si cuando estas en el cielo (o muy lejos) con una escala 10-10000 te funciona bien perfecto, si cuando te acercas al objeto te da problemas al rebajar la escala a 1-1000 muy facil, preselecciona objetos...me explico......si te acercas mucho a tierra todos los objetos que hay en el cielo no te sirven, asi que por ejemplo todo lo que haya de 1000 a 10000 no lo dibujes.......haces un cambio de escala, y 1.0 en vez de ser un metro que sea medio, y utilizas una escala 1-2000
No se si mucho de lo que digo tendrá sentido porque ya digo que recién llego al 3d, pero creo que la idea va por ahi xDD
Suerte con ese motor ^_^
Lo del W-buffer es bastante curioso, gracias por el dato tamat.
Creo que he visto por ahi que OpenGL tiene una funcion para renderizar el escenario al reves, es decir, que los valores maximos del z-buffer son los que quedan en primer plano, a lo mejor usando esto y cambiando las coordenadas... No se , a ver si me pongo a buscar la funcion por algun sitio.
Me suena a mí que en DirectX se ha dejado de usar el W-Buffer... alguien que trastee con DX9 que lo confirme o desmienta...
En la documentación de Microsoft DirectX 9.0 SDK Update (Summer 2003) sigue apareciendo el W-Buffer.
Saludos.
linkCierto, pues lo he debido soñar o algo :blink:
Cita de: "Minos"Creo que he visto por ahi que OpenGL tiene una funcion para renderizar el escenario al reves, es decir, que los valores maximos del z-buffer son los que quedan en primer plano, a lo mejor usando esto y cambiando las coordenadas... No se , a ver si me pongo a buscar la funcion por algun sitio.
Yo lo hago con esto: glDepthFunc( GL_ALWAYS );
Con eso incluso me funciona bien con los planos 1.0-10000.0
Me dibuja todos los polígonos "PERFECTAMENTE"... pero justo al revés: los más alejados delante :P Lástima que con GL_NEVER no haga justo lo contrario :P
¿Alguien sabe por qué no me funciona esto?: SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 32 );
El código es el siguiente:
SDL_Init( SDL_INIT_VIDEO );
SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 32 );
SDL_SetVideoMode( 800, 600, 32, SDL_OPENGL | SDL_HWSURFACE );
Mi tarjeta es una ATI Radeon 9600 Pro.
P.D.: Tampoco me deja cambiarlo a 16, siempre está en 24.
Hola sés.
La verdad es que llevo tanto tiempo sin programar que estoy perdiendo facultades pero si no me equivoco, el test de profundidad debería estar en GL_LESSEQUAL (no sé si es así en OpenGL) ya que con GL_ALWAYS siempre se pasa el test y puede ocasionar resultados incorrectos (polígonos que deberían quedar delante, quedan detrás).
Saludos.
Cita de: "sés"¿Alguien sabe por qué no me funciona esto?: SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 32 );
El código es el siguiente:
SDL_Init( SDL_INIT_VIDEO );
SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 32 );
SDL_SetVideoMode( 800, 600, 32, SDL_OPENGL | SDL_HWSURFACE );
Mi tarjeta es una ATI Radeon 9600 Pro.
P.D.: Tampoco me deja cambiarlo a 16, siempre está en 24.
No me hagas mucho caso, pero si no recuerdo mal SDL o OpenGL (no recuerdo de quien era la "culpa") toman ese tipo de valores a modo de "sugerencia". Osea que aunque tu le digas un z-buffer de 16 bits igual te lo ponen de 24....
por cierto, con 24 bits deberias de tener de sobra :P
Cita de: "Lord Trancos 2"por cierto, con 24 bits deberias de tener de sobra :P
Pues parece que no <_<
Pues algo debes de estar haciendo mal... :(
Entiendo que tuvieras problemas con esas distancias y un Z-buffer de 16,... pero con uno de 24.... <_<
Por cierto, yo de ti añadiria los flags SDL_HWACCEL y SDL_DOUBLEBUF al iniciar OpenGL:
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
SDL_SetVideoMode(C_VIDEO_WIDTH, C_VIDEO_HEIGHT, 32,
SDL_HWACCEL | SDL_HWSURFACE |
SDL_OPENGL | SDL_DOUBLEBUF)
Y volviendo al z-buffer....
- que valor le pasas a glClearDepth ?
- llamas a glEnable(GL_DEPTH_TEST) ?
- y a glDepthFunc(GL_LEQUAL) ?
Cita de: "Lord Trancos 2"Pues algo debes de estar haciendo mal... :(
Ya... :(
Cita de: "Lord Trancos 2"Por cierto, yo de ti añadiria los flags SDL_HWACCEL y SDL_DOUBLEBUF al iniciar OpenGL:
Añadidos, pero sigue igual.
Cita de: "Lord Trancos 2"- que valor le pasas a glClearDepth ?
1.0
Cita de: "Lord Trancos 2"- llamas a glEnable(GL_DEPTH_TEST) ?
- y a glDepthFunc(GL_LEQUAL) ?
Sí
¿Resolviste el problema al final?
Prueba a colgar el código a ver si alguien ve el error así.
Por cierto Shas, Sés es de la vieja escuela.
Aun no, dejé esa parte a un lado para hacer el plugin para exportar y últimamente no he tenido mucho tiempo.
Cuando encuentre algo lo pondré por aquí.
sés, has visto este artículo?
http://www.gamasutra.com/features/20020712...12/oneil_01.htmigual te sirve o te da alguna idea.
Por fín.
Resulta que lo que quiero visualizar, además de ser grande (unos 5Km), tiene coordenadas grandes. Vamos, que las coordenadas de la cámara tienen 7 cifras ^_^
He trasladado todo para que la cámara esté inicialmente en 0,0,0 y todo funciona.
No sé... supongo que es una chorrada, pero no se me pasó por la cabeza que afectara. Siempre creí que el Z-Buffer funcionaba con las distancias de los polígonos respecto a la cámara, no sabía que le afectaran las coordenadas absolutas de los polígonos.
En el artículo ese dice:
CitarThe problem with the traditional model and view matrices in the test case outlined above is that both have a very large translation in the X direction. A 32-bit float starts to lose precision around 1000 km, and Earth's orbit is around 149,600,000 km. Even though the camera is close to the planet and the numbers should cancel each other out, too much precision is lost during the calculations to make the resulting matrix accurate.
Es decir que el problema no es del z-buffer, es de la precision de los floats que, cuanto mas pequeños mas precisos pero llegando a números de 7 cifras como los tuyos comienzan a perder precision. Si encima multiplicamos esos números unos por otros (vertices por matrices) ocurren cosas como que todos los vertices entre 5.000.000 y 5.000.002 (por decir algo) acaban siendo calculados como 5.000.001. Si en vez de trabajar con numeros tan grandes, restas de manera que las multiplicaciones a la hora de transformar los vértices se hagan con numeros mas pequeñitos tendrás resultados mas exactos.
Igual era ese tu problema ¿no?
Sí, eso parece, pero no pensé que perdiera tanta precisión.
Al fin y al cabo, las distancias son las mismas. No veo mucha diferencia a dibujar entre 0 y 1000 que entre 1000000 y 1001000.
Y vamos, que 1000000 tampoco me parece un número tan grande.
Por cierto, también probé a utilizar doubles y no noté ningún cambio. ¿No se supone que eso debería hacer algo?
Bueno, como ya dije, estoy pez en todo lo de 3D, así que...
Pues no se, igual lo que está creando confusión es que tu problema no era uno sino dos. El de los floats y el del z-buffer.
Cuando usas un near plane muy cercano a la cámara, por cosas de la perspectiva, tienes una gran precision en los objetos mas cercanos pero una precisión muy mala en los lejanos. Si alejas un poco el plano (una pequeña variación afecta mucho), la precisión se distribuye mas homogeneamente. Hay un link unos mensajes mas arriba en el que puedes esperimentar con valores y comprobar esto. Así que intenta usar siempre un near plane lo mas alejado posible.
Aunque uses doubles para almacenar las coordenadas, al meterlas en las matrices se convierten en floats y el problema vuelve otra vez, a no ser que uses tus propias matrices y lo hagas por software o te inventes un vertex shader que use doubles :blink: . Vamos, que solo te solucionan los problemas que tengas fuera de la pipeline (¿como se dice esto en castellano? ¿tubería?)
Mira,
aquí hay un applet que calcula la representación de un float. Prueba valores de 7 cifras y modifica los decimales, verás que algunos números como 1000000.04 y 1000000.09 se representan igual, es decir en valores del orden del millon la resolución es mas o menos de 0.05 y con 3000000 y 3000000.12 pasa lo mismo, la resolucion en esos números es de 0.12 metros. Cuando llegas a los 5 millones tienes medio metro de imprecisión.
Cita de: "Thenend"Prueba valores de 7 cifras y modifica los decimales, verás que algunos números como 1000000.04 y 1000000.09 se representan igual, es decir en valores del orden del millon la resolución es mas o menos de 0.05 y con 3000000 y 3000000.12 pasa lo mismo, la resolucion en esos números es de 0.12 metros. Cuando llegas a los 5 millones tienes medio metro de imprecisión.
Ya, pero repito que las diferencias en mis unidades nunca eran menor de 1 metro (1 unidad), la mayoría con separaciones de varias unidades. Digo yo, que por mucha precisión que perdiera... no sé, no se me ocurrió... hasta ayer, claro :P
Claro, pero es que al multiplicar por la matriz del mundo, de la camara, la de proyección... todo eso con numeros que no son exactos aunque sea por un decimal, terminas teniendo resultados que son inexactos por varios metros. A mi me ocurrió una vez que lo puse todo en centímetros, los polígonos bailaban que parecía aquello una discoteca :P