Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Front To Back

Iniciado por Loover, 03 de Julio de 2003, 02:46:47 AM

« anterior - próximo »

Loover

 No sé, supongo que muchos ya lo sabaís, pero a mi me ha llamado la atención (vamos, las típicas palabras para evitar decir que no tenía ni guarra):

http://www.nvnews.net/previews/geforce3/oc...n_culling.shtml

CitarAlthough NVIDIA has remained secretive of the occlusion culling technology used in the GeForce3, it's obvious that rendering scenes in a front to back sequence increases performance. The early depth buffer check in the rendering pipeline will reject more pixels from being drawn.

Que resumiendo viene a decir que dibujar la escena de cerca a lejos favorece el "occlusion culling" de la tarjeta y en consecuencia su rendimiento. Pero que además, por las gráficas, se ve que no es moco de pavo.

Yo renderizaba de forma aleatoria (en cuanto a localidad) , excepto las texturas que usarán alpha blending, claro.

Un saludo!
IndieLib Libreria 2.5d utilizando aceleración por hardware para la programación de juegos 2d.
Indie Rover The monkeys are reading!

lemoniac

 Hola,

dibujando de "alanteatrás" realizamos el mismo número de comprobaciones con el z-buffer, pero escribiremos menos veces, ya que los objetos que están más lejos de la cámara posiblemente estén bloqueados por algún objeto que ya hayamos dibujado. El caso pero sería dibujarlos de atrás-adelante ya que seguro que todos los píxels de todos los objetos se van a dibujar aunque luego estén bloqueados (bueno, realmente no todos, pero sí muchos).

Si has leído en algún sitio sobre el motor de Carmack para el Doom III, verás que el primer paso que hace es escribir en el Z-buffer sin ningún tipo de información de iluminación, y de alante a atrás (¿alguna sugerencia de cómo escribirlo?). Luego ya hace los pasos necesarios por cada fuente de luz, pero el z-buffer ya no será modificado. Lo que no sé muy bien es cómo manejará las transparencias o cómo lo harán los tipos del Half-Life 2 para conseguir esas refracciones.

Tendremos que modificar nuestros motores gráficos, aunque seguro que muchos ya lo hacíais.

Un saludo.

Loover

 Gracias por las puntualizaciones :D y bienvenido al foro.

La pregunta ahora es: ¿ha muerto el oclussion culling por software ingual que murió el backface culling? Es decir, ¿tengo que currarme un sistema de oclusión o dejo el asunto en manos de la tarjeta?
IndieLib Libreria 2.5d utilizando aceleración por hardware para la programación de juegos 2d.
Indie Rover The monkeys are reading!

MChiz

 
CitarLa pregunta ahora es: ¿ha muerto el oclussion culling por software ingual que murió el backface culling? Es decir, ¿tengo que currarme un sistema de oclusión o dejo el asunto en manos de la tarjeta?

Evidentemente no ha muerto. Lo que ganas pintando de cerca a lejos es simplemente menos escritura en el frameBuffer, zBuffer, etc. Se gana velocidad, si, pero lo has enviado por el bus y las primitivas se han rasterizado. Detectar oclusiones siempre ira bien, al igual que hacer Frustum Culling y demas : )

Un saludote!

Loover

 
Citarsi, pero lo has enviado por el bus y las primitivas se han rasterizado. Detectar oclusiones siempre ira bien, al igual que hacer Frustum Culling y demas : )

Pero a ver, rasterizar incluye pasar a coordenadas 2d + dibujar ¿no?. (o era sólo dibujar). Bueno, en cualquiera de los casos y si el hardware detecta oclusión (en coordenadas 2d) no dibujará. Por lo tanto no lo rasteriza. Y en consecuencia si el hardware lo hace así de bien... ¿no es esto lo mismo que calcular nosotros mismos la oclusión y mandarlo o no a la tarjeta? Porque vamos, esto ya pasó con el backface culling, que se hace innecesario al hacerlo el hardware.
Vamos, que para detectar oclusión está claro que hay que pasar a coordenadas 2d (¿o no?). Una forma es hacerlo nosotros, y no mandarlo si hay oclusión. Otra, mandarlo, que lo pase a coordenadas 2d y entonces no lo dibuje si detecta oclusión. Yo veo los pasos idénticos...

Una pregunta: ¿Mchiz tu has implementado ya occlusion culling? Que si es que sí estaría genial que pusieras el método que utilizas.

Saquenme de dudas.
IndieLib Libreria 2.5d utilizando aceleración por hardware para la programación de juegos 2d.
Indie Rover The monkeys are reading!

MChiz

 Hola:

Si lo mirasemos de la forma que me hablas, tampoco haria falta hacer Frustum Culling porque el hardware lo hace a nivel de triangulo.

El occlusion culling lo debemos hacer por bloques, objetos o como quieras llamarlo. Si no envias, por ejemplo, 500 triangulos porque estan ocluidos ( todo el bloque ) es mucho mejor hacer tu el test PARA TODO ESTE BLOQUE y no enviarlos.

Yo si que he implementado un algoritmo de oclusiones. No hace mucho lo dije por el foro. Si no recuerdo mal se trataba de un thread que iba sobre como acelerar mas el renderizado.

Un saludote!

Loover

 Ah, pues tienes toda la razón. Esa es la clave, que el hardware lo hace a nivel de triángulo. Y sinembargo, nosotros lo hacemos a nivel de objeto. ¡Claro!

Gracias :D

Voy a buscar ese post, sino lo encuentro te pido más detalles. Por cierto, ¿tienes web con shoots o demos de tu motor? ¿vas a publicar el código?  
IndieLib Libreria 2.5d utilizando aceleración por hardware para la programación de juegos 2d.
Indie Rover The monkeys are reading!

MChiz

 Pues no tengo shoots, pero podria intentar hacer, aunque no es muy bonito de ver... sobre lo de publicar el codigo, no lo creo, lo siento : (
Un saludote y suerte!






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.