¿Importa si aprendo OpenGL o Direct3D?


11

¿Son las diferencias entre estos dos detalles de implementación menores de las API que significan que una vez que he aprendido una, puedo usarla para todo? ¿O hay razones para aprender una en lugar de la otra si quiero poder usarla en general sin tener que volver a aprender otra API en el futuro? ¿Es uno u otro más general?

En particular, me gustaría poder escribir para cualquier tarjeta gráfica, por lo que el código no se limita a ejecutarse solo en las tarjetas de un fabricante en particular o en un modelo específico. También me gustaría poder escribir código que todavía funciona en ausencia de una tarjeta gráfica (aunque más lento).

¿Hay alguna diferencia en la forma en que el código portátil será a través de diferentes plataformas (sistemas operativos / arquitecturas)? Estoy interesado en la disponibilidad de otras bibliotecas que funcionan con ellas, y si una u otra conlleva menos restricciones de licencia en su entorno más amplio. Cualquier cosa medible que marcaría la diferencia de si uno de estos podría ser el único que aprendo sin restringirme.


2
La respuesta de Ratchet Freak es buena. Si quieres aprender Direct3D puedes leer mi libro gratuito "The Direct3D Graphics Pipeline" . Los detalles de la API son principalmente Direct3D9, pero los conceptos son los mismos. La cuestión es que los conceptos para la programación de gráficos en 3D realmente no han cambiado en absoluto desde finales de la década de 1960. Las API para expresar esos conceptos se han vuelto mucho más inteligentes.
legalizar el

Respuestas:


9

No creo que importe mucho, qué API quieres usar cuando te inclinas por los "gráficos de programa". Lo más importante que debe aprender son los conceptos típicos que utiliza cuando trabaja con escenas 3D. Por ejemplo, desea aprender a escribir un gráfico de escena simple (y luego más sofisticado). Estos conceptos son mucho más importantes que los nombres de métodos de API específicos a los que debe llamar.

Compárelo cuando aprenda a escribir programas. Si eres bastante bueno escribiendo programas en, por ejemplo, Java, no tendrás tantos problemas para aprender C ++, Objective-C, Swift u otro lenguaje orientado a objetos. Porque son los conceptos y el pensamiento lo que aprendes.

La elección entre OpenGL, Direct3D y Metal es principalmente la elección, a qué sistema operativo se dirige. Direct3D está disponible principalmente en Windows, Metal en OS X e iOS, y OpenGL es compatible con la mayoría de los sistemas, incluidos OS X, iOS, Windows y Linux.

La tarjeta gráfica probablemente tenga poca o ninguna influencia en esta decisión, ya que no conozco una tarjeta que admita solo una o dos. Si no tiene una tarjeta gráfica dedicada, el renderizado en tiempo real será un problema pronto. Aunque un Intel HD Graphics y el compañero AMD ya pueden hacer mucho.

Entonces, elige tu plataforma.


Descargo de responsabilidad: a partir de ahora, no utilicé Direct3D ni Metal.


2
> "Si eres bastante bueno escribiendo programas en, por ejemplo, Java, no tendrás tantos problemas para aprender C ++", esto no es cierto. Todos tendrán enormes dificultades para aprender y usar C ++. Compararlo con Java o cualquier otro lenguaje seguro es completamente inapropiado. Sin embargo, para otros lenguajes que enumeró (Objective-C, Swift u otro lenguaje orientado a objetos), esa afirmación es mayormente cierta.
Nombre para mostrar el

9

Actualmente estamos en una transición de paradigmas API.

El método de la vieja escuela de vincular buffers, uniformes, atributos, diseño y programas como estado global (implícito) y enviar sorteos con ese estado es común en D3D11 y OpenGL. Sin embargo, tiene una gran cantidad de gastos generales (en estado de verificación y sin saber lo que el programa quiere hacer hasta el último minuto). Tampoco son seguros para subprocesos (en su mayor parte).

Esta es la razón por la que han aparecido nuevas apis (o vendrán pronto) D3D12, siendo vulkan y Metal los más destacados. Estas API le dan más control al programa y le permiten declarar de antemano lo que quiere hacer usando los buffers de comandos. También le permiten administrar sus propios recursos (datos de vértices, texturas, ...) mucho más directamente. Usarlos con múltiples es mucho más sencillo.

