Porque desaparecen los personajes eliminados en los videojuegos

[shenmue]

Buenas. Mi pregunta es bien simple. En todos los videojuegos cuando matas a un enemigo este desaparece al cabo de los 10 segundosunos,1 minutos o 5 minutos. Tarde el tiempo que tarde, el enemigo desaparece lo cual me revienta porque le quita mucho realismo al juego. Porque no pueden quedarse en el suelo, como señal de que hemos pasado por ahí, sin que desaparezcan. Es porque cuestión de memoria o algo así, ¿no? Sé que la pregunta es rara, pero siempre me ha intrigado.

[Chaman]

Pues, entre otras cosas, porque dibujar un personaje que solo es decorativo una vez muerto, con la carga que ello supone, no es muy rentable en término de los fps.

Y supongo que, dependiendo de la lógica del juego, esta situación puede suponer en algunos casos un conflicto.

No obstante, un programador de juegos podrá arrojar más luz sobre el asunto.

[HalfVector]

Pues sí, básicamente es lo que ha dicho Chamanman. ¿para qué renderizar polígonos que no afectan (tal vez existan excepciones) al gameplay? Ya sé que no es muy realista, pero.

Y no sólo se dejan de renderizar. En la mayoría de los casos, la física (colisiones, Ragdolls, etc) también suele desactivarse para esos modelos. Saludos.

[Caronte]

Es para no añadir geometría extra (prácticamente innecesaria) a la escena, ya que haría que todo fuese más lento a medida que más muertos hubiesen.

Ten en cuenta que en un juego se pretende usar el máximo número de recursos en mostrar personajes y escenarios de calidad cada vez mayor, por lo que sería una tontería desperdiciar miles de polígonos en cada muerto y que luego el movimiento fuese a saltos.

Al final llegara el día en que esto no pase, pero para eso aún faltan unos años.

[shenmue]

Pero es que, a mí no me mola entrar en una sala matar a 12 bichos a punta de metralleta, ir a la sala de al lado y luego volver a la sala donde se ha producido la mantanza y ver que está tan inmaculada como si hubiese pasado donlimpio. ¿dónde está el rastro de mi intervención¿en juegos como halo, mantienen al menos la sangre en suelo, aunque el bicho desaparezca.

También es que yo soy de lo que se tira, por ejemplo, 3 horas mirando la textura de una pared, preguntándome si lleva Normal Map o no, o mirando la malla de un personaje, y pasando del juego por completo.

Pero aun así, desde aquí revindico a los programadores que den más realismo a los cuerpos caídos y no los dejenen a manos de donlimpio.

[shenmue]

Al final llegara el día en que esto no pase, pero para eso aún faltan unos años.

Y con las consolas de última generación no podría pasar ya?

[Caronte]

No, justamente por lo que te he dicho, lo que se busca es un realismo extremo, y como todavía no se ha llegado a la calidad cinematográfica 100% pues.

Piénsalo de este modo:
Si hoy en día se modificara el Doom (versión 1) para que todos los muertos quedasen en el sitio, el juego iría perfecto y se podría hacer con total seguridad, pero, la calidad de los mismos ya la conocemos y no está ni de lejos a la altura.

[Caronte]

Soy de lo que se tira, por ejemplo, 3 horas mirando la textura de una pared, preguntándome si lleva Normal Map o no, o mirando la malla de un personaje, y pasando del juego por completo.

Vaya, yo también.

[shenmue]

Caronte me consuela saber que haces lo mismo gracias. Vale, pero entonces el problema técnico cual es? No creo que sea por el número de polígonos que aumentan si se dejan ahí, porque la tarjetas gráficas de última generacin mueven miles de millones de polígonos, a no ser que cada personaje tenga millones de polígonos(cosa que no sucede). Entonces que es¿la memoria? Tiene algo que ver con la ramío que pasa. Ya sé que estoy haciendo preguntas que quizá nada tengan que ver, pero es que, justamente no tengo ni idea de cómo funciona la cosa.

[HalfVector]

