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.

-- IMÁGENES ADJUNTAS --

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

[shenmue]

Vaya, quería respuestas y he recibido respuestas. A pesar de no haber entendido ni la mitad de lo que habláis, me doy cuenta de todo el cantidad que hay detrás. Al menos entre programadores os entendéis. Yo os seguiré leyendo, aunque no entienda ni papa.

[Caronte]

No os perdáis tampoco las nuevas tarjetas dedicadas al cálculo de físicas, que no tardarán mucho en estar incluidas en la propia gráfica.

Posdata: Shenmue, los cientos de orcos en la lejanía, yo diría que son prerenderizados.

[Klópes]

Vaya, esto es un hilo interesante para una pregunta aparentemente simple. A mí se me ocurre una razón mucho más intrascendente para que los personajes desaparezcan, y es la razón estética: no he visto los juegos más avanzados, pero hasta lo que he jugado, iguales personajes tienen igual forma de morir: los movimientos de caída y terrible agonía son exactamente iguales, incluso en distintas especies de enemigos aprovechan las mismas acciones para no repetir trabajo. Es raro el juego en el que aparecen más de dos muertes distintas (excepción de la rana de los huevos), y eso supone que, si hay varios muertos, resultan varios cuerpos en la misma posición (¿os acordáis cuando matabais 10 imps del Doom con la submachingun y quedaban 10 dibujos flotando todos iguales?), lo que me recuerda dolorosamente a una textura tileable mal echa en una fachada enorme. Pura estética.

[Caronte]

Es raro el juego en el que aparecen más de dos muertes distintas.

Eso era antes, en los juegos de última generación se suele usar la física y los muertos caen y sus articulaciones interactúan realistamente con el entorno.

[Klópes]

Eso era antes, en los juegos de última generación se suele usar la física y los muertos caen y sus articulaciones interactúan realistamente con el entorno.

Sí, eso puede ser verdad en los juegos más avanzados, pero no creo que sean tantos.

[Pit Matson]

Yo sólo he jugado a uno en mi vida, y como desintegrabas a los malos, no me extrañó.

[Klópes]

Pit, en el buscaminas el que muere no es el malo: eres tú. Aunque, pensándolo un poco.

[shenmue]

Posdata: Shenmue, los cientos de orcos en la lejanía, yo diría que son prerenderizados.

Qué quieres decir con prerenderizados. Que forman parte del decorado de fondo? Porque no es así. Yo he probado el juego y te digo que te metes montado a caballo en medio de todo el cantidad de esos orcos en tiempo real, y los vas barriendo del camino a tu paso. Hay tanto que ni puedes ver el suelo. Se sale.

[Josich]

Este hilo me parece muy interesante. Sobre todo, tu ilustración Halfvector, cuéntanos más. En que consiste el Pixel Shader y el vertex shader, comprendo un poco por encima de que va, pero no acabo de comprender del todo. Seria como dar forma a una geometría a partir de textura? O me he hecho un lío?
Últimamente estoy pensando cambiar de tarjeta gráfica por que muchos juegos me pide esa opción que mi Quadro 4 550 XGL 64 Mb no tiene. Merece la pena cambiar para tener esas opciones o va a salir algo nuevo mucho mejor en breve? Un saludo.

[Chaman]

Qué quieres decir con prerenderizados. Que forman parte del decorado de fondo? Porque no es así. Yo he probado el juego y te digo que te metes montado a caballo en medio de todo el cantidad de esos orcos en tiempo real, y los vas barriendo del camino a tu paso. Hay tanto que ni puedes ver el suelo. Se sale.

Es factible que los orcos sean personajes. Si tienen pocos polígonos y Shaders simples, hoy en día puedes meter orcos a cascoporro. En estas situaciones, no impresiona que un personaje tenga un Shader chachirecatore, sino la sensación de verte rodeado por miles de muñecos.

[HalfVector]

Bueno, lo que dice Caronte es una posibilidad. El nombre que recibe la técnica es impostors. Por ejemplo, se suele utilizar para render de terrenos con mucha vegetación. Los árboles, a una cierta distancia pasarían de ser geometría a simples billboards (quads que encaran constantemente la cámara).

