An assessment of slang

1. Core Pipeline Conflict (API Mismatch)

• jME3’s OpenGL Foundation: The core renderer of jME3 (LWJGL backend) and its mobile port (Android GLES) are deeply bound to the OpenGL/GLSL ecosystem.

• Slang’s Modern API Focus: As previously mentioned, Slang is designed primarily for modern graphics APIs such as Vulkan, DirectX 12, and Metal.

Point of Conflict: jME3 cannot directly load compiled SPIR-V shaders (unless you are using a community-driven, unofficial, and highly experimental Vulkan renderer for jME3). This means you must compile Slang into SPIR-V during the build phase, then use SPIRV-Cross to translate it back into legacy GLSL, which can finally be fed into jME3. This workflow is excessively cumbersome for the jME3 pipeline.

1. Incompatibility with the Material System (J3MD)

jME3 has its own mature and tightly-coupled material definition system (.j3md files):

• Built-in Macros & Global Variables: jME3’s GLSL code relies heavily on engine-injected global uniforms (e.g., g_WorldViewProjectionMatrix, g_Time, m_Diffuse) and pre-compile macros (#ifdef HAS_COLORMAP).

• Slang’s Lack of JME Context: Slang is a strongly-typed, standalone compiler that has no knowledge of jME3’s “magic” variables prefixed with g_ or m_. If you write shaders in Slang, you must manually declare these constant buffers or uniform structs within Slang. After translating back to GLSL, you must ensure their names and structures perfectly match jME3’s internal bindings. This process is extremely error-prone.

My current view is that we should not use Slang, as adopting it would significantly increase the engine’s complexity. Although the community may shift towards Vulkan in the future, considering compatibility and existing engine features, I recommend writing shaders using Vulkan GLSL (GLSL 4.50). (This raises another question: should we deprecate legacy APIs?) Currently, the Vulkan renderer I am developing is largely compatible with jME3’s content; only the shader code migration part remains. Once all existing OpenGL GLSL shaders are converted to Vulkan GLSL, they can be used. I am still searching for a feasible solution, so if anyone has better suggestions, please feel free to propose them here.