La memoria no es ya que los modelos son instancias. Sólo hay una copia del Mesh en memoria. El número de polígonos tampoco debería ser un gran problema ya que las aceleradoras hoy día son capaces de renderizar millones de polígonos sin enterarse. Además, no todos los personajes muertos se ven en todo momento sino que se descartan a través de su bounding box de forma rápida y así no se renderizan.

El limitador hoy día suele ser la complejidad del píxel Shader que se utilice para renderizar esos modelos. Si tenemos que esos modelos utilizan Shaders muy complejos, sí que se puede producir un bajón en el rendimiento. Eso sí, siempre y cuando el modelo (s) ocupe (n) un porcentaje considerable en pantalla y hayan muchos visibles en el mismo frame. Evidentemente se podría utilizar un Shader menos complejo (por ejemplo, que haga iluminación per-vertex en vez de per-pixel) para los personajes muertos o, por ejemplo, dependiendo de la distancia a la que estén.

Por cierto, yo también me fijo más en el aspecto técnico que en el juego en sí. Seguramente por eso prefiero programar motores gráficos a juegos. Saludos.

[Caronte]

Todo influye:
la memoria:
en el momento se llena la de la gráfica, todo va muchísimo más lento porque tiene que pasar desde la Ram de sistema.
los polígonos:
Aparte de que los personajes de juegos de última generación tienen mucho polígonos, también se usan a veces sistemas similares a la subdivisión de superficies y todos esos polígonos hay que contarlos también, además, si no postura una buena rutina de Lod un escenario enorme puede contener muchos polígonos si hasta dónde alcanza la vista es muy lejos y la escena es detallada.
las deformaciones de la malla mediante huesos:
Ya que esto no lo calcula la gráfica, si no el procesador.

Las físicas, la IA, etc.

Edito:
Halfvector tiene razón en cuanto a la memoria, ya que se supone que todas las texturas de los enemigos de un nivel ya están en la gráfica y el número de enemigos no hace aumentar el consumo si usan siempre las mismas.

[shenmue]

Con la excusa del miércoles empiezo a trabajar en esto de los videojugos, me he comprado una Xbox 360 y me descargue la demo de kameo. Técnicamente es bueno, sobre todo con las texturas, no sé si lo habréis visto o que, pero usan algo en las texturas que no creo que sea Normal Map a secas, tiene que ser algo mucho más potente porque realmente pare que estén en 3d, no hace flata hacer una prueba de iluminación, se ve a simple vista, bueno, el caso, os adjunto una imagen del juego, no se ve muy bien, pero se divisan centenares de personajes a la vez. Pues he jugado ese nivel, y es la ostia ver cómo arremetes con el caballo contra cientos de trols en pantalla. Así que pregunto, qué más da que estén en el suelo estáticos tras matarlos, que el que estén con vida dando tumbos por la pantalla¿y ya dejo de daros el coñazo con esta cuestión, es que me interesa saber ese tipo de cosas más que el propio juego. Caronte,halfvecto veo que me entendéis.

[Fiz3d]

Yo también pienso que es por eso, un personaje de unos 4000, 5000 o 7000 polígonos con su Normal Map, su especular, su Diffuse, algunos con reflejos y ahora incluso con AO y sub surface scatering, hace demasiadas llamadas a tarjeta y llamadas muy pesadas, no por la carga de polígonos que eso ahora mismo no es un gran problema, pero los Shaders, sobre todo píxel shader, es lo que trae de cabeza al mundillo.

Tu mismo lo dices Shenmue, te quedas parado viendo un normal, una pared o un reflejo, si tienes un contador frames por segundo verás cómo descienden, y vaya, solo estas viendo una simple pared, ¿Qué pueden será dos polígonos, eso más unos cuantos que se pintan, aunque no se vean, pero amigo, esa pared tiene píxel shader, y eso es un cálculo complejo que se está ejecutando por cada píxel que ves en pantalla, pues ahora imagina lo mismo, pero con 7000 polígonos, más el ragdoll, porque claro, si el tipo queda ahí tirado se le dispara a ver cómo se mueve, también queremos que se pinte la sangre en la ropa del tipo, algunas partículas para salpicar, muchas de esas cosas se las come el micro, menos mal que los muetos no necesitan inteligencia artificial si no otra cosa más a calcular, y cualquier juego por muy potente que sea frameara parecería un pase de diapositivas, y los grandes estudios no se arriesgan a eso ni en sueños,tampoco se puede arriesgar dejar el Lod con menos calidad porque eso quedaría feo, con lo cual los personajes desaparecen, en el quake4 hacen un efecto chulo.