La elección entre lo antiguo y lo nuevo se basa en qué tan bien puede administrar la memoria de video que asigna y construir el búfer de comandos.

  • Si desea algo que "simplemente funciona" incluso en hardware antiguo, las API de la vieja escuela son mejores; También son más conocidos y obtendrá más ayuda en línea.

  • Por otro lado, si puede manejar la naturaleza asincrónica de los comandos de envío y no le importa tener que rastrear todos los buffers que asigna. Entonces las nuevas API pueden ser algo para ti.


66
Las nuevas API de gráficos explícitos no están realmente diseñadas para el consumo del programador de gráficos promedio, son más para las personas que realizan trabajos de infraestructura en motores o para aquellos que realmente necesitan el rendimiento. Te dan un arma mucho más grande y apuntan directamente a tu pie.
porglezomp

3

Personalmente no creo que importe mucho. Simplemente elija uno que se adapte a su proyecto. He usado tanto D3D como OpenGL en el pasado. Son los conceptos los que importan. Lo que agarres, debes entender (por ejemplo):

  • Qué son las texturas y cómo las usa la GPU.
  • Conceptos básicos de desarrollo de gráficos (vértices, primitivos, fragmentos, etc.)
  • Cómo funciona el sistema de cámara (matrices MVP en OpenGL, por ejemplo).
  • Qué son los sombreadores y cómo usarlos correctamente.
  • Qué tan diferente funciona una GPU frente a la CPU en su máquina.
  • ¿Cuáles son las diferencias entre el modelo de memoria de la GPU y el modelo de memoria de la CPU?
  • Qué se debe hacer en la CPU y qué se debe descargar a la GPU para su procesamiento.

Como otros mencionaron aquí, estamos en medio de una transición a un nuevo conjunto de API (Vulkan, Metal, etc.), por lo que en este punto si es completamente nuevo en el Desarrollo de Gráficos, probablemente centrarse en GLSL es una buena idea ya que Vulkan va a aprovecharlo también.

Con respecto a la portabilidad, D3D es solo para Windows (hay rumores de que el proyecto Wine está tratando de hacer que D3D funcione en Linux, pero hasta ahora no es posible). OpenGL es multiplataforma. Si desea utilizar dispositivos móviles, OpenGL ES es una opción disponible. Por supuesto, tanto OpenGL como OpenGL ES tienen versiones diferentes que no son compatibles con todas las plataformas.

Al final del día, todas las API acceden al mismo hardware en su máquina, es solo cuestión de "cómo" acceden a él.


Direct3D también es lo que usaría si está programando para cualquiera de las consolas Xbox.
legalizar el

¿Qué quieres decir con "nada factible"? Wine ejecuta cientos de programas basados ​​en D3D sin problemas, y lo ha hecho durante años. Por supuesto, hay errores y partes no implementadas, pero eso no hace que toda la API sea inutilizable.
Ruslan

0

Diré algunas palabras sobre renderizar sin tarjetas gráficas.

Niether OpenGL ni DirectX realmente necesitan una tarjeta gráfica. Una implementación puede ser completamente acelerada por software.

Para OpenGL en Linux existe el rasterizador de software Mesa. En mi experiencia, funciona bien siempre y cuando no lo presiones demasiado combinando características extrañas (lista de visualización + matrices de vértices indexadas). Me imagino que su lista de errores reales tiene una milla de altura. ¡Asegúrate de hacer pruebas continuas!

Tengo menos experiencia usando OpenGL en Windows. ¡Edita la respuesta si sabes algo!

DirectX SDK se entrega con un rasterizador de software llamado "rasterizador de referencia". En mi opinión, es principalmente para la depuración, pero sé de al menos un amigo que usa el rasterizador de referencia al desarrollar DX11 en una computadora portátil solo compatible con DX10. Como se menciona en otras respuestas, DirectX es solo de Microsoft.


En mi experiencia, usar una tarjeta gráfica integrada debería ser lo suficientemente bueno para la mayoría del desarrollo de OpenGL en Windows, solo asegúrese de que sea compatible con una versión reciente de OpenGL.
akaltar
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.