aclysma / rafx

Multi-backend renderer with asset pipeline. The objective of this repo is to build a scalable, flexible, data driven renderer.
Apache License 2.0
641 stars 32 forks source link

Make distill optional in the higher level crates, abstract asset handling. #233

Closed gzp79 closed 2 years ago

gzp79 commented 2 years ago

I was planning to use rafx for it's higher level abstraction layer and frame graph capabilities, but it seems as all of these higher layers are distill dependent (assets, renderer, plugin) My issue is that my asset pipeline is very different and incompatible to distill: I have a server that handles all the dependency and packing and the client should request packages from the server. For now I see no way to add this functionality to distill and it seems I'd need to fork the rafx-asset, rafx-plugin, rafx-renderer to rework the asset loading/storing/handling part. If there were a way to make distill optional and provide some AssetManagement traits (with alias type) such that other asset handler/storage could be used/integrate, rafx would not enforce any 3rd part asset framework and would have a much smaller "crate-print" (smaller number of external dependencies). This crate could focus on the rendering part if there were a way to abstract away the asset handling (handler, storage, loader). Distill could be a default option even after this (or even better moved into an rafx-distill crate)

(Another use case would be to help integrating rafx into other engines like in Bevy where they have their own asset loader/manager but rafx could remain a valid and good alternative for rendering)

aclysma commented 2 years ago

It sounds like rafx-framework is the level where you want to be, and it includes the frame graph. rafx-assets, other higher level crates, the shader pipeline, and the blender plugins are designed specifically to provide a complete, opinionated workflow with distill and I don’t see that changing.