DirectX y OpenGL: las dos API más importantes del mercado gráfico
A la hora de crear un entorno tridimensional, los programadores deben decidir entre DirectX u OpenGL. En esta breve reseña detallaremos los aspectos más importantes de cada plataforma, su historia y haremos una comparación punto por punto, para ver cuál es la más conveniente para implementar.
Seguramente habrán oído muchas veces estas dos palabras. Si bien una de las dos –OpenGL– ha perdido terreno en las últimos años (por lo menos en lo que se refiere a videojuegos), continúa presentándose como la competencia más dura de DirectX. La API de Microsoft se convirtió en la preferida de los programadores a la hora de diseñar complejos entornos gráficos interactivos en tres dimensiones y utilizar los conocidos shaders.
Pero, un momento… ¿qué es una API?. Su sigla proviene de Application Programming Interface, lo que en castellano sería Interfaz de Programación de Aplicaciones. Se trata de un conjunto de técnicas, funciones y métodos utilizados para establecer una comunicación entre los diferentes niveles o capas de un software. Una API permite una abstracción en la programación entre las capas inferiores (bajo nivel) y las superiores (alto nivel), de forma tal de poder interactuar casi directamente con el hardware a través de funciones nativas del sistema operativo o mediante una aplicación específicamente diseñada con ese propósito.
Tanto DirectX como OpenGL son APIs que se valen de librerías para cumplir con su objetivo. Los diseñadores de software escogen la que mejor se adapte a los requerimientos del producto y comienzan a programar en base a ella. La elección correcta depende de varios factores, los cuales intentaremos detallar en las próximas líneas. Antes de ello, conozcamos un poco más sobre el pasado y el presente de estas dos APIs.
La sección de DirectX dentro de la página de Microsoft es el lugar más indicado para conseguir las librerias OpenGL es, junto con DirectX, una de las dos API que más se utilizan para el desarrollo de escenas 3D
DirectX es la más utilizada en la programación de videojuegos
El conjunto de librerías de Microsoft nació allá por 1995, cuando en una importante exposición se presentó lo que por ese entonces se conocía como GamesSDK v1. Al ser un API encargada de varios aspectos (gráficos, sonido, música, comunicaciones, etc.), estaba estructurada en varios componentes: DDraw, DSound, DPlay y DInput. Cada uno de éstos controlaba un aspecto en particular; en el caso de los gráficos 2D, DDraw era la responsable. Estas herramientas de desarrollo estuvieron disponibles en Octubre de ese año, un par de meses después que Windows 95 saliera a la venta.
El próximo paso fue incorporar Direct3D –para gráficos tridimensionales– al conjunto, algo que se lograría recién en la tercera versión (DX 3.0). Los sucesores no tardaron en aparecer, ya que DirectX 4 llegó en Diciembre del 96’ y DirectX 5 en Junio del año siguiente. En realidad, la cuarta edición fue una modificación de la tercera que venía preparada para ser compatible con el primer gran chip que llevaría la bandera de la aceleración 3D: el Voodoo Graphics.
Al ser compatible para atrás, cada nueva versión de DirectX podía ejecutar, también, software preparado para las versiones previas. Fue por eso que el crecimiento en potencia y posibilidades de esta API fue muy marcado en los años siguientes. El resto de la historia ya lo conocemos: DirectX 7 nos trajo el Transform & Lighting; DX 8 amplió los horizontes de los programadores con la inclusión de los shaders; DX 9 hizo mucho más extenso dicho horizonte, y lo más reciente –DX 10– está, por ahora, en sus primeras etapas de implementación y con un futuro enorme.
La herramienta de diagnóstico de DirectX nos permite conocer más en detalle las librerias de esta API La herramienta de diseño 3DS Max saca provecho de las posibilidades de DirectX
Counter-Strike: Source, corriendo en el modo OpenGL
Si se le pregunta a un gamer, automáticamente relaciona OpenGL con Quake. Es que John Carmack, el mentor de esta saga, fue –y es– una de las personas que mayor apoyo brindó a esta API, programando todos los títulos de su compañía Id Software utilizándola como base.
La responsable de Open Graphics Library –su denominación completa– es Silicon Graphics Incorporated (SGI), la misma que en la década de los 90’ fuera la propietaria de la API IrisGL, la antecesora de OpenGL. La diferencia radical entre ambas es que la segunda no estaba ligada a ninguna licencia de uso y modificación. Por eso, en 1992, SGI comenzaría la creación de OpenGL, con el objetivo de que fuera abierta a la comunidad de programadores. Gracias esta característica, junto a su escalabilidad y condición multiplataforma, OpenGL pudo mantener una especificación de uso actualizada en los años subsiguientes.
A partir de la versión 2.0, concebida por 3DLabs, la API tomó un nuevo rumbo. Además de una gran cantidad de modificaciones internas, se adoptó el lenguaje GLSL para el uso de los antes mencionados shaders. Esto significa que se reemplazaron las funciones fijas por unas mucho más versátiles, posibilitando los efectos gráficos que vemos, por ejemplo, en Quake 4, Doom 3 y, el más reciente, Prey.
OpenGL 2.1 apareció en Agosto de 2006, expandiendo ligeramente las funcionalidades de su antecesor y actualizando diversos aspectos, principalmente el lenguaje GLSL.
El lenguaje GLSL es el utilizado para implementar los shaders en OpenGL El manejo de luces es uno de los grandes puntos fuertes de esta API
Para las películas de animación, OpenGL es la plataforma preferida
Como decíamos al comienzo, la elección de una u otra API depende de varios factores, como la portabilidad, facilidad de uso, el rendimiento, los usuarios a los cuales está destinada la aplicación y la extensibilidad, entre otros. En este caso, vamos a comparar las librerías de DirectX dedicadas al procesamiento de gráficos (Direct3D) con OpenGL.
Portabilidad: Si nos guiamos por la portabilidad, DirectX difícilmente supere a OpenGL, dada su gran dependencia con Windows y sus componentes. Fuera de este sistema operativo, solamente se encuentra implementada en la consola Xbox. En cambio, OpenGL es compatible no sólo con Windows, sino que se utiliza en sistemas Unix, Linux, Mac y hasta en consolas como PlayStation 3 y Nintendo Wii. En resumen: exceptuando Windows y Xbox, todos los sistemas que proveen soporte para aceleración 3D han escogido a OpenGL para esa tarea. Por algo será, ¿no?.
Hablando del sistema operativo de Microsoft, éste incorpora un driver de la API de SIG, pero que sin funcionalidad de aceleración por hardware o agregado de extensiones. Algo curiosa es la manera de Vista para manejar OpenGL: la mínima integración de esta API –en su versión 1.4– hace que, para que funcione correctamente, se traduzcan las instrucciones de ésta a DirectX, aunque con algunas limitaciones. Claro que, utilizando el driver de video provisto por el fabricante del chip, este proceso no es requerido.
Facilidad de uso: En sus comienzos, varios programadores se agarraban la cabeza cuando tenian que trabajar con DirectX, debido a lo complejo de su utilización. Con el correr de las versiones, la balanza se fue equilibrando y, hoy en día, a pesar de que sigue un paradigma completamente distinto a OpenGL (inspirado en el modelo COM), ya no es tan complicado de usar. Lenguajes como Visual Basic o Visual Basic Script son un ejemplo de los que trabajan con este modelo. Por el lado de OpenGL, al estar basado en el lenguaje de programación C, es bastante más comprensible y puede ser adaptado a cualquier otro lenguaje sin demasiadas complicaciones.
La diferencia principal es que DirectX es una API cuya plataforma se basa en lo que el hardware es capaz de realizar, mientras que OpenGL es un tanto más independiente. A su vez, de su implementación depende la administración de los recursos, algo que en DirectX corre por cuenta de la aplicación. Este detalle permite un desarrollo de software más sencillo, pero es más propenso a sufrir los tan temidos errores de programación (mejor conocidos como bugs).
Performance: El rendimiento del software creado por medio de una u otra API sigue siendo un parámetro muy debatido. Dado que DirectX implementa los drivers a nivel del nucleo en el sistema operativo y de nivel usuario con un runtime provisto por Microsoft, existe la necesidad de hacer un cambio entre un modo y otro en las llamadas a la API. Como consecuencia, la CPU utiliza valiosos microsegundos en completar la operación, quedando inutilizada para otra tarea. En cambio, OpenGL, a través de una técnica conocida como marshalling, evita ese inconveniente y obtiene una valiosa ventaja en la performance final. Recién a partir de Windows Vista, DirectX podrá sortear esta deficiencia mediante este mismo procedimiento, ya que los drivers estarán funcionando más a nivel de usuario que del kernel del sistema operativo.
Extensibilidad: OpenGL incluye una propiedad que le posibilita extender sus capacidades a través de un driver, añadiendo nuevas funcionalidades. Pero esto puede conducir a generar una gran cantidad de variantes de la API, provocando cierta confusión entre los programadores. Por el lado de DirectX, Microsoft se encarga de mejorarla pero con menos regularidad. No obstante, desde hace un par de años que las actualizaciones aparecen cada vez más seguido. Depende de la empresa conducida por Bill Gates la incorporación de características en la API que aprovechen las novedosas funciones de las GPU más modernas.
Usuarios: La ventaja en el ámbito profesional está del lado de OpenGL. Incluso la propia Microsoft admite la superioridad de ésta en estos campos. De hecho, muchas de las placas profesionales sólo soportan esta API, lo que es un decir. Los films animados por computadora son desarrollados en base a OpenGL, dado su carácter de plataforma de propósitos generales.
La situación cambia cuando lo miramos desde el punto de vista del mercado de los videojuegos. DirectX no requiere de la implementación completa que demanda OpenGL para funcionar (incluyo funciones no soportadas por el hardware), por lo que se torna más sencillo de utilizar. Para hacerlo simple, podemos decir que Direct3D es un acceso directo de bajo nivel a los registros disponibles. Además, posee un mecanismo que determina si una funcionalidad está o no presente en el dispositivo, evitando la implementación obligatoria y dejando a elección del diseñador del videojuego su incorporación en el software. Por este detalle importante es que vemos muchos más juegos de ordenador programados en DirectX que en OpenGL.
La dependencia de DirectX con Windows es uno de los puntos más flacos de esta API OpenGL también es aplicado en el mundo de las consolas, como es el caso del Nintendo Wii
John Carmack, un ícono de OpenGL
Más allá de todo lo que hemos relatado, hay que aclarar que las diferencias son mucho más pronunciadas, y que sólo pueden percibirse por completo habiendo tratado con una y con otra desde el lugar de programador. Como simples usuarios, no queda otra alternativa que esperar una buena optimización por parte de las compañías responsables, de forma tal que el producto software final aproveche lo mejor posible el hardware instalado en nuestro ordenador.
Estas épocas lo ubican a DirectX en la delantera en el sector que concentra la mayor cantidad de público: el mercado de los videojuegos. John Carmack es uno de los pocos que aún apoya la utilización de OpenGL en los juegos de ordenador, pero no hay que olvidarse que su competencia no es más ni menos que la mismísima Microsoft.
El futuro nos depara cosas prometedoras. DirectX 10, la versión más sofisticada y poderosa de esta API, es una de ellas. En tanto que OpenGL continuará evolucionando poco a poco gracias a su extensibilidad, manteniéndose a la misma altura –en cuanto a capacidades– que su rival.
Con DirectX 10 se pueden lograr escenas tan realistas como éstas del título Crysis. Adivinen cuál es real y cuál pertenece al videojuego.
http://www.neoteo.com/directx-y-opengl-las-dos-api-mas-importantes-del.neo
————————————————————————————
Bueno despues de mirar Mirror’s Edge me he dado cuenta que hace falta hacer un reflexión de lo que es física y lo que algunas veces nos meten en los juegos haciendo aparentar que es física y es algo que se puede conseguir mediante directx o OpenGl o OpenCl,otra cosa bien distinta es que el agua pegue en un personaje y actue sobre el como Cryostasis,pero vamos hasta los de Nvidia lo pasan mal en ese momento por que verdaderamente es cuando hay física,en Mirror’s Edge para mi es un engaño.
Pondré aquí ciertas cosas sobre Directx 9, 10 y 11 y sobre Opengl y OpenCl,Cuda etc,para que todos sepamos que es exactamente y que novedades y lo que Nvidia o Intel o Ati nos quieren vender.Intentaré poner imagenes de Mirror’s Edge y otros juegos comparando ciertas zonas,de agua,cascadas y niebla,cristales rotos de FEAR,etc,etc,para ver si es posible hacer las cosas de otra manera y esto es simplemente un truco para vendernos algo que ya estaba y está ahora mismo.(No pretendo crear polemica solo dar ejemplos y opiniones).
Mucha gente no sabe que mediante caracterisiticas de Havok o directx o OpenCl o OpenGl se pueden hacer las mismas cosas,eso si con más trabajo,algo que por lo visto los programadores de hoy en día no quieren hacer,se van a lo más facil,asi salen juegos mal optimizados como GTA iv etc.
Empezaré poniendo el post que hice hace tiempo sobre CUDA,Havok y Ati física,una lectura casi obligada para entender por donde van los tiros y que quieren vendernos en las graficas de nueva generación como las que nos vienen de directx 11
http://www.gameprotv.com/foro/viewtopic.php?t=73820&highlight=cuda
La tarjeta Ageia,la primera que hizo posible lo que Nvidia hace hoy en día y que mucha gente no quería comprar…
Haré el post poco a poco con ejemplos,cualquier valoración positiva o negativa será considerada,pero ojito quiero con este post quitar valor a Physx y eso va a doler a gente ya que mi post va dirigido a que las cosas se pueden hacer de otra menera y se puede demostrar que algunas cosas de físicas ya estan en algunos juegos sin utilizar Ageia o Nvidia Physx CUDA.
Vamos a comparar Mirror’s Edge y sus físicas con algo ya aparecido y me informaré en revistas antiguas sobre juegos Half Life etc y virtudes de espejos,etc.
¿FÍSICA Mirror’s Edge es posible hacer el juego sin ella?.
Voy a utilizar todas mis armas en imagenes para dejar claro que es posible sin física hacer efectos como la niebla o el agua.
Demo de Medusa es una demo en la que aparece una niebla,está demo funciona en mi Ati y tiene mejor efecto de niebla que en el juego
Efecto Niebla
Mirror’s Edge
No veo en esa niebla justificación para que baje a 8 frames….
Call Of Juarez sin Physx y con más particulas
http://www.gameprotv.com/foro/viewtopic.php?p=1148774#1148774
Demo Medusa
Hasta este efecto me va mejor a tope
http://www.gameprotv.com/foro/viewtopic.php?p=1148006#1148006
Efecto Agua
Mirror’s Edge
No si en Mirror’s Edge tiene tantas particulas que vamos hay que bajar a eso si no tienes Physx Nvidia….jajaja.
Call of Juarez
http://www.gameprotv.com/foro/viewtopic.php?p=1148774#1148774
Unreal Tournamet 3
http://www.gameprotv.com/foro/viewtopic.php?p=1148294#1148294
Lluvia
El efecto lluvia como es comprobado por todos Ustedes no le hace faltá física alguna,solo programarlo bien.
Call Of Duty 4
http://www.gameprotv.com/foro/viewtopic.php?t=74409
Stalker
http://www.gameprotv.com/foro/viewtopic.php?t=74444
Bioschok efectos agua y cascada y humo directx 10,por supuesto esto en Mirror’s Edge podría estar perfectamente sin esos bajones.
No hace falta algunos efectos crearlos por Physx Nvidia yo lo he demostrado.Es todo un cuento para vender.Comprar el producto precio/calidad nada más.
Bueno que os habeis quedao así
DirectX9 Vs DirectX10
nVidia Directx 10 – Rain
Link
http://www.youtube.com/watch?v=-yxnETZ6RZk
DirectX 9 vs. DirectX 10
Link
http://www.youtube.com/watch?v=0KvURb4-Hdg
FSX Vista DX10 -vs- DX9
Link
http://www.youtube.com/watch?v=aY9wWvA4gWI
The Miracle of DirectX 10
Link
http://www.youtube.com/watch?v=x7aPvedU7cI
Diferencia y caracteristicas entre las placas de video DX9 y DX10:
El sitio Shacknews tiene nuevos screenshots (capturas en juego) de “Age of Conan”, un título basado en la nueva API de Microsoft, DirectX10. Sin embargo, el juego también es compatible con DirectX 9.
Entre las imágenes más notorias se encuentran las dos primeras, donde se observa cómo se gana con DirectX 10 un mayor número de elementos en escena y más detalle en el relieve de los objetos (Shader Model 4.0), limitantes básicas de DirectX 9.
DirectX 9.0c (derecha)
DirectX 10 (Izquierda)
Fuente: ShackNews
¿Qué cambios traerá DirectX 10?
Introducción
Una de las mayores evoluciones en la industria de los juegos esta por venir. El sólo hecho de que Microsoft vaya a lanzar un nuevo sistema operativo es de por sí un evento mayúsculo, pero esta vez no viene solo, porque junto con su nuevo Windows Vista, la empresa de Redmond introducirá un nuevo API, desarrollado desde cero.
No tan rápido ¿Que es un API?
La Interfaz de Programación de Aplicaciones
Originalmente, se incluyó DirectX en Windows para que los desarrolladores pudiesen tener acceso a varios aspectos de una tarjeta gráfica, tarjeta de sonido y dispositivos de entrada (mouse, teclado, joypad, etc) sin la necesidad de programar individualmente para cada hardware .
DirectX esta compuesto de varios sub API, entre las que se incluyen DirectSound, DirectInput y DirectMusic. El componente que ha tenido mayor evolución ha sido Direct3D, debido al gran desarrollo de las tarjetas de video.
Las funciones API se dividen en las siguientes:
Depuración y manejo de errores
E/S de dispositivos
DLLs, procesos e hilos
Comunicación entre procesos
Manejo de la memoria
Monitoreo del desempeño
Manejo de energía
Almacenamiento
Información del sistema
GDI (interfaz gráfica) de Windows
Interfaz de usuario de Windows
Ahora que ya sabemos lo que es un API podemos imaginarnos la importancia de DirectX 10, pero… ¿Es sólo otra versión de DirectX? ¿Qué grandes mejoras específicamente trae? ¿Es una movida de Microsoft para que todos tengamos que renovar nuestro Hardware?
Esas y otras dudas, quedarán claras como el agua en los siguientes párrafos.
¿Sólo otra versión de DirectX?
El DX10 es otra versión de DirectX, eso está claro, pero es necesario contrastar sus atributos con los de su antecesor, DX9, para poder entender la importancia del cambio. Mal que mal, DX9 apareció en el 2002 y aunque en su momento fué un agran adelanto, en el intertanto han aparecido tecnologías nuevas que lo han ido haciendo paulatinamente obsoleto.
DirectX 9 Overhead
Una de las limitaciones mas grandes de DX9 es el “Object Overhead”, una condición que crea un cuello de botella para los desarrolladores de juegos. Debido a lo anterior, es necesario plantear un API que corrija este problema.
¿Qué queremos decir con “Object Overhead”? En palabras simples, DX9 utilizaba ciclos de procesador para completar tareas necesarias para hacer renders antes de ser enviados a la tarjeta de video. Cuando se renderea un juego, la aplicación primero debe llamar al API y luego el API llama al Driver antes de poder llegar a tu GPU. Estas llamadas son manejadas por el CPU y eso utiliza recursos muy valiosos y limitados, pero además alarga el camino que debe recorrer la información para que el proceso sea exitoso. Ambas características convierten al Object Overhead en un importante cuello de botella.
Dentro de este proceso hay limitaciones de cuántos objetos puedes mostrar en la imagen en un momento dado en un frame dado. Los objetos pueden ser cualquier cosa en un juego, un personaje o un árbol por ejemplo. La cantidad máxima de objetos en cada frame actualmente es de alrededor de 500 objetos, cualquier cosa sobre eso produce un gran cuello de botella a nivel de CPU. Lo anterior obliga que los desarrolladores de contenido deban balancear cuidadosamente el juego para evitar cuellos de botella producidos por el API y el CPU. Pese a que uno podría pensar que 500 objetos es un límite generoso, la progresiva complejización de los escenarios de los juegos, orientadas a ofrecer una experiencia más envolvente, ha terminado por requerir más que esa cifra.
Para dar una idea de la limitación anterior, pensemos poe ejemplo en un juego cuya acción transcurra en un bosque. Sabemos que en un bosque real hay miles de arboles y arbustos distintos, pero debido a la limitación de DX9, la mejor representación de un bosque que el API actual puede ofrecer consiste en la repetición de un mismo árbol con mínimas variaciones entre uno y otro. Es una salida ingeniosa para subsanar la limitación, pero el escenario no alcanza a ser realista. DirectX 10 eliminara esta limitación y será posible por ejemplo introducir miles de arboles distintos en un frame dado.
¿Qué nos entregara DirectX 10 a cambio?
DirectX 10 nos permitirá poner más objetos únicos en un frame lo que nos mostrará ambientes más realistas y más inmersivos. Aún podremos encontrar limites en cuanto a cantidad de objetos pero ya no será el API el factor limitante sino sólo el GPU y la imaginación de los desarrolladores.
Con la desaparición del Overhead veremos además una reducción en el tiempo de ejecución de los juegos. Calculen que actualmente DirectX 9 y el driver producen el 40% del tiempo de ejecución, DirectX10 reducirá a la mitad esa proporción.
El hecho de que los cálculos que antes pasaban por el CPU ahora puedan ejecutarse directamente en el GPU, liberará una cierta cantidad de potencia en la plataforma, pero además permitirá ejecutar en el GPU cálculos no necesariamente relacionados con gráficos, como son las aplicaciones de GPGPU de entre las cuales destaca el cálculo de físicas.
La siguiente diapositiva explica, según el punto de vista de Nvidia, la mejora que se producirá en los cálculos físicos, debido más que nada a que estos cálculos son un proceso altamente paralelizado, ideal para aprovechar la fuerza bruta de un GPU. Como podemos ver de las 3 etapas del proceso del calculo de físicas el que menos paralelismo tiene es de un 70%.
Limitaciones de un Pipeline Fijo
La siguiente limitación de DirectX 9 y las GPUs actuales es la naturaleza de sus pipelines, que es orientado a una función fija. En una GPU los Procesadores de Vertex constituyen un conjunto separado de los Procesadores de Pixeles, y dependiendo de la escena puede darse el caso que un conjunto esté utilizado al 100% mientras el otro está en reposo. El hecho de que los shaders cumplan una tarea específica redunda, etonces, en una permanente subutilización de recursos.
¿Como soluciona esto DirectX10?
Nuevos Shaders de Geometria
Una de las nuevas características de DirectX 10 es una nueva etapa en el pipeline este se llama Shader de Geometría. Este nuevo shader se incorpora a la idea de un pipeline unificado y será una nueva etapa en este componente. La gracia del Shader de Geometría es que ayudará a tener escenas mas complejas, al permitir que el desarrollador del juego a tome formas simples (puntos, líneas o triángulos) y generar objetos complejos a su alrededor. Este nuevo atributo permitirá nuevos e interesantes efectos como son el el Mapping Displacement en tiempo real y Motion Blur.
Stream Out
Esta es una función nueva también en la arquitectura de DirectX 10 y se encuentra asociada a los Shaders de Geometría. El Stream Out permite guardar información de los Vertex shaders o de los Geometry shaders en el buffer y habilita la opción de múltiples pasadas en el Geometry shader.
Arquitectura Unificada
Como dijimos antes, actualmente los Pixel y Vertex shaders existen en conjuntos separados. Sin embargo, para ser compatible con DirectX 10 el hardware deberá pasar a ser completamente unificado. Esto significa que cualquier shader unificado debe ser capaz de funcionar como Vertex Shader, Pixel Shader o Geometr Shader indistintamente y según la ocasión lo requiera. De este modo ya no habrá tarjetas con X pixel shader e Y vertex shaders. Simplemente tendrá N shaders unificados capaces de hacer de todo.
Lo anterior permitirá que dependiendo de la escena, podamos usar toda la potencia de la VGA para procesar vértices o bien pixeles, evitando tener recursos desaprovechados y redoblando a cambio los recursos disponibles para la operación en curso.
Comparativa entre arquitectura DirectX 9 y DirectX 10
Beneficios para Gamers
Mayor nivel de detalles
Para desplegar una imagen, el API interpreta y ejecuta las instrucciones con que un desarrollador le “describe” una figura. Con DX10 esta interpretación y ejecución resultará en formas más detalladas y realistas, sin nececidad de complejizar la manera como se caracteriza el objeto. Veamos por ejemplo el nivel de realismo en la cara de algunos personajes en Half Life 2 (DX9) y Crysis (juego DX10 por venir).
Fotografía 1: DirectX 9 (Half Life 2)
http://www.chilehardware.com/modules/guias/images/20061024/hl2.jpg
Procesamiento de Sombras
La siguiente imagen nos muestra coloreada en verde la proyección que hace una figura para generar la sombra, característica que evidentemente cambia según el origen de la luz. En DirectX 9 la sombra es generada en el CPU, reduciendo el rendimiento del sistema en conjunto con cada nuevo personaje con sombra que aparezca en la imagen. En DirectX 10, la sombra puede ser generada y rendeada completamente en la GPU aprovechando su capacidad de hacer cálculos en paralelos con enorme potencia.
Escenas mas complejas y ambientes mas complejos
El siguiente ejemplo servirá para ilustrar el realismo que DX10 puede imprimirle a un escenario. Aunque el ejemplo está algo exagerado y hemos visto a DX9 desplegar escenas de mucho mayor calidad, al menos en este caso la exageración contribuye a hacer más evidente el cambio.
Wallpaper rendereado en DirectX9
Escenarios dinámicos
En las imágenes podemos ver como crecen las plantas alrededor de la cripta a medida que pasa el tiempo en el juego. DirectX 10 facilita al motor del juego a cambiar dinámicamente la apariencia de la cripta a medida que pasa el tiempo. Esto permite que los escenarios en el juego evolucionen a medida que pasa el tiempo mientras pasa el tiempo, así reemplazando los ambientes estáticos de manera única estimulando el crecimiento natural y el paso del tiempo.
DirectX 9 no es capaz de crear nueva geometría en el GPU. Tampoco es capaz de almacenar resultados intermedios de geometría, por ejemplo, escenarios entre la 1era imagen y la última no podría haber sido generados en el GPU usando DirectX 9.
Motion blurring
En las imágenes superiores lo que vemos es un ejemplo realista de motion blur, que son posibles gracias a DirectX 10. En versiones anteriores de DirectX para realizar el motion blur los desarrolladores tomaban la imagen y la difuminaban posteriormente, mientras que en DirectX 10 darían el aspecto de motion blur de forma dinámica, simulando justamente como si fuera una cámara y modificando el tiempo de exposición, lo que dará un resultado mucho mas realista.
Conclusión
Como habrán podido comprobar, la evolución del API no es una simple medida de fuerza bruta, sino que hay diferencias estructurales de por medio. No sólo cambia “cuánto se hace” sino que “qué se hace” y “dónde se hace” también. Esta reubicación y reorganización de la cadena productiva permitirá salvar obstáculos que estaban estrangulando el desarrollo de los juegos e impedían dar el salto al siguiente nivel.
Sin embargo, lo que se ha cubierto en este artículo se enfoca más que nada en los potenciales usos del API, pero falta comprobar lo realmente importante: Qué y cómo harán los fabricantes de GPU para implementar y explotar estar características. Y eso, queridos usuarios, es una batalla que nos dará muchas horas de entretención para los meses venideros.
El estándar OpenCL
“justo, es la competencia de CUDA/Stream, y viene con dx11 supuestamente”
El nuevo estándar de programación paralela OpenCL (Open Computing Language).
Con dicho lenguaje se pretende unificar en un protocolo abierto sin coste por ninguna de las partes para hacer un uso inteligente de programación paralela incluyendo computación en GPU y CPU.
Funcionalidades de procesamiento conjunto que aporta el lenguaje:
* Conjunto de extensiones C99 para procesamiento en paralelo.
* API para coordinar datos y tareas entre diversos y homogéneos procesadores.
* Requerimientos numéricos basados en el estándar IEEE 754.
* Interoperabilidad eficiente con OpenGL, OpenGL ES y otros API gráficos.
Como punto fuerte a tener en cuenta, es que se podrá hacer uso de la potencia de proceso gráfica, ya mostrada en aplicaciones con CUDA y el nuevo conversor de vídeo de AMD de manera completamente libre. De la mano de cualquier programador sin tener que pagar un canon por usar el nuevo estándar.
Con OpenCL conseguiríamos que las tarjetas gráficas (concretamente sus núcleos de procesado), se “liberasen” y en vez de sólo procesar tareas gráficas, también podrían procesar operaciones conjuntas con la CPU multinúcleo (llamándolo procesado “heterogéneo”). Con este método, el rendimiento de los ordenadores se vería profundamente optimizado.
OpenCL nuevo interfaz de programación paralela
OpenCL, Open Compute Language, es la primera propuesta abierta y estándar de programación paralela sobre dispositivos heterogéneos de consumo, como sistemas multicore, GPUs, móviles, procesadores basados en Cell, etc. El objetivo de OpenCL es crear un punto de encuentro entre fabricantes para que adopten una estrategia común, simplificar la programación de estos dispositivos y poder sacar provecho a arquitecturas heterogéneas con menores tiempos de desarrollo. OpenCL fue una iniciativa propuesta por Apple y posteriormente impulsada por Khronos, el grupo de empresas del sector que mantiene el interfaz de acceso gráfico OpenGL entre otros.
Khronos, el grupo formado por diversas empresas del sector como son 3DLABS, Activision Blizzard, AMD, Apple, ARM, Barco, Broadcom, Codeplay, Electronic Arts, Ericsson, Freescale, HI, IBM, Intel Corporation, Imagination Technologies, Kestrel Institute, Motorola, Movidia, Nokia, NVIDIA, QNX, RapidMind, Samsung, Seaweed, TAKUMI, Texas Instruments y Umeå University, ha presentado oficialmente en SIGGRAPH ASIA 2008 la especificación 1.0 de OpenCL. La iniciativa responde a la creciente popularidad de ciertas arquitecturas multicore, desde los ordenadores de sobremesa, a estaciones basadas en procesadores Cell o arquitecturas basadas en tarjetas gráficas, como los sistemas Tesla de Nvidia o FireStream de AMD/ATI.
La aceleración que producen determinadas aplicaciones de propósito general sobre dispositivos poco habituales como estas tarjetas gráficas, han forzado a algunos fabricantes a introducir interfaces de programación para aprovechar sus arquitecturas. Ese fue el caso de Nvidia y su popular arquitectura hardware/software CUDA o AMD/ATI y su Stream SDK. Sin embargo, estos interfaces no eran multiplataforma, evitando la portabilidad de las soluciones entre diferentes fabricantes de hardware y entre diferentes dispositivos que, sin embargo, coincidían en comunes modos de programación. La empresa Rapidmind capitaneada por Michael McCool, profesor de la Universidad de Waterloo, lleva varios años proponiendo un interfaz multiplataforma con iguales propósitos, pero no era libre y sus licencias eran de pago.
Con OpenCL se abre un nuevo horizonte para el aprovechamiento de estos sistemas de consumo y altas prestaciones, se dota de cierto razocinio en la comunidad y se establece un punto de partida para el futuro de estas arquitecturas.
http://weblogs.madrimasd.org/supercomputacion_de_consumo/archive/2008/12/10/109037.aspx
Publicadas las especificaciones de OpenCL 1.0
OpenCL es un nuevo lenguaje de programación, abierto y libre de royalties, desarrollado para aplicaciones de propósito general que utilicen computación paralela.
Este nuevo lenguaje provee, en palabras de sus desarrolladores, “un entorno de programación para desarrolladores de software para escribir código eficiente y portable para servidores de cómputo de alto rendimiento, sistemas de escritorio y dispositivos de mano, usando una diversa variedad de CPUs multinúcleo, GPUs, arquitecturas basadas en Cell y otros procesadores paralelos como DSPs”.
OpenCL está siendo desarrollado por Kronos Group, seguramente conocido por muchos anteriormente por ser los encargados del desarrollo de OpenGL, el cual engloba a toda una serie de empresas del sector informático como AMD, Apple, Intel y Nvidia entre muchas otras.
Desde aquí podemos acceder a la especificación.
Fuente: aquí.
http://www.noticias3d.com/noticia.asp?idnoticia=29963
OpenGL 3.0, presentación oficial
Khronos Group ha anunciado el lanzamiento de las especificaciones finales de OpenGL 3.0, con un fuerte apoyo por parte de la industria para brindar nuevas funcionalidades al estándar abierto y multiplataforma de aceleración de gráficos 3D.
OpenGL 3.0 incluye GLSL 1.30, una nueva versión del lenguaje de shading OpenGL, y da soporte y acceso a la funcionalidad de las gráficas de última generación y shaders programables. Las especificaciones podéis verlas al completo aquí, pero os resumimos las principales nuevas características. Se espera que OpenGL 3.0 esté disponible antes de un año.
Vertex Array Objects
Funcionalidad Full framebuffer object renderizando a uno y dos canales de dato, permitiendo una mezcla flexible de tamaños de buffer y formatos cuando se renderiza hacia un framebuffer.
Texturas de 32-bit de coma flotante para una mayor precisión y rango dinámico en operaciones visuales.
Renderizado condicional basado en peticiones de oclusión para aumentar el rendimiento
Datos de vertex y pixel medio flotante para ahorrar memoria y ancho de banda.
4 nuevos tipos de compresión de textura, para texturas de uno y dos canales, dando un factor de 2 a 1, lo que ahorra espacio frente a datos sin comprimir.
Renderizado y blending en framebuffers sRGB para una reproducción fiel de los colores en aplicaciones OpenGL sin tener que ajustar la corrección gamma del monitor.
Arrays de texturas para ofrecer un acceso indexado y eficiente a un conjunto de texturas.
Soporte de una profundidad de buffer de 32-bit coma flotante.
El grupo Khronos también ha anunciado que muchas de las características serán integradas en la versión OpenGL 2.1, y así puedan ser usadas por las gráficas actuales.
http://www.noticias3d.com/noticia.asp?idnoticia=27700
OpenGL 2.X y 3.0
Al principio, los desarrolladores de juegos mostraban su oposición al empleo de la API 3D Direct3D de DirectX y preferían emplear OpenGL. Hoy el panorama es distinto, DirectX avanzó con nuevas versiones y la tendencia la cambió definitivamente DirectX9, por lo que hoy es la API3D más usada, al ser más fácil de usar y extendida, y con diferencia por los desarrolladores de juegos, incluso los más tradicionales.
OpenGL se quedó estancado y la versión 2.0 ha decepcionado tras sus retrasos. El panorama cambiará este año, pues aparecerá la versión 2.X, llamada Longs Peak. Es una versión perfeccionada de esta API y con más extensiones. Su llegada tendrá lugar en verano, posiblemente en julio.
Tres meses más tarde vendrá la nueva versión OpenGL 3.0, Mount Evans. Esta nueva versión dispondrá de la característica de las unidades de sombreado unificadas, por lo que requerirá hardware gráfico compatible con DirectX10. La versión 3.0 ofrecerá renderizado en instancias, salida de flujo de datos de los vértices a un búffer, objetos de búffer de texturas, nuevos formatos de texturas, … Otro aspecto destacable es que Khronos Group está uniendo el desarrollo de OpenGL y OpenGL ES, API 3D para dispositivos móviles. Se realizará mediante Collada y glFX y de este modo las características de OpenGL 3.0 también estarán disponibles en la variante ES.
De este modo, OpenGL 3.0 es la primera revisión de esta API 3D totalmente escalable y cualquier gráfica DX10 sería compatible con esta API. Quizás, el problema es la llegada un tanto tardía teniendo en cuenta el desarrollo de los títulos de nueva generación.
http://www.noticias3d.com/noticia.asp?idnoticia=19083
DirectX 11 según AnandTech
La reputada web técnica AnandTech ha realizado un extenso análisis de DirectX 11 y de lo que esta nueva versión de la famosa API 3D de Microsoft podría significar para el mundo de los videojuegos y los gráficos.
Las conclusiones de ese análisis parecen revelar que DX11 es una API “bastante agresiva” debida a mejoras como la introducción de accesos a memoria sin orden secuencial, multihilo, teselación y el nuevo Compute Shader.
Como indican en el artículo, la complejidad de la migración de DX10 a DX11 no tiene nada que ver con la que hubo entre DX9 y DX10. De hecho, al igual que Windows 7 parece una versión mejorada de Vista, DX11 también es una evolución (que no revolución) de DX10, lo que hará más fácil la ejecución de juegos DX11 en hardware más antiguo, algo que no fue posible con la llegada de DX10. Parece que Microsoft aprende de sus errores.
vINQulos
AnandTech
http://www.anandtech.com/video/showdoc.aspx?i=3507&p=8
http://www.theinquirer.es/2009/02/03/directx-11-segun-anandtech.html
DirectX 11
Entre las novedades más interesante, se encuentra una nueva tecnología que permite que los desarrolladores utilicen la GPU como un procesador paralelo, de modo que ayude al procesador o procesadores principales en lugar de emplearla tan solo para renderizar los gráficos. Esto se complementa con la implementación de un mejor aprovechamiento de las arquitecturas multinúcleo tan comunes hoy en día.
Otra novedad interesante es el soporte para teselación, una tecnología que permite que los modelos de los personajes aumenten en detalle cuando la cámara se acerca a ellos, renderizándolos con mayor o menor detalle según la distancia.
tambien nuevos tipos de sombreados computerizados y lenguaje de sombras 5.0 de alto nivel.
Link
DirectX 11 promete incorporar Raytracing
Si la mayoría de mortales aún seguimos esperando para hacernos con un PC lo suficientemente potente como para poder mover juegos en Windows Vista y bajo DirectX 10 sin perecer en el intento, ya han empezado a surgir los primeros rumores sobre la próxima entrega de la colección de APIs de Microsoft. Según apunta la fuente de Tech ARP no tendríamos que esperar mucho para tener entre nosotros DirectX 11, según comenta Meristation a finales de este mismo año en un virtual Windows Vista Service Pack 2.
¿Pero que es el Raytracing? Siendo breves, un sistema de iluminación mucho más complejo y realista con bastantes tecnicismos que se me escapan. Para hacernos una idea es el algoritmo de iluminación que usan en algunas películas digitales, como las de Pixar, con unos resultados bastante más espectaculares que el actual método de rasterización. El problema es llevar esto a un videojuego y lograr que se mueva. Para ello existen algunos motores que lo hacen un poco más asequible, pese a que el raytracing no deja de consumir un buen número de cálculos de GPU. Sí, porque esto tira más de procesador que de gráfica.
Para que se hagan una idea, una versión de Quake IV modificada con el motor de raytracing desarrollado por Intel, que parece que se va a llevar el caramelo, se logró mover a 100 fps y a una resolucion de 1024×1024 con un procesador Intel de 8 núcleos. Aunque claro, habrá que ver como funciona esto en nuestras casas. De momento parece más un sueño de bombo y platillo que una realidad. Si es que lo es.
http://ecetia.com/2008/03/31/directx-11-promete-incorporar-raytracing/
Primeras capturas de Microsoft DirectX 11
Como no podía ser de otra forma, DirectX 11 será exclusivo de Windows 7, aunque mantendrá la retrocompatibilidad con todas las tarjetas con soporte para DirectX 10 o 10.1..
Entre las novedades más interesante, se encuentra una nueva tecnología que permite que los desarrolladores utilicen la GPU como un procesador paralelo, de modo que ayude al procesador o procesadores principales en lugar de emplearla tan solo para renderizar los gráficos. Esto se complementa con la implementación de un mejor aprovechamiento de las arquitecturas multinúcleo tan comunes hoy en día.
Otra novedad interesante es el soporte para teselación, una tecnología que permite que los modelos de los personajes aumenten en detalle cuando la cámara se acerca a ellos, renderizándolos con mayor o menor detalle según la distancia.
http://forums.vr-zone.com/showthread.php?t=353789
Detalles del DirectX 10.1 (destacar que está api viene con SP1 del Vista)
Mejoras sobre DX10: Mejor acceso a los recursos de Shaders lo que repercutirá en la mejora del multisampling y de la calidad del Anti Aliasing o FSAA. También se mejorarán las sombras y sus filtrados, así que veremos sombreas de más calidad. DirectX 10.1 mejorará el aprovechamiento de los procesadores de más de un núcleo, que por entonces ya sólo se venderán procesadores Dual core o más. Comentan que los muy utilizados efectos de reflexión y refracción sobre superficies, como agua, espejos, etc… requerirán menos llamadas a la API y por lo tanto consumirán menos recursos. También comentan que mejorará el cube mapping una técnica bastante utilizada y mejoras en el Floating point blending, puntos que no sabemos explicar.
Añadidos sobre DX10: DX 10.1 llevará mejoras en la calidad visual al introducir los calculos de filtrado en coma flotante a 32 bits en vez de los clásicos 16 bits que tiene DX 9 y 10. El HDR, por ejemplo tendrá mas calidad visual (aunque no sabemos si dejará el rendimiento por el arrastre, claro). Siguiendo con la calidad visual, la aplicación tendrá más control del FSAA y de sus técnicas para conseguirlo como son el MultiSampling (MS) y el SuperSampling (SS), esto quiere decir que posiblemente el programador podrá escoger, en un mismo juego, escenas donde se utilizará la técnica del MS y otras donde el SS. Suponemos que será la que obtenga mejor resultado visual en cada caso, aunque no dudamos que esto será al máximo nivel de detalles y probablemente si escogemos niveles de detalle más bajos, sea al contrario y el juego escoja la técnica más rápida de las disponibles… Siguiendo con el FSAA se permitirá el control sobre el “pixel coverage mask” que mejorará la aplicación y la calidad del FSAA en zonas de vegetación, rejas, etc… Con todo ello para cumplir el estándar DX 10.1 la tarjeta deberá soportar como mínimo FSAA 4x por hardware.
WDDM 2.1 DirectX 10 incorporará WDDM 2.0 y con DX 10.1 llegaremos a la versión 2.1 del sistema de drivers llamados Windows Driver Display Model. Básicamente los controladores permitirán más fluidez en el momento de modificar los elementos a renderizar por pantalla y el cambio a otro tipo de elementos o situaciones. Windows Vista tendrá un entorno o escritorio 3D y además potenciará el uso de aplicaciones multitarea real, gracias a los procesadores de más de un núcleo, por lo tanto entendemos que quieren que los cambios de aplicación o pantalla sean lo más rápido posible. También quieren que la tarjeta cuando no encuentre un dato “page fault”, no se quede esperando mientras recibe respuesta del S.O. sino que proceda con la siguiente tarea y luego cuando el dato esté disponible pueda reemprender el trabajo que estaba haciendo.
En fin, vemos muchos retos tecnológicos, aparte de los de nivel de hardware, mucho trabajo a nivel de controladores para garantizar el último punto WDDM 2.1, por lo que parece que hasta llegar a conseguir estas metas o habrá mucha gente trabajando o tardaremos un poco en verlo. Es decir, quizá salga el hardware DX 10.1 pero no se pueda publicitar a falta de que los drivers estén bien pulidos, ya veremos.
Aunque hay varios detalles que están enfocados a la mejora del rendimiento de muchas tareas hay un especial hincapié en la calidad gráfica y por lo tanto queda claro que veremos varios modelos de tarjetas y pasarán años hasta que DX 10.1 sea movido fluidamente con todo su esplendor gráfico. Atentos al pase de diapositivas que seguro que nos proporcionará Futuremark, aunque no sabemos si será con su 3DMark 07 o 08.
http://www.noticias3d.com/noticia.asp?idnoticia=15653
DirectX 10.1 será la última revisión de la API DX10
Según nos cuentan en la web de X-bit labs, la nueva versión de la API DirectX 10, llamada DirectX 10.1 será la última de la serie 10 o por lo menos eso asegura AMD que forma parte de su grupo de desarrollo. Así veremos utilizar las instrucciones Shader Model 4.0 y 4.1 y no pasará como en DirectX 9 donde vimos aparecer distintas y demasiadas sub-versiones como Shader Model 2.0, 2.0a, 2.0b y 3.0 traducidas en DirectX 9.0, 9.0a, b y c.
Esto intentará simplificar un poco el desarrollo de software y hardware compatible, intentando evitar que la guerra entre las compañías de chips gráficos provoquen funciones exclusivas para sus tarjetas gráficas, lo que nos debería facilitar un poco la labor a los usuarios en el momento de elegir entre tantos productos distintos y pequeñas modificaciones.
Se supone que DirectX 10.1 llegará a mediados del 2008 con el Service Pack 1 de Windows Vista, pero aún no es seguro ni hay una fecha exacta. Así aseguran que los desarrolladores de hardware ahora se tendrán que centrar en conseguir mejor rendimiento con sus VGAs con DX10 y 10.1 y no a buscar nuevas funciones exclusivas. Veremos si esto mejora un poco la optimización de recursos tanto por parte de los fabricantes como de los desarrolladores de software.
Naturalmente esto significa que Microsoft y sus compañeros de desarrollo pondrán ahora su empeño en el desarrollo de la siguiente API, bautizada de momento como DirectX 11, pero de momento esto queda en un futuro relativamente lejano y poco preocupante para nosotros.
http://www.noticias3d.com/noticia.asp?idnoticia=22704
Lo más llamativo es que el hardware diseñado para la versión 10.1 de la API de Microsoft será retrocompatible, pero las actuales tarjetas con soporte DirectX 10 no lo soportarán. Se espera la aparición de este nuevo hardware para la primera mitad de 2008, pero hay que tener en cuenta que el Service Pack 1 de Windows Vista todavía no está terminado. Diferencias destacables entre las dos versiones será que algunas características opcionales en DirectX 10 pasarán a ser estándares obligatorios (por ejemplo, el filtro Anti-Aliasing 4x será obligatorio en la nueva versión cuando en DX10 era algo opcional), y también ofrecerá a los desarrolladores un mejor y mayor control sobre la calidad de imagen.
ATI Radeon HD 3800 Series and DirectX 10.1 Ping Pong Demo
Link
Juegos con Directx 10.1
FarCry 2 Como no lo he probado no se cual es la diferencia con o sin directx 10.1
http://foro.noticias3d.com/vbulletin/showthread.php?t=261927
S.T.A.L.K.E.R: Clear Sky
http://www.noticias3d.com/noticia.asp?idnoticia=29166
Assessing Creed que sacaron un parche para quitar las directx 10.1
Physx CUDA en dos juegos conocidos
Cryostasis DX10-Techdemo
Link
http://www.youtube.com/watch?v=fQMbFQVLhMc
Cryostasis gameplay
Link
http://www.youtube.com/watch?v=AWQnuHPQt8k
Mirror’s Edge PhysX effects on the PC
Link
http://www.youtube.com/watch?v=tvhw_v3q4L8
Explicación aquí.
http://www.gameprotv.com/foro/viewtopic.php?t=73820
Quake 4 usando Ray tracing en tiempo real
Hablar de RayTracing es hablar de secuencias generadas por ordenador que son indistinguibles de la realidad. El inconveniente de esta técnica es que, sus requerimientos de procesador son tan enormes, que cada fotograma requiere varios minutos para generarse. Debido a esto, el uso de esta técnica en videojuegos era impensable, quedando limitada a la industria del cine y a las aplicaciones de CAD. Sin embargo, el incremento en la potencia de los procesadores puede hacer que, en un futuro mas o menos próximo, esta técnica también pueda utilizarse en videojuegos.
En primer lugar, ¿Que es el RayTracing? En los juegos actuales, el proceso para generar un fotograma de pantalla comienza con los modelos 3D de los objetos, siendo cada modelo una lista de polígonos que definen el modelo. El primer paso es seleccionar los polígonos que se ven en pantalla; luego, a cada polígono se le aplica las transformaciones necesarias (si recibe luz, se le aplica un brillo correspondiente con esa luz; si debe mostrar alguna imagen, se le imprime dicha imagen, …), luego se le aplican los escalados y giros necesarios, y por ultimo se imprime en pantalla. En RayTracing, partimos de los pixels de pantalla; para cada pixel, seguimos su línea de visión (la línea que recorrería el rayo de luz que lo “ilumina”), hasta llegar al objeto que “produce” ese rayo de luz. Si, a su vez, el objeto es un espejo o un cristal (es decir, no tiene un color propio, sino que transforma la luz que recibe), entonces continuamos el proceso; seguimos el rayo de luz que indice sobre ese punto del objeto, y así sucesivamente hasta llegar a la fuente original de luz.
Dicho con otras palabras, que el RayTracing funciona al reves que las técnicas de rendering convencionales; si en estas el punto de partida es el objeto y llegamos hasta la pantalla, en RayTracing el punto de partida es la pantalla y desde ahí llegamos hasta los objetos. Y aquí es donde reside el problema; en las técnicas de rendering convencionales, partimos de una estructura de alto nivel (la definición del objeto 3D), que vamos descomponiendo en piezas mas pequeñas y simples, hasta llegar a un flujo de números sobre el que hay que realizar operaciones aritméticas; es decir, buena parte del trabajo son algoritmos de bajo nivel susceptibles de ser implementados en hardware, en coprocesadores específicos (las GPUs).
En cambio, en RayTracing todo el trabajo se hace sobre las definiciones 3D de los objetos, lo que implica que todo el proceso son algoritmos de alto nivel para los que es muy dificil crear un hardware específico que produzca una mejora visible del rendimiento. De hecho, para generar las escenas para películas cinematográficas se utilizan granjas de PCs totalmente convencionales, sin ningún tipo de hardware específico.
Pero las cosas están cambiando; un equipo alemán ha desarrollado openRT, una librería para realizar raytracing en tiempo real, librería que está disponible para descarga. Así, un estudiante llamado Daniel Pohl ha reescrito los motor es de renderización de Quake 3 y Quake 4 para basarse en dicha librería, con lo que estos juegos han pasado a funcionar sobre raytracing. ¿Los resultados? Podemos verlos en estas dos páginas:
Quake 3 sobre OpenRT
Quake 4 sobre OpenRT
Y aquí tenemos los vídeos:
Quake 3 con raytracing
Link
Quake 4 con raytracing
Lo mas impresionante de estas demos no son los juegos en si, sino sus requerimientos: el equivalente a un procesador de 36Ghz; mas concretamente, para efectuar este renderizado se utilizo un cluster de 20 procesadores Athlon-XP. ¿Veremos algún día juegos con RayTracing? Por supuesto, todo dependerá de que se consigan crear tarjetas gráficas específicas; de momento, los creadores de OpenRT han creado saarcor, un coprocesador que implementa el soporte de RayTracing. Según explica, con la ayuda de este chip estas versiones de Quake pueden funcionar en un Athlon-XP convencional.
http://teleobjetivo.org/blog/quake-4-usando-ray-tracing-en-tiempo-real.html
——————————————————————————–
Intel también trabaja en el ray-tracing
Una de las bromas del April’s fool day fue el anuncio de DirectX 11, que supuestamente soportaría ray-tracing. Lo que si que es cierto es que todos los grandes de la electrónica están trabajando en el ray-tracing, entre ellos Intel.
Ray-Tracing es una técnica de iluminación tremendamente pesada, por lo que es imposible utilizarla para la generación de gráficos en tiempo real; así, su uso se ha visto limitado al cine, donde lo importante es la calidad gráfica y no el tiempo que tarde en generarse cada fotograma.
Actualmente, los ordenadores personales ya empiezan a tener suficiente potencia como para poder producir ray-tracing en tiempo real, para poder utilizarlo en videojuegos. De hecho, en Teleobjetivo ya hablé de unas versiones de Quake que utilizaban Ray-Tracing; se basaban en OpenRT, un motor gráfico de raytracing implementado como unas extensiones de OpenGL. También he hablado de un software de ray-tracing para Cell desarrollado por IBM, que mostraron en una demo que corría sobre PS3.
Intel no podía quedar fuera de esta carrera, así que también ha presentado sus propias demos; a continuación podemos ver una demo de ray-tracing a tiempo real sobre un procesador de ocho núcleos.
Link
Una de las peculiaridades de Ray-Tracing es que es una técnica gráfica que se ha de implementar en software. Aunque se han diseñado algunos procesadores específicos, como el SaarCOR, la mejor manera de implementar ray-tracing es mediante procesadores multinúcleo de propósito general. Una mala noticia para los fabricantes de tarjetas gráficas, aunque NVidia se ha puesto las pilas y sus últimas GPU son combinados CPU/GPU con procesamiento de proposito general.
En cualquier caso, para alegría de los gamers, se da por seguro que la llegada del ray-tracing será el final de las tarjetas gráficas dedicadas. Una buena noticia para Intel y AMD, pero muy mala para NVidia.
http://teleobjetivo.org/blog/intel-tambien-trabaja-en-el-ray-tracing.html
Todo aquí
http://www.gameprotv.com/foro/viewtopic.php?t=94528&postdays=0&postorder=asc&start=0
y aquí
http://www.gameprotv.com/foro/viewtopic.php?t=73820&highlight=cuda
NVIDIA
¿La tecnologia Ageia en CUDA?
Como ya sabéis, NVIDIA, anda finalizando estos días la compra oficial de AGEIA, creador de la tarjeta PhysX, y como no le parecía suficiente ha dejado caer varios detalles de los planes que tiene en mente la firma del camaleón.
Hace poco despotricábamos (en nuestros foros) a AGEIA por su poca cabeza a la hora de entrar en el mercado de los juegos y a NVIDIA porque tardarían lustros en hacer algo con esta nueva adquisición, pues bien, Jen-Hsun huang, presidente de la casa, ha declarado que próximamente integrarán el motor software o API de la tarjeta PhysX en la tecnología CUDA de NVIDIA. La tecnología CUDA (Compute Unified Device Architecture) permite a los desarrolladores usar los procesadores gráficos para cálculos diversos sin que tengan relación con la información que se vaya a visualizar en 3D.
Todos los procesadores que soporten CUDA (incluye la serie 8 ) podrán utilizar esta tecnología ya que al parecer no necesitaremos más que descargar el programa y punto. Aun no se sabe si vendrá integrado en los ForceWare o como programa a parte, pero Huang ya se frota las manos y espera vender aun mas de gráficas para supuestas plataformas SLI y 3-way SLI.
http://foros.3dgames.com.ar/hardware.31/453805.nvidia_ya_ha_adaptado_el_motor_f_sica_ageia_cuda.2.html
————————————————————————–
Cuando Nvidia anunció la adquisición de Ageia la pregunta era ¿qué hará Nvidia con la nueva compra? Una de las respuestas era que la absorbiera y la hiciera desaparecer como marca al igual que hizo con 3dfx cuando la compró. Pero ayer se despejaron las dudas cuando el CEO de Nvidia dijo que integrarán el motor de física PhysX en su línea 8000 de tarjetas gráficas.
La implementación no es a nivel hardware, sino a nivel software. El motor PhysX se fusionará con CUDA, una tecnología para programar los GPUs y utilizarlos para operaciones no-gráficas que empezó a ser soportada por la serie 8000 de tarjetas de Nvidia. De esta manera, cuando esté listo, con solo bajar una actualización del controlador de la tarjeta gráfica se estará haciendo funcionar al GPU como un procesador de física al mismo tiempo que como un procesador gráfico.
De esta manera Nvidia apunta, no solo a ampliar el uso de sus GPUs, sino también a darle al SLI una nueva utilidad. Dado que con el motor PhysX integrado, en un sistema SLI se podrá usar una tarjeta para el procesamiento gráfico y la otra para el procesamiento de la física. Habrá que ver qué tan efectivo lo pueden hacer, ya que el desempeño de estas implementaciones depende pura y exclusivamente de la calidad del software, pero más intriga me genera lo que hará AMD/ATI para mantenerse competitiva frente a la más poderosa que nunca Nvidia.
Fuente: DailyTech
Activity pensamientos…..:
Creo que por ahora es todo un cuento chino…..por ahora,pero viendo que ha pasado estos días y viendo nueva versión de ageia drivers pues creia que iban a sacar lo de CUda ya,pero veo que no,tambien en los foros y por donde se habla del tema,las pruebas de Cuda fueron en Nehalem,que quiero decir pues que lo más seguro que hasta que no salga Nehalem en diciembre dudo que salga lo de CUDA.Lo de implimentar ageia Hardware por Software en CUDA me parece ciencia ficción,pero bueno todo puede pasar,tambien me preocupa el hecho de si será necesario SLI o no,si el tener CUDA ralentizará las tarjetas y por tanto solo una nueva generación de Nvidia serie 9900 o la serie 10 saque partido de ello,y solo sea marketing por parte de Nvidia ahora,para vender más,como se ha visto recientemente Ati tiene directx 10.1 pero como no salia en ningún juego todos criticaban eso como una api inutil y que era solo marketing ahora se ha visto que no era así y que saca al renderizar una sola vez un 20% más rapido,pues lo mismo en CUDA,todas las Nvidia desde la serie 8 y la 9 tienen esos dentro de la tarjeta,por tanto solo hace falta una buena implimentación sosftware y funcionará,pero mis dudas tengo al respecto ya que no ha salido y una demo..en cambio ati tiene una demo de directx 10.1,vamos que se ve que eso es real…El CUDA si saliera a la luz y verdaderamente hiciera lo que queremos hundiria a ATI.Pero todos en este foro sabemos que repercutira en que la grafica vaya más lenta al tener que hacer otro tipo de trabajo,no es que no este preparada,ya que tiene CUDA,es que tampoco los de Nvidia lo han puesto a trabajar,actualmente trabaja Havok en casi todos los juegos o ageia,por tanto CUDA para muchos es una incógnita.
Fecha, no han dado pero yo diría que con la salida de Nehalem ya que creo que tiene algo que ver.Tambien como podeis leer será necesario un sli en Nvidia,pero existe algo parecido en Ati.
ATI
AMD confirma los requerimientos de aceleración de física asimétrica.
AMD ha desvelado ya los requerimientos de aceleración de física que ATi empezó ya a desarrollar antes de que AMD la comprara.
Se llama aceleración de física asimétrica y puede funcionar en dos modalidades: Una placa compatible con Crossfire, en la cual se colocan dos gráficas, una como aceleradora 3D y la otra destinada a cálculos de física. La otra modalidad consiste en tener una placa base compatible con Triple Play con un Crossfire montado, en la que se usa la tercera ranura PCIe 16x para dedicar una tercera Radeon al procesamiento de física.
http://www.madboxpc.com/contenido.php?id=1992
Lo que quiero decir que tanto Nvidia como Ati tienen algo parecido,aunque Nvidia al tener ageia y su producto tienen más posibilidades de hacer algo mejor.
http://www.tweaktown.com/articles/908/computex_2006_video_of_ati_s_hardware_physics_in_action/index.html
Video
http://www.tweaktown.com/files/ati-talks-about-hardwarephysics.avi
ATI shows three GPU physics
Link
Como podeis ver tanto lo de ageia por hardware como lo de Ati es más real,además de estar por video,CUDA es algo que no es real aún.
ATI Hardware Physics Demo
Link
Pero vamos en Ati será obligatorio el tener Crossfire de eso seguro como se puede ver.En Nvidia a lo mejor con una solo es suficiente.Pero si es en SLI seguro que irá.Me se de uno del foro con dos 8800GT que se le hace la boca agua….yo es que tengo envidia….jajaja.
Reflexión:
¿Si teneis SLI o Crossfire,que preferis que la segunda tarjeta os ayude en las texturas y la resolución o que se dedique a la física y perdais detalles y texturizado….sobre todo en juegos como Crysis o FarCry2?.
Havok
El paquete Havok Complete, que incluye el motor de física Havok Physics y la solución de animación Havok Animation, podrá descargarse gratis a partir de mayo en su versión para PC. Los desarrolladores tendrán vía libre para usarlo en proyectos no comerciales. Havok espera que los principales beneficiarios de esta iniciativa sean los desarrolladores independientes, las instituciones educativas y los desarrolladores amateurs. Además, Intel, la empresa propietaria de Havok, dejará usar el paquete comercialmente gratis a los desarrolladores que aprueben.
Havok ha aprovechado la GDC que se celebra esta semana en San Francisco para presentar dos nuevas herramientas: Havok Cloth, orientada al manejo de ropa, y Havok Destruction, destinada al control de objetos destructibles en los juegos.
Intel compra Havok y su motor 3D
En una nota de prensa del 14 de septiembre, el numero uno mundial del microprocesador, Intel, anuncia haber firmado un acuerdo definitivo de adquisición de la empresa irlandesa Havok. Fundada en 1998, esa empresa se dedica al desarrollo del motor físico del mismo nombre, cuyos componentes, Havok Physics y Havok FX, están utilizados en títulos tales que BioShock, Stranglehold, Halo 2, Half Life 2, Oblivion, Crackdown o Motorstorm.
“Esa compra permitirá a los desarrolladores especializados en la animación digital y a las comunidades de jugadores de disfrutar de las capacidades de Intel en materia de innovación y su posición privilegiada en el mundo de la creación digital”, indica la empresa de Santa Clara.
Según David O’Meara, CEO de Havok, la adquisición permitirá a su empresa desarrollar sus actividades en nuevas direcciones. Recordamos que Havok no solo se ha hecho un nombre en el videojuego sino que también sus productos se usan en el ámbito de la modelización 3D así que la animación digital a destinación del cinema. Películas tales que Matrix, Troya o Charlie y la fábrica de chocolate utilizaron herramientas de Havok.
La empresa acababa de anunciar la proxima salida de la versión 5 de su motor durante el Austin Game Developers Conference. Para Intel la operación podría ser doble, optimizar un motor bastante popular para su arquitectura Core 2 y también ampliar sus conocimientos en materia de 3D para eventualmente integrarlo en su proyecto Larabee. Los detalles financieros de la transacción no fueron revelados.
Havok será gratuito en mayo
Los desarrolladores podrán descargar el paquete Havok Complete para PC.
El paquete Havok Complete, que incluye el motor de física Havok Physics y la solución de animación Havok Animation, podrá descargarse gratis a partir de mayo en su versión para PC. Los desarrolladores tendrán vía libre para usarlo en proyectos no comerciales. Havok espera que los principales beneficiarios de esta iniciativa sean los desarrolladores independientes, las instituciones educativas y los desarrolladores amateurs. Además, Intel, la empresa propietaria de Havok, dejará usar el paquete comercialmente gratis a los desarrolladores que aprueben.
Havok ha aprovechado la GDC que se celebra esta semana en San Francisco para presentar dos nuevas herramientas: Havok Cloth, orientada al manejo de ropa, y Havok Destruction, destinada al control de objetos destructibles en los juegos.
PD:El tercero en discordía,es gratis,lo utilizan en casi todos los juegos,StarCraft 2 es el que va por defecto,por tanto tanto Nvidia como Ati estan preparadas para este código de físicas….es como decirlo,física universal para todas las tarjetas.
Comentarios recientes