Mostrando entradas con la etiqueta direct3d. Mostrar todas las entradas
Mostrando entradas con la etiqueta direct3d. Mostrar todas las entradas
miércoles, 14 de julio de 2010

Porque Direct3D > OpenGL? otras 10 razones

0 comentarios
 
Ya que estamos en la polemica... hay que hacer lo opuesto tambien!

1) Direct3D viene con Windows,

OpenGL viene con el driver. A las versiones de los drivers de OpenGL que vienen con windows, se les saca el soporte de OpenGL a proposito.
En la practica esto no afecta tanto, ya que en USA, Europa, etc casi todas las PCs son de marca, y los OEM les instalan los ultimos drivers
disponibles. Pero en el "tercer mundo" no es tan asi..

2) OpenGL 2.0 No esta disponible en Intel GMA.

Intel no provee soporte de OpenGL 2.0 en sus drivers de Windows (pero si soporte de Directx9c). Solo llega hasta GL 1.4.
En Mac, intel SI provee soporte de GL2, y el driver semioficial/opensource de X11 (Linux) tambien lo soporta, asi que el hardware no es el problema. Probablemente una decision politica de parte de Intel, o algun arreglo con Microsoft. Esto es un problema importante, dado que todas las notebooks y PCs OEM que vienen con procesadores Intel, vienen con GMA.

3) OpenGL >1.1 no viene con Visual Studio.

Microsoft no provee practicamente soporte para OpenGL, todo en windows se hace con extensiones. Por suerte existe GLEW, pero no se actualiza tan seguido. DirectX viene con el DXSDK.

4) Direct3D implementa los nuevos features primero.

El orden usualmente es
a) Direct3D saca una nueva especificacion
b) NVidia/ATI implementan hardware
c) OpenGL hace su version

Aunque en esta ultima iteracion, OpenGL 4 se adelanto a nvidia, pero nunca se sabe..

5) Direct3D define muy bien lo que soporta el hardware

En teoria OpenGL tambien, mediante extensiones, pero en la practica, Nvidia implementa muchos mas fetures en OpenGL
de lo que la placa soporta, y los emula por software, lo que lo hace inusable, y bastante complicado de adivinar que feature
no usar en que placa, para evitar que todo vaya a 1fps.

6) Direct3D compila los shaders siempre igual.

Si el shader compila en Nvidia, va a compilar en ATI. En OpenGL se supone que es lo mismo, pero ATi se queja de mas cosas que Nvidia, lo cual hace bastante dificil escribir shaders que compilen en todas las plataformas.

7) Direct3D9 soporta instancing, OpenGL no.

El hardware SM3 en Direct3D9 soporta instancing, en OpenGL no. Si bien multiples llamadas a glDrawElements/Arrays son baratas en OpenGL, se empieza a volver costoso pasando los miles de elementos, (ej: al dibujar pasto).

8) Direct3D9 viene con muchisimos ejemplos oficiales.

La calidad de la documentacion de D3D y GL es bastante debatible, pero lo cierto es que D3D esta lleno de ejempos que vienen con el SDK, y con licencias permisivas. Si bien en GL hay bastante, encontrar en internet es mas complicado. En D3D es mas comodo y se pierde menos tiempo. En general la mayoria de los papers de game developes son en D3D, y la mayoria de los papers cientificos son en GL.

9) Direct3D viene con mas herramientas para debugear Direct3D

PIX, mejor soporte de FX composer, D3DDebug, etc.

10) Direct3D Impulsa a la industria

Gracias a que Microsoft impulsa a la industria con D3D e impone el ritmo,
sigue saliendo nuevo hardware e Intel/ATI/NVidia se ponen de acuerdo.
Cuando OpenGL era el estandar, cada placa tenia sus propias extensiones
que no estaban soportadas en las demas, haciendo programar juegos mas complejo.
(Ej, ATI truform, Nvidia con Combine4, etc).

Fuente: http://www.adva.com.ar/foro/index.php?topic=7006.0
Leer entrada
miércoles, 30 de junio de 2010

Porque OpenGL > Direct3D? 10 razones.

0 comentarios
 
El Sr. Engine ha recorrido un larguisimo camino, y la verdad es que finalmente se empieza a sentir que falta poco.
Aca hay una escena de prueba en progreso (todavia no esta terminada), lo mejor de todo es que por como esta programado, y gracias a hacks que solo se pueden hacer en OpenGL (no en Direct3D) esto corre de forma safable hasta en una geforce 6100.



No hay nada precomputado (lightmaps/ambientmaps/etc), todo es en tiempo real.
En gran parte, gracias a OpenGL. Porque?
Primero a todo cabe recordar que estoy refiriendome a GL 2.1 vs Directx9 (D3D10 y GL3 son casi identicos), pero si uno quiere hacer algo que corra en todas las computadoras, no se puede usar Directx10 o GL3 de cualquier forma Lengua

1) Batching

Las llamadas a funciones de GL son infinitamente mas baratas que en D3D, primero por no tener que usar objetos sino porque los comandos se batchean en userspace y luego se envian al driver. (en Direct3D casi todo va directo al driver). Esto permite hacer cambios de materiales/shaders/binder arrays/etc con bajo costo.

