- Minecraft Java Edition cambia su motor de renderizado gráfico de OpenGL a Vulkan
- El cambio se debe a la falta de actualizaciones de OpenGL y al fin de su soporte en macOS tras décadas de uso desde los años 90
- Vulkan ofrece soporte nativo en Windows y Linux, y en macOS funciona mediante una capa de traducción sin pérdida de rendimiento
- Con esta transición se espera una mejora en la calidad visual y en la tasa de fotogramas
- Tras probar OpenGL y Vulkan en paralelo en snapshots, planean retirar OpenGL cuando la estabilidad esté garantizada
Bringing modern rendering to Java
- En Minecraft: Java Edition continúan los preparativos para Vibrant Visuals, con trabajo de refactorización y modernización del código de renderizado
- En actualizaciones anteriores ya se realizaron mejoras en la estructura del código de renderizado
- Ahora entran en la etapa de reemplazar la propia tecnología base del renderizado
- Está previsto cambiar la tecnología de renderizado del juego de OpenGL a Vulkan
- El objetivo es abrir nuevas posibilidades en gráficos y rendimiento
- Se espera que esto afecte a la comunidad de modding y a algunos jugadores
What are we changing?
- Actualmente, Java Edition usa la API gráfica OpenGL, creada en los años 90
- Se ha mantenido basada en OpenGL desde sus primeros lanzamientos
- La razón para adoptar OpenGL fue que permitía compatibilidad con Linux, Windows y macOS
- Estaba diseñado para ejecutarse en casi cualquier PC y Mac
- OpenGL dejó de actualizarse hace 9 años, está deprecated en macOS y en el futuro dejará de poder ejecutarse allí
- Para mantener compatibilidad con macOS tuvieron que quedarse en una versión antigua de OpenGL, lo que dificultó modernizar la base de código
- Para que Java Edition siga funcionando en la mayoría de las PC, incluyendo macOS y Linux, era necesario dejar atrás OpenGL
Introducing: Vulkan
- Vulkan es una API gráfica con más de 10 años en el mercado y adoptada ampliamente por los principales fabricantes de hardware
- Tiene soporte nativo en Windows y en distribuciones modernas de Linux; en macOS puede usarse mediante una capa de traducción y funcionar sin pérdida de rendimiento
- A largo plazo, abre la puerta a mejoras de rendimiento y a ampliar funcionalidades
- Proporciona la base necesaria para implementar Vibrant Visuals
- Existe la posibilidad de que GPUs con más de 10 años no sean compatibles con Vulkan
What does this mean for modders?
- Al pasar de OpenGL a Vulkan, habrá impacto en los mods de renderizado basados en OpenGL
- Se espera que la transición a Vulkan requiera más trabajo que adaptarse a una versión normal del juego
- Recomiendan a la comunidad de modding reducir su dependencia de OpenGL
- Aconsejan reutilizar al máximo la API interna de renderizado
- Si hace falta, es posible discutir aspectos técnicos directamente con el equipo de desarrollo
- Las discusiones técnicas se están realizando en el canal de Discord de Vibrant Visuals
- No es un canal de anuncios, sino un espacio para conversaciones técnicas profundas entre desarrolladores
What does this mean for players?
- Algunos mods podrían verse afectados durante la transición
- Los creadores de mods necesitarán tiempo para actualizarlos
- En futuros snapshots planean ofrecer OpenGL y Vulkan en paralelo
- Será posible elegir el renderizador tanto en snapshots como en versiones estables
- También trabajarán en la estabilidad y en minimizar errores
- Piden reportar bugs a través de bugs.mojang.com
When is this happening?
- El objetivo es introducir Vulkan en las pruebas de snapshots durante el verano
- Durante el periodo de pruebas se podrá alternar entre OpenGL y Vulkan
- Cuando se complete la validación de estabilidad y rendimiento, planean eliminar la implementación de OpenGL
- Habrá un aviso previo antes de retirarla
- También actualizarán los requisitos mínimos del sistema
Vulkan and Vibrant Visuals
- La modernización del renderizador es un paso clave en la hoja de ruta de Vibrant Visuals
- El cambio a Vulkan amplía el margen para mejorar los gráficos y reforzar el rendimiento
- Se espera una reducción de errores relacionados con drivers
- Un objetivo central es asegurar que el juego siga funcionando en macOS
- Para garantizar que los jugadores de todos los sistemas operativos compatibles puedan participar por igual
Significado de la actualización
- Esta transición es un paso importante para que Minecraft Java avance hacia una pila gráfica moderna
- Refuerza la base técnica del motor del juego, dejando una estructura más favorable para futuras ampliaciones y nuevas funciones
- El paso de OpenGL a Vulkan también va en línea con el relevo generacional de APIs gráficas en toda la industria de los videojuegos
3 comentarios
Comentarios de Hacker News
Ojalá que con el tiempo baje la sobrecarga de CPU en el hilo principal
Los juegos que fueron porteados de DX11 a 12, o de OpenGL a Vulkan, no mejoraron solo por cambiar de API, sino porque aprovecharon la capacidad de procesar draw calls en paralelo
En Minecraft el cuello de botella aparece porque la CPU es más lenta que la velocidad a la que la GPU puede renderizar, así que espero que este cambio también deje más margen de CPU en el entorno de mods
Por curiosidad probé correr la versión de Windows en Proton y el rendimiento mejoró 30%
Supongo que fue gracias al multihilo de la librería dxvk que usa Proton
Me parece una buena decisión que Minecraft Java Edition sea solo de escritorio, porque así evita los problemas de drivers de Vulkan en móviles
Aun así, siendo Microsoft del tamaño que es, pensé que tendrían capacidad para hacer un RHI multiplataforma que usara APIs estables por plataforma (DX12, Metal)
Mantener tres versiones del renderizador de Java sería una carga pesada, y como el ecosistema de mods es clave, este cambio por sí solo ya va a generar bastante confusión
No creo que haga falta complicar todavía más el mantenimiento de los mods de shaders
Vulkan también puede correr en macOS, así que no veo muy bien por qué usar DX12 en un proyecto nuevo
En mi vieja Acer C720 Chromebook (Intel HD4400 iGPU), Vulkan no está soportado, así que parece que Minecraft se va a romper
Antes una de sus ventajas era que corría en casi cualquier hardware, así que da pena
Me pregunto por qué no movieron los comentarios al post original (hilo relacionado)
Es interesante que Microsoft se haya acercado más que Apple al estándar de Khronos
Adoptaron SPIR-V como formato de entrada y salida del compilador de shaders de DirectX, mejorando la interoperabilidad con Vulkan
Apple tenía muchas quejas sobre cómo se manejó OpenCL, y Sony y Nintendo casi no muestran interés en Khronos
En la práctica, las APIs de Khronos tampoco ofrecen portabilidad completa por el problema del espagueti de extensiones
VulkanMod mejora mucho el rendimiento, pero no es compatible con la mayoría de los mods
Si en el futuro Vulkan llega a poder usarse incluso en modpacks completos, sería realmente genial
Ojalá Vibrant Visuals llegue pronto también a Java Edition
Da pena que para usar shaders siempre haga falta un mod
Se instalan arrastrando y soltando un archivo .zip, sin loaders complejos ni riesgos de seguridad
Es menos flexible que Aperture, Iris u Optifine, pero funcionalmente se parece bastante
Me pregunto si también se podrán incluir shaders de Vulkan en resource packs. Aunque quizá lo limiten porque el riesgo de romper funciones del juego sería mayor
No sabía que Java tuviera bindings de Vulkan. Supongo que usan JNI
También me sorprende que todavía estuvieran usando OpenGL. No sé mucho del estado actual de Minecraft, pero también es la primera vez que me entero de que existe una versión de escritorio no-Java
El manejo de memoria es muchísimo más limpio y enlazarse con funciones externas (como Vulkan) se vuelve mucho más fácil
Me parece una de las funciones más subestimadas del Java reciente
Me pregunto por qué mantienen dos versiones del mismo juego
Bedrock ya casi alcanzó la paridad funcional, pero como reemplazo completo fue un fracaso
Bedrock tiene mejor rendimiento y portabilidad, pero en consolas el modding de todos modos no es posible
El 90% del contenido de YouTube está basado en Java, así que Microsoft está enfocada en lograr equivalencia de funciones
Desde la perspectiva de Microsoft, mantener ambas versiones para maximizar ingresos es una decisión racional
Ojalá hayan resuelto bien el problema de la latencia por compilación de shaders en Vulkan
Eso se debe a que no usa un sistema de materiales complejo, sino un renderizador de voxels bastante simple
El problema aparece cuando el motor genera demasiadas combinaciones de shaders, o cuando cierto estado de GPU (por ejemplo el blending) provoca recompilación del shader
En Vulkan moderno, la mayoría de esos estados pueden manejarse como dynamic state y así se mitiga el problema
Aun así, algunos estados como el blending todavía pueden causar recompilación
O sea, si los desarrolladores evitan esos estados dinámicos, la latencia se puede prevenir fácilmente
Últimamente muchas grandes empresas de videojuegos han descuidado la optimización técnica
Minecraft fue originalmente un juego desarrollado en Java, pero después de que se lo vendieron a MS lo volvieron a hacer una vez más en C++. No debe haber sido nada fácil reimplementar un juego completo cambiando el lenguaje de desarrollo, así que da curiosidad cómo fue que terminaron haciéndolo.
Parece que hicieron la edición Bedrock con el objetivo de optimizar para móviles...
Pensé que quizá iban a abandonar Java, pero al final parece que van a seguir actualizando ambas.