Otra posibilidad (aunque tal vez poco probable por lo costos a que puede llegar a ser) es utilizar un algoritmo que es capaz de simplificar al máximo un modelo, pero sin que la silueta se vea afectada (o al menos no demasiado). El modelo sería plano (con un determinado número de triángulos coplanares) pero mantendría su silueta vista desde la cámara. Pero como digo, me parece poco probable. Además, lo que se tiende es a descargar la CPU para pasar el mayor número de cosas posibles a la GPU, no lo contrario.

De hecho, hay cosas como simulaciones físicas e incluso temas de inteligencia artificial que se están empezando a calcular en la GPU por la misma razón (y utilizando técnicas similares) que comentaba en el mensaje anterior. La GPU tiene una capacidad de cálculo inmensa. Es más, algunos motores de física conocidos están empezando a hacer uso de la GPU para acelerar los cálculos. Por ejemplo, la gente de Havok está empezando a utilizar la GPU y, por ejemplo, el creador de newton también está pensando en hacer uso de las mismas. Incluso el vicepresidente de Havok dice que el camino a seguir son las GPU y no las pu (physics processor unit), aunque esto habrá que verlo. Si bien es cierto que con los sistemas SLI de Nvidia y el Crossfire de Ati se pueden tener dos aceleradoras trabajando en paralelo, con lo que eso conlleva.

Con respecto a los vertex & píxel Shaders. Son pequeños programas que se ejecutan en la GPU (lo de pequeños va siendo menos cierto conforme pasa el tiempo). Se pueden programar en diferentes lenguajes (ensamblador, hlsl, GLSL, stanford SL, etc). Estos lenguajes tienen instrucciones muy especializadas para llevar a cabo operación sobre vértices y píxeles. O sea que tenemos instrucciones para multiplicar vectores con matrices, matrices con matrices, calcular productos escalares, productos vectoriales, acceder a texturas, etc. Todas estas operación, al tratarse de hardware muy especializado, se llevan a cabo más rápido que en una CPU.

Concretamente, los vertex Shaders realizan operación sobre los vértices. En ellos puedes mover los vértices, rotarlos, transformarlos de un espacio a otro, y básicamente preparar todo lo necesario para que luego el píxel Shader pueda llevar a cabo sus cálculos. Por ejemplo, calcular el Vector que va de la luz al vértice, el Vector que va de la cámara al vértice, etc. En las primeras versiones, la mayor parte de los cálculos se llevaban a cabo en los vertex Shaders y los píxel Shaders se limitaban a realizar cálculos muy básicos (combinar colores, básicamente). De forma que la iluminación se solía llevar a cabo en el vertex Shader (per-vertex lighting). Actualmente es todo lo contrario, los vertex Shaders suelen ser bastante simples y es en el píxel Shader donde se llevan a cabo las operación más costos a. Es por eso que actualmente el procesado de la geometría no suele ser un problema para la GPU. El problema es el Shading de esa geometría. Es lo que ha mencionado antes Fiz3d. Si tú te pones delante de una pared, puede que esa pared esté formada por tan sólo 2 triángulos, pero resulta que a lo mejor el juego se va arrastrando. ¿por qué? Pues porque la dichosa pared tiene aplicado un píxel Shader bestial que se está ejecutando por cada píxel de la pantalla. Es decir, que el porcentaje de pantalla que ocupe un modelo con un determinado shader, va a condicionar el rendimiento del juego. Si ese modelo esta a mucha distancia, no hay problema, pero si esta delante de la cámara, el frame rate puede llegar a descender en picado.

Más o menos ya he comentado cosas sobre los píxel Shaders (fragmento Shaders en la jerga de OpenGL). Realizan operación a nivel de píxel (o fragmento) y en la mayoría de los casos son los culpables de que os quedéis embobados cuando veis esos gráficos tan espectaculares (eso y la mano del artista, por supuesto). Actualmente todos los cálculos de iluminación se llevan a cabo aquí, es decir, en los píxel Shaders se calculan las componentes Diffuse y Specular de la iluminación, las reflexiones, las refracciones, etc. También se empieza a utilizar Raytracing y otras técnicas como el ray marching para el cálculo de efectos volumétricos. Por ejemplo, hay una técnica denominada Occlusion Paralláx mapping que utiliza algo similar al ray marching y permite resultados mucho más realistas que el normal mapping. Con esta técnica realmente pareciera que estas viendo relieve en un sitio cuando realmente sólo se trata de un plano.