2) Built-in uniforms

OpenGL 2.1 tiene todo el estado del fixed pipeline accesible, todas las luces, materiales, etc. Esto permite, con un poco de esfuerzo, no usar uniforms y crear shaders extremadamente chiquitos, maximizando la posibilidad de usar conditonal compilation, ya que el estado es persistente aun al cambiar entre shaders (algo asi como bindable uniforms en placas antiquisimas), y el cambio entre shaders es casi gratis (gracias al batching y a que no hay que subir uniforms), se pueden dibujar ej, multiples luces en un pase y cambiar entre combinaciones de luces a una performance enorme.


3) Fast/deferred shader compiles

La compilacion de shaders en OpengL es rapidisima. Sencillamente rapidisma. Principalmente porque el compilador solo pasea el codigo y luego
hace el resto de la compilacion on-demand (cuando el shader se usa). Se puede compilar cientos de shaders en pocos segundos.
En D3D, la compilacion comparativamente es mas lenta ya que hay varios pasos: a) Compilacion a assembler (D3DX) b) Subir el assembler c) El assembler de D3DX decompilado por el driver y recompilado optimizado para la placa (ya que los video card vendors optimizan cada uno para su placa). En la teoria, D3D permite guardar shaders precompilados, lo que agiliza el proceso, pero en la practica, este ultimo paso hace que no sea demasiada la diferencia.

4) Persistent attributes/texcoords

Los texcoords y los attributes son persistentes. Esto quiere decir que siempre estan aunque no se bindeen (el ultimo valor queda puesto). En contraste, Direct3D9 prohibe crear shaders que usan un texcoord/ que no esta bindeado en el streamsource. Sencillamente el shader no funciona.
Esto es horrible, porque no permite a un engine tener una separacion entre geometria y material sin tener que compilar una version del shader que use los mismos arrays que tiene la geometria.

5) Readable/Writable Depth Buffer

Los depth buffers se pueden bindear como textura y leer en OpenGL, y no solo eso sino que se filtran aun en el hardware mas viejo (siempre y cuando sean potencia de 2!). Que permite esto? hacer muchisimas cosas en hardware viejo que nada mas se puede hacer en Directx10, vista+, como por ejemplo


  • Recuperar la posicion de un fragment




  • Shadow maps super baratos (solo escribir a un depth buffer), mas baratos aun usando un depth buffer de 16 bits




  • ESM (Exponential Shadow Maps) baratisimos en hardware antiquisimo, aprovechando que se pueden leer/escribir usando gl_FragDepth para blurear, y filtrar




  • ZClipping de particulas, con borders fadeados




  • SSAO superbarato (lee del depth buffer / escribi al shadow buffer)




  • DOF superbarato





  • 6) read/write buffers y CopyTexSubImage

    Algunas tecnicas requieren hacer copias de buffers. GL provee read/write buffers, para hacer esto sin tener que usar shaders/geometria, lo cual tambien es considerablemente mas rapido.
    GL Permite habilitar/deshabilitar la escritura a diferentes componentes de un framebuffer. Esto esta _buenisimo_, por ejemplo para guardar datos en componentes en diferentes pases. Tecnicas que me resultaron barbaras usado esto fueron glow send en el canal alpha (y bloquearlo cuando se dibujan objetos con transparencia) y especialmente util para tecnicas como dual paraboloid shadow mapping o PSSM, porque puedo guardar los datos (depth) en una sola textura si quiero, ayudar un monton al cache y liberar texunits.

    8) Built-in TC

    En Direct3D existen formatos comprimidos de textura, pero hay que subir los datos a mano comprimidos, o tenerlos ya guardados. Si bien se esta poniendo de moda en DirectX10 hacer la compresion a DXT,BC,etc en un shader en el momento de subir la textura. OpenGL hace la conversion automaticamente (al pedirselo) aun en placas antiguas.

    9) Built-in memory Management

    En Direct3D hay diferetes tipos de memoria (pools) a donde van los arrays, las texturas, etc. Cada uno tiene diferentes restricciones. Si uno elige enviarlo a la memoria de video, entonces la textura o el array no se pueden recuperar.. y si llega a ocurrir un devicelost (que sucede tan solo al resizear una ventana Cheesy), se pierde todo! Algunos engines manejan todo a mano, pero la verdad es que es un bajon tener que preocuparse donde esta cada cosa, asi que Direct3D ofrece una opcion MANAGED, que guarda una copia en memoria de sistema del recurso. Si alguna vez se preguntaron porque los juegos de D3D ocupan tanta memoria, esa es la respuesta . Windows Vista virtualiza la memoria de video para evitar eso cuando el hardware lo provee. OpenGL en cambio sube y baja los recursos de memoria de video cuando es necesario y hasta provee algoritmos de LRU en hardware antiguo, el programador no se tiene que preocupar donde va todo, o a lo sumo proveer hints de uso.

    10) OpenGL es un estandar 

    OpenGL es un estandar, se puede programar/ejecutar en linux, windows, mac, celulares, tabletas, etc.

    Fuente: http://www.adva.com.ar/foro/index.php?topic=7005.0
    Leer entrada