floooh
commented
1 month ago Yeah would make sense. They're definitely not supported in WebGL2, but now that WebGPU is "around the corner" it's not such a big deal as a couple of years ago to have features that don't work on WebGL (they wouldn't be emulated, but simply not supported, e.g. there would need to be a feature flag in sg_features).
No promises on a timeline though :)
Just a proposal, but how hard would it be to add support for cubemap arrays as an image/sampler type?
I noticed if I write
textureCubeArrayin glsl, then sokol-shdc will compile it just fine to the correct equivalent in each backend, the only issue is that the Image Type is INVALID in the sokol glue code, and obviously there's no way yet to specify a cube array in sokol's current sg_image_desc.I only have first-hand experience with OpenGL and WebGPU, I've never touched DirectX or Metal else I'd try to add it myself in a PR. I'm not sure what it would take to add cube arrays to the existing texture loading/binding functions, or how much work it would be for each backend. I have done some cursory research on the different APIs, and I'm certain they all have roughly similar support for the feature - minus WebGL which would require a way to simply ignore the feature, or instead implement a workaround (such as using a texture array of size N*6 with a manual lookup function added to the shader).
On a pragmatic note, cubemap arrays are pretty much the only real way to implement shadow mapping for multiple point lights in a single pass. To say nothing of things like baked environment maps or light probes or other similar things that make use of several cubemaps at once, which would eat up all the bind slots otherwise.