Otra cosa de la que se encargan exclusivamente los píxel Shaders es de los efectos de postproducción, es decir, glares, Bloms, Depth of Field, Motion Blur, etc.

Otra cosa que ha mejorado desde los primeros días de las GPU programables es la capacidad de realizar operación en coma flotante en el píxel shader. Antes la cosa se limitaba al rango [0,1], pero ahora se permiten rangos mucho mayores (high dynamic range, HDR). Esto ha llevado a lo que he mencionado antes, la posibilidad de utilizar los píxel Shaders para cosas que no tienen nada que ver con lo que se idearon en un principio. Por ejemplo, cálculo de colisiones, búsqueda de caminos para la IA, dinámica de fluidos, dinámica de partículas, simulación de telas, pelo, etc.

Y luego está el futuro próximo. Dx10 y el nuevo Shader model 4. Con el vendrá un nuevo tipo de Shaders, los geometry Shaders. Hasta ahora no era posible crear o destruir geometría dentro de la propia GPU, pero con los geometry Shaders ya será posible. Además, se podrá empezar a hacer displacement mapping real. E incluso puede que empecemos a ver algoritmos de Lod (level of detail) ejecutándose completamente en la GPU. Podremos crear sistemas de partículas complejos donde de una partícula nazcan nuevas partículas (esto en una GPU es una novedad). En fin, un nuevo abanico de posibilidades se abrirá ante nosotros.

Otro avance que se avecina es la unificación de los Shaders, es decir, no habrá diferenciación entre vertex & píxel Shaders, sino que todo se llevara a cabo en un sólo shader. Como siempre digo, seguimos los pasos de la especificación RenderMan.

Josich, en cuanto a cambiar de aceleradora, no sabría decirte. Creo que ha finales de año (casi con la llegada de Windows Vista) esta previsto que salgan las nuevas aceleradoras con soporte para el Shader model 4 y DX10. Lo que pasa es que tienen que costar una pasta. Además, los juegos tardarán en exprimirlas, así que, si quieres cambiar de aceleradora, pilla una con Shaders 3.0. Si quieres Ati, una de la serie x1000 (una x1800, por ejemplo,) y si quieres Nvidia, pues tienes la serie 6 pero yo me decantaría por la serie 7. Una GeForce 7800, por ejemplo. Aunque si no te lo puedes permitir (no sé cómo estará de precio), una GeForce 6800 estaría bien. Nosotros estamos pensando en empezar a dar soporte en el motor para Shaders 3.0. De hecho, haddd se ha pillado una GeForce 6200 (unos 70 euros) pero es bastante mala. Es más lenta que la Radeon 9500. Creo que está pensando en cambiarla por una Radeon x1800.

Bueno, ya me he cansado de escribir. Saludos.

[shenmue]

Vaya explicaciones nos das tío. Voy a empezar a rendirte culto.

[Geminis]

En los últimos juegos la física está mejorando mucho, por ejemplo, en el oblivion(juego) no desaparecen al morir y se dan de leches con todo al caer, es más en ese juego si te ven con un cadáver al lado los guardias van a por ti. Anda que no me abre cebado yo en juegos a acribillar a la peña en el suelo para desestresarme (en el Soldado de Fortuna, por ejemplo, los mutilaba a todos en el suelo si me había costado matarlos, que masoca soy).

Vaya Halfvector pedazo explicaciones, nos estas haciendo aprender un heuvo muchas gracias. Un saludo.

[neobarry]

Pero si te vas a otro nivel los cuerpos desaparecen. (Imagínate si matas a un millón).

[HalfVector]

Si os interesa este tema de utilizar la GPU para cosas no necesariamente relacionadas con gráficos, podéis pasaros por GPU (general-purpose computation on GPU).

Precisamente uno de los nuevos artículos es la presentación de Havok FX en la gdc de este año. Saludos.

[Josich]

Genial Halfvector, una gran explicación, lo que me suscita más incógnitas y por supuesto más interés (es lo malo de haber aprendido algo más, que quieres saber más).

