You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rendering functionality that should be compatible with all backends are:
3
3
4
-
Unlike jme3, where all uniform bindings were localized to a material, jme4 will allow anything to bind anything to any set/binding. Processes are expected to handle their own descriptor sets for this. This assumes that the relevant processes know exactly what protocol any given shader is following, so there are opportunities for uncoordination here. Luckily, there are a few things going in our favor:
5
-
6
-
1. Renderers are more or less expected to be handcrafted. If you want to use a shader with a different protocol, you must also design the infrastructure to properly interface with your shader.
7
-
2. If a shader doesn't use a particular binding that is supplied, it just doesn't use it. We don't have to check if the shader is actually using it. This is big for general global stuff that gets bound maybe once per frame.
8
-
9
-
For api, I'm planning on having a ShaderBinding interface, which specifies one or more bindings and exposes UniformBindings that parameters are submitted to. ShaderBinding objects will be created by the Engine, as vulkan and opengl engines will very likely use different implementations. The UniformBinding objects are a bit stickier though, as for vulkan they spawn the writers that interface directly with vulkan. For OpenGL, same thing but with OpenGL.
4
+
* Render viewport
5
+
* location: anywhere
6
+
* Technique implementation
7
+
* Specify render state
8
+
* shaders (technique)
9
+
* macro definitions (material, technique)
10
+
* shader binding sets (engine, technique)
11
+
* translation from set/binding to binding required for opengl
0 commit comments