Escenarios Grandes

[tamat]

 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

[sés]

 Gracias, hablaré con mi amigo google a ver que me cuenta.

[shash]

 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.

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.

Alguien que quiere hacer muy tocho, no tiene problemas con el near plane... No es problema de lectura, es ignorarla :P

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.

Ejem, digamos que mejor no comento esta idiotez... No tengo nada que demostrar :)

Y 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

[sés]

 

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...

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.

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.

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.

Alguien que quiere hacer muy tocho, no tiene problemas con el near plane... No es problema de lectura, es ignorarla :P

(ses)

Ejem, digamos que mejor no comento esta idiotez...

Sí, es una idiotez. NOTA: He repetido tus palabras...

No tengo nada que demostrar :)

Pues te empeñas de una forma muy curiosa en hacerlo.

Ejem, sigue el link de mi firma si quieres ver cosas mias, o en www.pouet.net :P

¿Ves? :P  

[shash]

 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...

[rafaware]

 Eso te pasa por intentar ayudar.... con prepotencia (que es lo unico que te ha sobrado)

Rafa

[shephiroth]

 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 ^_^

[Minos]

 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.

[Grugnorr]

 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...

[BeRSeRKeR]

 En la documentación de Microsoft DirectX 9.0 SDK Update (Summer 2003) sigue apareciendo el W-Buffer.

Saludos.

[Grugnorr]

 link

Cierto, pues lo he debido soñar o algo  :blink:

[Lord Trancos 2]

 Un link interesante:

http://www.sjbaker.org/steve/omniv/love_yo...r_z_buffer.html

[sés]

 

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

[sés]

 ¿Alguien sabe por qué no me funciona esto?: SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 32 );

El código es el siguiente:

Código [Seleccionar] Expand

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.

[BeRSeRKeR]

 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.