Si con el Shader model 4 y el geometry Shader se consigue desplazamientos en geometría, trabajar con alto rango dinámico, crear geometría etc, se acerca el punto donde los renders en programas de modelado sean instantáneos y en el viewport. No tengo ni idea de cómo trabajan internamente los motores como Mental Ray, Vray o RenderMan, entre otros, pero por lo que se ve no creo que tarde tanto en llegar a ese punto, lo que sería una maravilla.

Como participante del proyecto the truth espero poder ver en acción alguna de esas opciones y sacarle el máximo provecho al haddd.

Por lo que hace a la tarjeta gráfica, en principio me decantaría por una Nvidia, ya sea porque la conozco más o por capricho. La 7800 se va a los 600 euros, un poco cara por ahora, y la 6800 GT no la veo mal y mucho más asequible. Miraré las Ati que has comentado a ver qué tal.

En lo referente a los cadáveres en pantalla, también me gusta que se queden los cuerpos en escena. Por ejemplo, en el Call of Duty hay la opción enfermizo donde se amontonan decenas de muertos, lo que da una ambientación mucho más cruda. Por otro lado, mencionar un juego algo viejo, pero muy digno, a más de producción española llamado Blade (que todos conocereis), donde se quedaban en pantalla los muertos y no solo eso sino que depende dónde les golpearas, mutilabas un miembro u otro (piernas, brazos, tronco, cabeza), era muy entretenido ir mutilando los cadáveres y lanzar sus restos a otro enemigo. Un saludo y gracias por la extensa explicación.

[Sombra3d]

Hombre, algún día si se llegara a la calidad del render, pero todavía queda mucho camino por recorrer, por cada vez que se avanza un poco más nos damos cuenta de lo que nos queda por caminar, el principal problema que tienen los juegos actualmente es el tema de calcular la iluminación, normalmente gracias a trampas visuales o precalculada, pero hasta que lleguemos a ver un programa que calcule GI en tiempo real.

Ten en cuenta que el silicio ya está en las últimas, y llegar a la calidad de la vida misma (que es el objetivo del render) es por definición inalcanzable.

[Josich]

Muy filosófico tu razonamiento sombra3d, es para abrir otro hilo del tema: la eterma búsqueda de la perfección en 3d y global iluminación. Un saludo.

[Sombra3d]

No, no es filosófico, es matemático, simplemente, piensa, si quieres recrear el mundo real solo hay una manera de que sea perfecto, a base de un sistema que simule a niveles atómicos, pero claro, no puedes con algo creado en átomos simular lo que hacen los átomos en tiempo real.

[Chaman]

No puedes con algo creado en átomos simular lo que hacen los átomos en tiempo real.

Yo entiendo lo que quieres decir, pero esa frase no tiene mucho sentido y no es cierta. Se simulan a la perfección hoy en día reacciones nucleares mediante computación. No en mi ordenador ni en el tuyo, si en supercomputadores como el que hay en Barcelona (Marenostrum) o cómo el supercomputador que tienen en Japón que se dedica a simular historias de metereologia.

El otro día me contó mi compañero de piso (que estudia aereonautica) que en una conferencia un japonés les contó que pidió permiso para simular en ese supercomputador las turbulencias que se producían en el borde del ala de un avión durante un período de medio minuto, usando las ecuaciones de navier-stokes a dolor (un morcillón de ecuación), para comprobar si eran en realidad fieles a la realidad, comparando los resultados con los obtenidos en un túnel de viento. Y en efecto, los resultados eran calcados (lo que no se atrevio es a decir cuánto tiempo se estuvo simulando la prueba en el supercomputador ese).

Conclusión: hay cosas que se pueden simular perfectamente, lo que pasa es que no hay capacidad de computación para hacerlo. Por ahora.

[Sombra3d]

Tu mismo me has reafirmado chaman, si un macrocomputador con la capacidad de 10000 (o más.) ordenadores no puede ni imaginar hacer en tiempo real solamente la simulación de partículas es imposible que algún día procesador alguno que pueda simular un entorno real, solo una simple emulación llena de trampas, ya que la propia latencia de los datos lo hace impracticable (en tr) en un macrordenador, solamente sería posible en un procesador, pero el silicio ya está gastado (el cell ya da más problemas que soluciones). Además, tu estas hablando de física.

