{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigcf4xkbqyoynjvcujfnyiamhueowr7ukdpt5x2drvahbnme37eqe",
    "uri": "at://did:plc:dxjzgxe7cvirxkwfjr2tjspt/app.bsky.feed.post/3mmk2mn7vbxh2"
  },
  "path": "/t/jme-vulkan/49551#post_7",
  "publishedAt": "2026-05-23T16:27:01.000Z",
  "site": "https://hub.jmonkeyengine.org",
  "textContent": "Thanks for your reply!\nUnlike OpenGL, Vulkan requires you to define exactly what types are bound to specific pipeline slots on the backend. While OpenGL abstracts this away, this explicitness is necessary in Vulkan.\nLooking at other engines, the approaches vary widely due to compatibility concerns:\nUnity & UE​ use custom shader languages. They have their own mechanisms to map shader variables to pipeline slots (Unity relies on name matching via Shader Reflection, while UE uses static struct mapping with RDG and macros).\nGodot​ offers an interesting hybrid. It has RDShader(similar to Unity’s automation), but its RenderingDeviceAPI forces explicit binding layouts when using raw GLSL.\nGodot’s approach feels like a good fit for JME, though it would need some adaptation. Currently, jme3-coreallows us to choose between OpenGL and Vulkan at the frontend, but the underlying differences remain significant. My goal is to bridge these gaps so we don’t have to abandon OpenGL while still being able to leverage Vulkan (though that might be easier said than done, haha).\nMy current plan is to provide default pipelines for the standard JME materials (like VKUnshaded.j3mdand VKLighting.j3md). If users want to write custom shaders, they would need to define custom pipelines as well.\nOf course, I’m still learning, and I’m open to changing my mind if I find a better solution down the road!\n\n\n    \"Vulkan requires all resource binding layouts (Pipeline Layout / Descriptor Set Layout) to be defined upfront when creating the Pipeline, whereas OpenGL allows you to call glBindTextureor glUniformat any point before drawing.\"\n",
  "title": "jme-Vulkan"
}