Además, ten en cuanta que los juegos no se hacen solo para las últimas tarjetas de últimisima generación, los que se hacen ahora se hacen para que funcionen en las gráficas de ahora, que cuando salgan no serán de última generación.

De todos modos, con el Cryengine y algún otro motor que hay por ahí estos problemas desaparecerán poco a poco, y verás a tus víctimas en todo su explendor. Saludos y enhorabuena por el curre, te darás cuenta que hacer videojuegos no es lo mismo que jugar con ellos, pero también tiene su encantó.

[Chaman]

Saludos y enhorabuena por el curre, te darás cuenta que hacer videojuegos no es lo mismo que jugar con ellos, pero también tiene su encantó.

De hecho, es más entretenido (por lo menos para mí, que no soporto jugar a videojuegos).

[HalfVector]

Ahora que hablas de las hordas de orcos, cuento algo que tal vez os pueda parecer interesante. Hasta la llegada de los Shaders, tanto la transformación de los Bones como el skinning (deformación de la malla en base a esos Bones y los pesos) se hacían por software.

Luego aparecieron los vertex Shaders y el skinning se empezó a llevar a cabo en la GPU a través del vertex shader. En cambio la transformación de los Bones se seguía llevando a cabo en la CPU. Aun así, debido a la limitación de pesos que se suele imponer para poder hacer el skinning por hardware (4 pesos por vértice, que normalmente es más que suficiente) y el hecho de que por cada pasada de render la GPU tenía que volver a recalcular la transformación de la malla, algunos juegos siguen llevando a cabo el skinning en la CPU. Por ejemplo, dom3 lo hace así. Eso sí, con rutinas en ensamblador para acelerar el proceso lo máximo posible.

La verdad es que he estado hablando en pasado, pero estas técnicas siguen siendo las más comunes. La que viene a continuación es la que es muy novedosa y por lo tanto no está muy extendida aún.

La técnica en cuestión recibe el nombre de render todo vertex buffer (r2vb), que consiste en aprovechar la inmensa capacidad de cálculo de las múltiples unidades de píxel Shading (mucho mayor que la cualquier cpu) disponibles en la GPU. Así que ahora, las texturas se utilizan para mucho más que almacenar colores. Ahora se puede almacenar cualquier atributo. En el caso de la animación esquelética se pueden almacenar las matrices de los Bones en cada píxel de la textura y luego en el píxel Shader calcular las matrices de transformación finales para cada clave de animación. Finalmente esa textura se pasa al vertex Shader y ahí se transforman los vértices por las matrices de transformación.

Esta técnica tiene varias ventajas. Una es la que he mencionado, la GPU tiene un poder de cálculo bestial, por lo que los cálculos se realizaran más rápido que en la CPU. Eso quiere decir también que todos los cálculos se realizan en la GPU por lo que nos evitamos el trasiego de datos cpu->GPU. Además, nos ofrece la posibilidad de realizar la transformación una sola vez y reutilizar todo eso en las subsiguientes pasadas de render (depth pass, shadow pass, lighting pass, etc). Otra ventaja es que la limitación de 4 pesos por vértice debería desaparecer.

Evidentemente está técnica se puede utilizar para más cosas. Por ejemplo, tener sistemas de partículas de cientos de miles de partículas calculándose exclusivamente en la GPU. Por ejemplo, en el SDK de Ati hay una demo que utiliza una textura (render target) de 1024 por 1024, lo que da la posibilidad de meter 1.048.576 partículas. En mi aceleradora (Radeon 9600 XT, que no es gran cosa a la altura que estamos) va petado con esa cantidad de partículas (unos 9 fps), pero con unas 100.000 partículas va a unos 60 fps, que no está nada mal.

En fin, que la cosa está muy interesante. Y ya veréis con la salida de DX10 y las aceleradoras compatibles. Saludos.