O sea, lo que quiero decir es que nadie se haga ilusiones de ver en su día un PC del tamaño de un encendedor que se conecte al cerebro y tenga su propio universo a lo nivel 13 proceso de manera real.

[Chaman]

Computadores que, antes ocupaban plantas enteras de edificios (hace 30 años) son pulidos en potencia por cualquier ordenador que puedas comprar de segunda mano en cualquier tienda de tres al cuarto. El Cray que usaban en el 90 y pico para simulaciones meteorológicas del tamaño de una lavadora luce hoy esplendoroso en el museo de mi facultad, y es pulido con creces por cualquier portátil. La tecnología del silicio se agotara llegado el momento (todavía queda). Pero con el silicio no se acaba el mundo. No nos estáncamos en las válvulas de vacío, y no lo haremos en el silicio.

Me gustaría retomar este mensaje dentro de 40 años.

[Sombra3d]

Vamos a ver, para que lo entiendas, ningún procesador formado por x átomos puede calcular un universo formado por más de x átomos. Y eso en el supuesto de que se consiga la tecnología y el material para que un átomo haga todo eso solo (lo cual sabemos que también es imposible).

[Chaman]

A ver, no digamos sandeces. ¿de dónde te sacas que para simular la realidad haya que hacerlo a niveles de átomos? En fin, da igual, la perra gorda para ti.

Y bueno, actualmente se están investigando como realizar cálculos binarios a nivel de átomos, trabajando con los saltos de los electrones en sus diferentes capas de Valencia y considerándolos diferentes estados binarios.

[ikerCLoN]

Esto está alcanzando unas cotas de misticismo chorra increíbles para mí, el error esta aquí.

Y llegar a la calidad de la vida misma (que es el objetivo del render).

¿el objetivo del render es llegar a la calidad de la vida misma? Vaya, ¿y eso de dónde lo sacas?
Por cierto, Halfvector, muy buena toda la información. Para profanos como yo, es un lujo poder informarse de estas cosas de primera mano.

[shenmue]

A estas alturas podemos empezar a debatir sobre la investigación de la antimateria. Antimateria¿la futura fuente de recursos energéticos que salvarán el planeta o un arma nuclear debastadora que aniquilara la tierra?
Hace poco que estoy leyendo ángeles y demonios de dan Brown que trata este tema, a raíz de eso he empezado a mirar páginas del Organización Europea para la Investigación y demás sitios sobre los avances científicos, es acojonante. Os recomiendo que lo leáis. Se os podrán de cobarta viendo lo que podría pasar. Yo voy a empezar a construirme un bunquer bajo casa.
¿Para cuándo una simulación en los videojuegos en tiempo real de la aniquilación que produce el choque de materia y antimateria?
Menos mal que solo quería saber porqué desaparecían los bichos al morir. Ahora tengo miedo.

[Sombra3d]

Simplemente se saca de que ahí es donde va los programas, física real, gráficos más reales, ahora me vas a negar que los juegos cada vez tienen gráficos más reales y que es lo que quiere la gente.

[neobarry]

¿Un superordenador que controle totalmente los átomos del universo para predecir el futuro y así modificarlo?
-Me estas hablando de Matrix ¿no?

[josepzin]

Hace poco que estoy leyendo ángeles y demonios de dan Brown que trata este tema.

Hag, mejor léete caballo de Troya, es igual de exagerado, pero al menos es autóctono.

[HalfVector]

Bueno la máxima de un programador gráfico es algo, así como hazlo más creíble posible, aunque la simulación no se adapte a la realidad.

Pongo un ejemplo. Raytracing.

En la naturaleza, las fuentes de luz lanzan millones de fotones cada segundo. Estos fotones van dirigidos en infinidad de direcciones. Unos pocos, al colisionar con una superficie, serán reflejados/refractados y acabaran en nuestra retina, lo cual hará que esa superficie sea visible para nosotros. La mayoría acabaran siendo absorbidos por el entorno.

