Ir al contenido

publicidad

Foto

XNA: Demasiados modelos a renderizar = FPS ridículos


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
4 respuestas en este tema

  • Ollydbg

  • Bahamut

  • vida restante: 100%
  • Registrado: 05 sep 2008
  • Mensajes: 6.259
#1

Escrito 12 junio 2011 - 20:13

Buenas,
Tengo un "mapeado" de 256 x 256 "cubos", o lo que es lo mismo, 65.536 "cubos"

Cada cubo es de 200x200x200 "unidades" de alto x ancho x largo

Tengo un FarPlaneDistance de 25.000 "unidades"

Si renderizo esos 65.536 el programa se cuelga (bueno, no se cuelga pero los FPS tienden a 0)

La primera "optimización" (por decirlo así) es dibujar solo aquellos "cubos" que estan dentro del viewFrustum (usando BoundigSpheres y mirando si están dentro del mismo)

En este caso y con el FarPlaneDistance anteriormente citado el número máximo de "cubos" es de unos 9000

Los FPS en este caso han subido de 0 a 8 FPS, lo cual es una mejora pero no deja de ser un asco :)

He probado de hacer "Occlusion Queries" sobre esos 9000 cubos para que teóricamente los "cubos" que están "detras de otros cubos" no se dibujen.
Al intentar hacer 9000 queries el programa vuelve a "colgarse" y paso de mis maravillosos 8 FPS a 0:cabreado:

He estato mirando esto (mesh instancing por hardware) pero tampoco saco nada en claro. No veo como hacer un "hardware instancing" de modelos distintos (con distintas texturas)

En este video se puede ver más o menos lo mismo que quiero conseguir

Hay un comentario interesante:

How are you actually doing the rendering? Raycasting/octree? Painters algorithm? Do you have the entire visible area in a vertex buffer? Or the entire area around you in a vertex buffer? Do you have any special rendering order for these blocks? Looks awesome!


a lo que el autor responde:

The rendering is actually really basic at the moment. I divide the terrain in chunks of 16x16x128 blocks (x,y,z). The whole terrain in this video is 16x16 of these chunks. For each chunk I have a vertex/index buffer that has only the visible cube faces of that chunk in a custom vertex format to reduce its memory footprint. I just draw all these chunks (with view frustum culling culling).

Oops, I meant 33x33 (x, z) chunks.


16 x 33 = 528

Entiendo que en este caso, el autor de ese vídeo tiene un "mapeado" de 528 x 528 cubos
y ademas de 128 cubos de "altura", lo que da un total de 528 x 528 x 128 = 35 millones de cubos

¿A que se refiere que tiene un custom vertex format?

En lenguaje de "andar por casa" alguien me podría explicar esa respuesta?

Saludos.

  • The_Hans

  • Anima

  • vida restante: 100%
  • Registrado: 27 ene 2004
  • Mensajes: 7.490
#2

Escrito 13 junio 2011 - 10:33

Creo que el camino que tienes que seguir es el mesh instancing pero no es algo que haya hecho nunca, así que no estoy seguro. Yo le daría vueltas a eso :P

  • malditis

  • Neonate

  • vida restante: 100%
  • Registrado: 07 feb 2006
  • Mensajes: 68
#3

Escrito 13 junio 2011 - 11:46

Desconozco la técnica a usar pero en cualquier caso mandar todo eso a renderizar es una salvajada.

He visto que ponias algo de raycasting/octree, me parece que es una buena opción para eliminar cubos. Investiga por esa linea...

Divide tu matriz inicial en bloques de cubos mas pequeños para formar un octree, y en vez de comprobar cada cubo pequeño con el frustum, compruebalo con un grupo de cubos mas grande y cada grupo de cubos lo mandas a pintar por separado.

Otra optimizacion que se me ocurre, para cada grupo de cubos marca como no visible a los cubos que esten completamente rodeados por otros cubos. De forma que no los envies a renderizar, esto es una informacion estatica asi que es facil de calcular y evita un monton de calculos.

  • Ellolo17

  • Zodiark

  • vida restante: 100%
  • Registrado: 16 nov 2006
  • Mensajes: 6.208
#4

Escrito 13 junio 2011 - 20:03

No te crees un objeto por cada cubo. Eso "mata" al motor.

