GLSL Shader in StereoKit

[austinbhale]

Hey Nick! Looking to have a glsl-specific shader file render in StereoKit. This wouldn’t work like the cross-platform sk shader since we need an OES texture only for Android. So I’m thinking of two potential routes so I wanted to check with you on which one would be more ideal for integration:

1. Add a method ‘Shader.FromMemoryGLSL’ which inserts the appropriate metadata for rendering the glsl just like an sks would. Trying to load a glsl file in sk_gpu directly crashes during rendering since it seems it requires sks-specific metadata or similar?
2. Command line option for skshaderc to take in a glsl file and output sks

[maluoi]

1. FromMemoryGLSL is interesting, but raises a number of sticky questions/problems. Like, having to maintain a parallel shader include library written in GLSL. That may not be 100% critical, but skipping on this might mean this should be like a Backend.OpenGL.ShaderFromGLSL, or otherwise hidden in a corner. Also, getting the shader metadata right is kinda non-trivial, as you'd have to calculate the data layout via somewhat esoteric rules that even I can't get straight sometimes.
2. Command line for skshaderc might be better, this solves the shader metadata problem, but doesn't solve the include problem. skshaderc is also kinda tuned for HLSL's setup of one file for everything, where GLSL typically splits fragment and vertex shaders into separate files. This is a somewhat smaller problem, but you might have to rearrange a few things to make that work well.

A third option that I think might be a lot less invasive, if possible, would be to edit the generated GLSL based on metadata in the HLSL file. So right now, in HLSL files you'll find metadata like this for textures:

//--diffuse = white

This also contains a tagging system that allows you to slot in a bit of extra data. Right now I mostly use this to differentiate between an arbitrary float4 and a color float4. We could add the OES flag as a tag kinda like this:

//--diffuse : OES = white

And then when generating the final GLSL shader, use that meta tag to swap out what kind of sampler it uses. Spirv-cross does have some tools for letting you modify the GLSL it outputs, I'm just uncertain if this would be one of the edits it supports easily, or if you'd have to do some exciting string manipulation for this.

[nrewkowski]

What do you mean by "include problem"? If you're on a platform that uses GLSL like Android, then wouldn't this be similar to providing the "sk_gpu" code like skg_shader_stage_create the GLSL string? This already works fine for me, the only problem is that skg_shader_create_manual receives the file.meta and then stores it in the skshader, but then idk what it does with it. It clearly doesn't need to have accurate internal data representing the shader code, because I can get by by using a dummy .sks file to fill the metadata and then my custom code works. So the only problem is that metadata is being used somewhere in an unexpected way (as in the name is not the only thing used for some reason, even though the skg_shader_t already has different variables for the pixel, vertex, and compute shaders, so theoretically it shouldn't need the original code at all after the original compilation).

[maluoi]

The include problem is the fact that there is a "standard library" of HLSL shader code that while currently smallish, will grow larger over time. Supporting GLSL as a shader language in addition to HLSL will mean maintaining that standard library in two different languages simultaneously. This standard library provides important information like critical engine variables, instance data, common lighting algorithms, etc.

The metadata tells StereoKit about the data structures, textures and parameters used in the shader, what their names are, where they're located in the buffer, what size/format they are, and what their default values are. If the shader metadata isn't present properly, then you'll likely have major issues when attempting to set material parameters. Probably some other issues with the rendering pipeline as well, but off the top of my head I'm not sure what specifically. If the shader is simple enough, going without metadata might work on account of not having much in the way of buffers/parameter to fill out, but it almost certainly won't scale to more complex shaders well.