Rendy has been out for a while, supporting our use of Vulkan. However, after trying to write a custom render pass for my game, I’ve become a bit skeptical of it.
My points are:
Rendy uses gfx-rs, which has multiple backends. I know that portability is important, but this has a few problems:
- No Vulkan-specific libraries. Things like VMA are unavailable.
- Heavy generics. I have not checked how it affects compile time, but generics have been a major cause of slowness in rustc due to the monomorphization scheme.
- Portability is not free. While the goal is to run on a variety of platforms, Amethyst hasn’t really performed well on anything other than Vulkan. gfx-rs’s additional complexity doesn’t worth it at the moment (although there’s a big room of improvement).
Viral suggested that a particular problem with gfx-rs is that backend behaviour is beyond what the types represent. Depending on the backend, unsupported operations might get emulated (slow path), panic, or even UB. An alternative is to properly provide feature detection, and allow the user decide to fallback or panic in those cases.
Rendy does more than a wrapper. Rendy calls itself “State of the art ‘build your own engine’ kit”, and this actually have two parts: ideas from Vulkan wrappers and concept from other game engines. Considering that docs are insufficient as described below, these additional concepts really creates confusion.
Rendy’s design of graphs requires a lot of boilerplate. Compared to other wrappers, the graph boilerplate is so large that the overall example size becomes larger. You can check vulkano’s example for reference.
At this point, it seems that Rendy needs to be separated clearly of these two: concepts from Vulkan, and concept originated and useful for engines. The former is required because gfx-rs is low level, and doesn’t provide facilities like destructor.
- Lack of documentation. Rendy’s documentation is very minimal, and we probably need detailed guides in additional to the reference. Another thing we need is API design documents.
Seemingly poor maintainability. It’s rare but one of the files is over 3000 lines. I had a hard time examining this.
Some part of the code doesn’t seem to be well coded. The
chaincrate have been very hard to understand. Good news is, this greatest offender is going to be removed as a part of the upcoming graph refactor.
- Unsatisfied promises. The rendy README shows that Declarative pipelines is one of the goals, but it remains unimplemented. In the Amethyst use case we have so-called “submodules” for code separation, but they are not to the extent of being pluggable (can’t be integrated by end user). Writing render passes for Amethyst has a lot of frictions, so modularity is of great importance IMO.
And well, given that we have invested a lot of effort, I’ll try to avoid saying that we should just rewrite things. However, it might make sense to have some sort of diversity in design. I’m currently inclined to try out Vulkano to see how far can it go; especially because it has nothing in common with gfx-rs, and therefore has many interesting design choices.