¿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.
Respuestas:
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.
fuente
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.
fuente
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):
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.
fuente
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.
fuente