Very good deep-dive, but I'm surprised there was little mention of the higher-level libraries that do exist already. I've found kiss3d and three-rs, both of which seem pretty early but appear to let you "load a model you made in Blender and show it on screen".
A Guide to Rust Graphics Libraries as of 2019
21–27 of 27 posts
Re: A Guide to Rust Graphics Libraries as of 2019
#22Earlier quoted context omitted.
So from what I can find, it seems gfx-hal works with GLSL, compiles it to SPIRV, and then uses that (somehow). I'm just not sure how it uses the SPIRV for each backend.
The first link I included has a wonderful diagram of this (but from the perspective of HLSL instead of GLSL), the gist of it is: GLSL gets compiled to SPIR-V ahead of time by a compiler of your choice (probably glslangValidator). You can take that binary blob and feed it into Vulkan (vkCreateShaderModule) or OpenGL (glShaderBinary as long as you have the right extension). For everything else, Khronos has a tool calle…
Re: A Guide to Rust Graphics Libraries as of 2019
#23Earlier quoted context omitted.
Thanks so much for explaining how that works :) Is it just me or does decompiling the binary SPIR-V to ESL/HLSL source code then recompiling sound like a recipe for massive inefficiency? Or in practice does it work out pretty nicely?
Yes, it's absolutely inefficient but for those platforms it's the only way to execute your own code on the GPU. Metal has a bitcode format that I know nothing about and I believe older DirectX had some intermediate format that was binary. Both are proprietary and only documented via reverse-engineering, so they're not great targets. Most of the extra cost of feeding in SPIR-V could also be offset if you generate the…
This isn't a big concern at the moment though, since most of the shader loading/compiling time is spent by the driver receiving the result, not us translating it.
Generating a text shader at packaging time is certainly an option to explore, especially for self-contained users like WebRender. The trouble here is that we adjust the shader code based on the pipeline and pipeline layout, so we can only really start translation at the run/init time, unless we start pre-packaging a set of "popular" configurations (which is feasible for WebRender).
Re: A Guide to Rust Graphics Libraries as of 2019
#24Very good deep-dive, but I'm surprised there was little mention of the higher-level libraries that do exist already. I've found kiss3d and three-rs, both of which seem pretty early but appear to let you "load a model you made in Blender and show it on screen".
Kiss3d is great. It has some rendering issues on mac, but a great level of abstraction.
Re: A Guide to Rust Graphics Libraries as of 2019
#25Not trying to be rude, but I'd just like to point out the apostrophe on API's indicates ownership, as in "John's dog jumped". APIs is fine, as in "John has two dogs".
Re: A Guide to Rust Graphics Libraries as of 2019
#26Earlier quoted context omitted.
Kiss3d is great. It has some rendering issues on mac, but a great level of abstraction.
Is it featured/mature enough for a full game?