Me hice un par de pruebas. En una creaba por cada vuelta de bucle un vikingo en 3d y le hacia girar sobre si mismo, medía los poligonos, los objetos y los fps de esa escena.

Básicamente lo que hacía era crearme un objeto de cada vikingo. Luego en otra prueba lo que hice fué en vez de hacer un objeto por cada modelo 3d, solo había un modelo 3d pero instanciado varias veces (en realidad, habñia varios punteros al mismo objeto que tenía el objeto 3d, O algo de eso, esta prueba la hice hace mas de un año aunque en el mismo pc que uso ahora mismo)

En total el resultado de la primera prueba es que con 70.000 poligonos llegaba a 32 fps y ahi se paraba (era para optimizar, no para ver cuanto aguantaba el pc), con la segunda logré llegar a los 400.000 poligonos o más.

Mas o menos mi primera prueba por lo que veo siguiendo la distribución es como lo que tienes tú, mira a ver como hacer algo como esto para lograr más poligonos en pantalla ;) Tus 65.000 cubos equivalen a 393,216 poligonos, que es mas o menos lo que tenia yo, solo que con lo mio aun tenia 32 fps en un ordenador que tiene dos años y usando un motor menos optimizado que XNA.

Y aun así en tu caso lo puedes optimizar mucho mas. Imagino que estás intentando hacerte un minecraft. Pero en realidad lo que tienes que hacer es que los que estan bajo tierra ni existen. Si has visto pruebas de cómo esta hecho minecraft ves que cuando se mueven con no-clip, no existen cientos de cubos por debajo, si no que solo estan en un principio los de la superficie.

A la hora de generar la matriz de la etapa haz que el valor con el que lo inicializes no se dibuje y que solo cree la superficie. Luego al cavar se cambiaría el valor de los espacios adyacentes al espacio cavado y se crearían sus cubos.

Ya dirás ;)

  • malditis

  • Neonate

  • vida restante: 100%
  • Registrado: 07 feb 2006
  • Mensajes: 68
#5

Escrito 14 junio 2011 - 00:44

No te crees un objeto por cada cubo. Eso "mata" al motor.

Me hice un par de pruebas. En una creaba por cada vuelta de bucle un vikingo en 3d y le hacia girar sobre si mismo, medía los poligonos, los objetos y los fps de esa escena.

Básicamente lo que hacía era crearme un objeto de cada vikingo. Luego en otra prueba lo que hice fué en vez de hacer un objeto por cada modelo 3d, solo había un modelo 3d pero instanciado varias veces (en realidad, habñia varios punteros al mismo objeto que tenía el objeto 3d, O algo de eso, esta prueba la hice hace mas de un año aunque en el mismo pc que uso ahora mismo)

En total el resultado de la primera prueba es que con 70.000 poligonos llegaba a 32 fps y ahi se paraba (era para optimizar, no para ver cuanto aguantaba el pc), con la segunda logré llegar a los 400.000 poligonos o más.

Mas o menos mi primera prueba por lo que veo siguiendo la distribución es como lo que tienes tú, mira a ver como hacer algo como esto para lograr más poligonos en pantalla ;) Tus 65.000 cubos equivalen a 393,216 poligonos, que es mas o menos lo que tenia yo, solo que con lo mio aun tenia 32 fps en un ordenador que tiene dos años y usando un motor menos optimizado que XNA.

Y aun así en tu caso lo puedes optimizar mucho mas. Imagino que estás intentando hacerte un minecraft. Pero en realidad lo que tienes que hacer es que los que estan bajo tierra ni existen. Si has visto pruebas de cómo esta hecho minecraft ves que cuando se mueven con no-clip, no existen cientos de cubos por debajo, si no que solo estan en un principio los de la superficie.

A la hora de generar la matriz de la etapa haz que el valor con el que lo inicializes no se dibuje y que solo cree la superficie. Luego al cavar se cambiaría el valor de los espacios adyacentes al espacio cavado y se crearían sus cubos.

Ya dirás ;)


Un apunte, la cantidad de poligonos influye pero no es lo que mas pesa para matar el rendimiento... es la cantidad de pixeles... puedes tener miles de triangulos pequeñitos que supongan pocos pixeles e ira bien...

Asi que lo importante es limitar la cantidad de cubos, que vas a mandar a la tarjeta, a los que tienen posibilidades de visualizarse.


Este tema ha sido archivado. Esto significa que no puedes responder en este tema.
publicidad