3 ms·
Everything in Bevy is organized as a plugin. Bevy's asset crate (bevy_asset) for instance exports the AssetPlugin, itself comprised of more sub-plugins. Bevy's
by jms55 3y ago
Everything in Bevy is organized as a plugin. Bevy's asset crate (bevy_asset) for instance exports the AssetPlugin, itself comprised of more sub-plugins. Bevy's rendering infrastructure is split into the following crates/plugins, each building on the layer below it:
- bevy_pbr: Bevy's standard physically-based renderer. Provides PBR shaders, user-extensible materials, as well as APIs for organizing draw calls and rendering.
- bevy_core_pipeline: Defines some standard rendering setups like "2d" and "3d - Opaque, transparent, etc", with the goal that you could plug your own wgpu-based renderer into this layer. Also currently holds all of our post-processing effects (TAA, tonemapping, bloom, etc).
- bevy_render: One part wrapper/helpers around wgpu, one part generic renderer utilities like a render node graph and 3D camera types.
There's also some extra crates I didn't cover like bevy_sprite for 2D, bevy_ui for UI, etc.
If you want to build a wgpu-based renderer, you have a couple of options depending on what kind of rendering you need. You can plug in your own custom renderer instead of bevy_pbr using bevy_core_pipeline. You can still use bevy_pbr and just add your own render nodes on top of it. Or, you can ditch wgpu/bevy_render completely and build everything from scratch (at the cost of losing UI/2D support).
Anything you do would take the form of a custom plugin. Bevy is extremely modular - plugins are how we organize and develop the engine itself, so removing certain rendering plugins and adding your own is easy.
EDIT: I encourage you to join Bevy's discord channel and discuss your project in the #rendering channel, it's much easier to provide help and give info than over a forum.
- adastra22 3y agoThank you! I just started with bevy this week, and it's a bit overwhelming, but in a weird and mostly good way. The way components and systems work is fucking magic, the kind of stuff you'd expect of Rails or Django, but not in a real-time framework in a systems programming language. The good is that whole applications can be written in just a handful of mostly declarative code, which is absolutely amazing! The bad is that with all the magic being handled by macros and back-end event processing loops, it can be a little intimidating and not obvious how it is constructed under the hood. I would love to see a class diagram showing both the extant objects and their types, and the control flow during a frame update. But anyway, thank you for all your hard work and for the response. Now I know where to go first in the source code to do what I need to do. > If you want to build a wgpu-based renderer, you have a couple of options depending on what kind of rendering you need. You can plug in your own custom renderer instead of bevy_pbr using bevy_core_pipeline. You can still use bevy_pbr and just add your own render nodes on top of it. I actually have my own wgpu-based renderer done (https://github.com/atomCAD/atomCAD/ https://github.com/atomCAD/atomCAD/), so maybe that's the first thing to try. Thanks! > I encourage you to join Bevy's discord channel and discuss your project in the #rendering channel, it's much easier to provide help and give info than over a forum. Will do.