Ahora bien, pongamos por caso que algún día existe una máquina capaz de procesar tal cantidad de fotones. ¿realmente queremos simular ese comportamiento con exactitud? ¿Qué sentido tiene hacer un seguimiento de la trayectoria de millones de fotones (con la cantidad de colisiones, reflexiones, refracciones, etc que ello conlleva) cuando en realidad sólo un pequeño porcentaje acabara alcanzando la cámara?
A ese proceso se le denomina forward Raytracing y desde luego no es el proceso que sigue el Raytracing. El Raytracing hace justamente lo contrario (backward Raytracing). Lanza fotones desde la cámara, lo cual nos asegura que todos los fotones colisionaran con algo que será visible para la cámara.

Evidentemente esto genera ciertas cuestiones como, por ejemplo, cuantos fotones son necesarios lanzar por cada píxel. Si te quedas corto aparecerán artefactos como aliasing, noise, etc. Si te pasas, estarás lanzando rayos de forma innecesaria. Para paliar esto, se han ido desarrollando técnicas como supersampling, adaptive supersampling, estochastic Raytracing (Montecarlo, Manhattan, etc), etc.

En definitiva, la cuestión es si realmente vale la pena desperdiciar capacidad de cálculo lanzando fotones que no van a contribuir a la síntesis de la escena final. Sólo en el caso de tener un ordenador con una capacidad de cálculo infinita podría valer la pena. Pero aun así, creo que con los métodos actuales ya somos capaces de engañar muchas veces al ojo humnano y hacer que las cosas parezcan reales sin llegar a serlo. Saludos.

[Mars Attacks]

Nuestra meta es hacer las cosas creíbles, no realistas. Una de las antiguas citas de Shazam que habría que tatuarse en alguna parte.

Hablando de Raytracing, en las jornadas gráficas de la uji de verano del año pasado, un hombre nos hizo una demostración de una imagen Dual: dada la relación entre la luz que sale del emisor y llega a la cámara, se puede invertir el camino de forma que, con esa información, podamos reconstruir la escena tal y como la veríamos si iluminaramos con la cámara y recogiéramos la luz con el emisor. Fue bastante acojonante el ver cómo reconstruía la imagen de una carta de naipes puesta perpendicular a la cámara, pero de frente al emisor.

[Mars Attacks]

Por cierto, en Commandos los personajes muertos sí permanecen muertos y puedes colisionar con ellos. Pero claro, siendo billboards.

[Josich]

Que es exactamente un billboard? Ya ha salido varias veces. Sombra3d aparte de que se te ha ido un poco la bola con el nivel atómico, decir que a lo que me refería sencillamente es a ver los renders directamente en las vistas del viewport en GI, nada de simuladciones atómicas ni una reproducción exacta de la realidad, ni que fuésemos dioses del olimpo.

El 3d no deja de ser una herramienta para representar la realidad o la fantasia. Hasta hace unos pocos años la única forma de hacerlo era con la pintura o la fotografía. Por muy reales que parezcan algunos cuadros o fotografías no dejan de ser representaciones de lo que se muestra, ya sea a base de pinceladas o de puntos de nitrato de plata. No creo que ningún pintor pintara átomo por átomo las mininas.

Vistos los avances que han salido en estos últimos 20 años no es de extrañar que en un breve plazo los juegos se vean como películas y los renders estáticos sean de décimas de segundo. No creo que este diciendo ninguna tontería, o quizás si.

Viva el 3d y los montones de cadáveres perpetuos. Un saludo.

[HalfVector]

Que es exactamente un billboard? Ya ha salido varias veces.

Un billboard es un Quad (dos triángulos) que encara constantemente la cámara en alguno de sus ejes.

Te pongo un ejemplo para que lo entiendas. Me imagino que has visto juegos como Unreal o Quake 3 que tienen esos halos de luz en algunas fuentes de luz. Eso no es más que un Quad con la textura de un flare que se orienta de tal forma que siempre está mirando a la cámara.

saludos.

[Fiz3d]

No creo que ningún pintor pintara átomo por átomo las mininas.

Mininas: versión reducida o para ver en tu IPod de la obra las meniñas, también se refiere a una versión en la que aparecían un gato en vez del perro.

Por otra parte, los pintores extienden la pintura por el lienzo, la pintura esta compuesta por átomos, con lo cual realmente están pintanto átomo por átomos su obra.

No me hagáis caso tenía que decirlo. Saludos.