DEV Community: Fumiya Funatsu

Bevy Engine, as a Small Unity, Big Processing (P5)

Fumiya Funatsu — Tue, 23 Jan 2024 00:26:09 +0000

(This article is self-translation from my original post in Japanese. I'm sorry if not translated well.)

Introduction: Creative Coding and Processing

There are many game engines out there, what are you using now?

I like so-called creative coding, and I use, for example, Unity, UE5, Touch Designer, Notch, React, etc., to make what I have in mind. I always choose a tool that seems to be just right for prototyping each time.

When I wonder what the origin of creative coding is for me, I think it must be Processing (also called P5²).

When I look back on why I love Processing, it was just "simple", as ease of use. Even today, that philosophy continues in the form of p5.js and openFrameworks. For example, p5.js has an online editor in your browser ³.

From that time on, Processing required only one editor and nothing else, and we just enjoyed pure simplicity of writing code.

Large-scale game engines and the in-between ravine

By the way, creative coding is a formless concept, and I consider the so-called visual editors in Blender, Unreal Engine, etc. as the same creative coding.

(Figure: Blender's geometry node ⁴)

(Figure: Material Editor in Unreal Engine 5 ⁵)

In fact, I myself make full use of such things to give shape to my ideas, and as the word of "no code" suggests, I feel "code" has become just "a concept" nowadays.

Web browsers are also one type of engine, and "engines", not limited to game engines, are the backbone that supports our production and have become indispensable.

However, sometimes I feel a desire to go back to the roots of something lightweight and easy to use like Processing, or I want something that combines modern concepts (such as reactive programming in React) and ease of use, in other words, something in between Unity and Processing, which I can get my hands on immediately, without having to wait for dozens of GB of editors to download ⁶.

Bevy Engine, as a in-between Unity and Processing

While I was thinking about above, I came across the Bevy Engine.

⁷

Bevy Engine is open source and has not been developed for many years, although, there are already many volunteer plug-ins, just like add-ons to openFrameworks.

Similar to Processing and openFrameworks, the core is written small, with such plugin systems being added as you need.

And most importantly, you basically don't need any tools other than Rust (cargo). First, create an empty project with $ cargo new bevy-hello ⁸, move to the project folder with $ cd bevy-hello, add bevy as a library with $ cargo add bevy, and then just paste any code in src/main.rs (e.g. the following) and run $ cargo run to get it working.



// hello world example of src/main.rs

use bevy::prelude::*;

fn main() {
    App::new()
        //.add_plugins(DefaultPlugins) // uncomment this to show the window
        .add_systems(Startup, hello_world)
        .run();
}

fn hello_world() {
    println!("hello world");
}

It takes a while to start (build, compile) the first time, but after the second time it reloads surprisingly fast and can hot-reload assets if you need.

Short look at ECS (Entity Component System)

(Figure: ECS's mock-up diagram ⁹)

First, "System".

Now that we have written what is called "Hello World," let's take a look at some other code.



// (first part omitted)

fn main() {
    App::new()
        .add_plugins(DefaultPlugins) // this is a magic spell
        .add_systems(Startup, setup)
        .add_systems(Update, (system, rotate_camera, update_config))
        .run();
}

This is the beginning of the code taken from a sample called 3D Gizmos, where add_systems(Startup, ...) and add_systems(Update, ...) registers functions, in terms of Processing , setup (a function called only once) and draw (a function called every time when updating).

Let's take a look at one of the functions actually registered.



fn system(mut gizmos: Gizmos, time: Res<Time>) {
    gizmos.cuboid(
        Transform::from_translation(Vec3::Y * 0.5).with_scale(Vec3::splat(1.)),
        Color::BLACK,
    );
    gizmos.rect(
        Vec3::new(time.elapsed_seconds().cos() * 2.5, 1., 0.),
        Quat::from_rotation_y(PI / 2.),
        Vec2::splat(2.),
        Color::GREEN,
    );

    // (last part omitted)
}

Here's the amazing part: if you specify a type for the arguments that points to what you want, and it will automatically bind that value. It's a trick that could be called DI (Dependency Injection), how cool :)

Startup basically does registering elements, like HTML or JSX in React. The elements are updated by functions registered in Update, which is equivalent to JavaScript in HTML.

We call this group of functions "System", and basically everything that does any work is written in "System" ¹⁰.

The difference from draw in Processing is that the drawing itself is basically done automatically ¹¹. So, instead of draw, it's called update, and in update, basically only parameters such as values and components are changed, not the drawing itself. This is similar to React and others.

All are Entity, all attributes are Component, all data are Resource

And this is where it is similar to Unity (strictly speaking Unity DOTS): all elements are derived from something called Entity. Everything is Entity (same as Game Object in Unity), so it is easy to handle in a unified way, and furthermore, all attributes are derived from Component, and since Components exist under the same concept in Unity, it is easy to understand how to read them.

In addition, all data that you want to keep, which are so-called variables, become Resource, and assets such as images and 3D data are Asset. This is also simple and easy to understand.

And how to get them from the System is the same as before: declare a type as an argument and it will fetch them for you ¹². It's magic.



fn check_zero_health(
    // Access Entity with `Health` and `Transform` Component.
    // Get `Health` as read-only, get `Transform` as mutable.
    // Optional: get the `Player` Component if it exists
    mut query: Query<(&Health, &mut Transform, Option<&Player>)>,
) {
    // Get all matching Entities
    for (health, mut transform, player) in query.iter_mut() {
        eprintln!("Entity at {} has {} HP.", transform.translation, health.hp);

        // If HP is 0, move to center
        if health.hp <= 0.0 {
            transform.translation = Vec3::ZERO;
        }

        if let Some(player) = player {
            // here Entity is `Player`.
        }
    }
}

// code cited from (includes comments, but I translated into English from Japanese):
// https://xianliang2032.hatenablog.com/entry/2021/09/28/Rust_Bevy_Query%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

I would like to keep just as introduction to this architecture, which is called ECS (Entity Component System), but you can see that it has the same general-purpose mechanisms as Unity and others.

(Figure: Unity and Bevy terminology correspondence chart)

Other features: Cross-platform, low-level drawing engine abstraction, etc. (skips today)

¹³

There are many other interesting features of the Bevy Engine, such as the wgpu mechanism, which allows automatic cross-platform support for DirectX, Metal, Vulkan, WebGL, etc. with a single code, but skips description today, because it would be commonplace in Unity and other platforms nowadays.

Last one: Plug-in system for more and more extensions / e.g. Inspector, Gizmo, Particles ...etc...

Finally, I would like to mention a few things about plug-ins. For example, if you get greedy, you may wish to have an "editor" like Unity. Plug-ins can do it.

¹⁴

For example, if you want a GPU particle system, you can use bevy_hanabi, with display a more casual inspector, bevy-inspector-egui can be used to.

The list of plug-ins is endless, but at last if you felt "want to write a UI in HTML!", a plugin called belly will do it for you.

This kind of casual extension is fun part of any engine, and thanks to the ECS architecture, I'm happy to be able to use it in parallel and well-ordered with other Entity, Component, and other structures without any discomfort.

p.s. Bevy Plug-in list is here: https://bevyengine.org/assets/#assets, and here https://github.com/topics/bevy-plugin

Summary: Merging "past" and "future" of Creative Coding will be...?

Now, I have introduced the Bevy Engine as a "just fit" product in between, for those of you who are tired of Unity, Unreal Engine (and other game engines), and who are wondering what to do next to Processing in your programming classes.

By the way, if you actually try to write a game with the Bevy Engine, you will be surprised at how hard it is to understand the errors that Rust produces... (LOL 😂) ¹⁵

...Half joking but... it's largely a matter of getting used to it, but Bevy Engine is designed so that you don't have to be so conscious of ownership and lifetime (which are difficult parts of Rust) thanks to the component system called ECS. And probably in the future, something like the Bevy Engine will be available from general languages such as TypeScript, and I feel that this may be the future of creative coding.

Bevy has only been around for a short period of time, so there is no handy sketch sharing platform online like p5.js, or ~~there is no~~ web-site or list of add-ons (p.s. Bevy plug-ins list
already existed in official!), but already Example can be viewed interactively with WebGL, and I think such a future is just around the corner.

I hope that little by little, from a place like this, the best of each of the "past" and "future" of creative coding can be merged well together.

Additional information

You can use shadplay as the same kind of tool like ShaderToy for wgsl shader language, it's useful if you want to try only effects without worrying about ECS, or debugging purposes ¹⁶.

quoted and reconstructed from https://bevyengine.org/examples/2D%20Rendering/bloom-2d/. ↩
Originally, Processing had used the domain proce55ing.net, it became origin of P5. see https://en.wikipedia.org/wiki/Processing#History. ↩
As a side note, cultures such as Tweet Processing is also interesting related to one-liners. ↩
Image cited from https://forest.watch.impress.co.jp/docs/serial/blenderwthing/1373040.html (Japanese article). ↩
Image cited from https://docs.unrealengine.com/5.0/en-US/organizing-a-material-graph-in-unreal-engine/. ↩
Just to follow up on the capacity thing, capacity and specs are relative, and I think the impression of what simplicity is will always change. In fact, Processing at the time was about 300 MB, which was not small in capacity. So, in the context of this article, I'll assume here that simplicity means keeping the core simple by using plugin systems, abstractions, etc. (Unity, for example, is already simple enough, I think). ↩
quoted and reconstructed from https://bevyengine.org/examples/3D%20Rendering/3d-gizmos/. ↩
Commands beginning with $ refer to what you type into the terminal. (Omit the $ and type what follows.) ↩
Figure cited from https://blog.mozvr.com/introducing-ecsy/. ↩
"System" also allows you to specify dependencies and create combinations (called sets), but this is redundant and will not be discussed here. ↩
Note that this does not mean that you cannot customize your drawing, as there is a good balance provided between high-level APIs such as ECS, low-level APIs for the drawing engine itself (wgpu), and mid-level APIs that fall in between. Using mid-level APIs or low-level APIs, assured that the shader pipeline and various buffer objects can be manipulated. ↩
Code cited from (includes comments, but I translated into English from Japanese) https://xianliang2032.hatenablog.com/entry/2021/09/28/Rust_Bevy_Query%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6. ↩
Table cited from https://bevy-cheatbook.github.io/gpu/intro.html. ↩
Image cited from https://zenn.dev/eloy/articles/ea11899ee3dbe4 (Japanese article). ↩
I omitted it in the article, but when you actually write the code, if you put rust-analyzer in VSCode, the completion will work perfectly, so you are now ready. Have a happy coding! ↩
Information was received from the official Bevy Discord community. I really appreciate all the support from the community. ↩

Comparison of C++ Low-Level Graphics, Cross-Platform Frameworks and Libraries

Fumiya Funatsu — Tue, 04 Feb 2020 14:18:06 +0000

(This article is self-translation from my original post in Japanese. I'm sorry if not translated well.)

I usually write codes of graphical, cross-platform apps with OpenGL, but recently thought how I can create apps supporting Metal, DirectX, or Vulkan with Low-Level Graphics APIs.

So I researched frameworks and libraries which is:

Implemented in C++ ( C++98 or 11,14,17 etc. )
Supports low-level graphics APIs ( Vulkan, DirectX11/12, Metal etc. )
Cross platform ( Win/Mac/Linux, iOS/Android etc. )
Lightweight or embeddable / extensible compared to Unity and Unreal Engine 4

Note: I just focused on low-level Graphics APIs. So please check other articles if you need comparison of game engines. There are many game engines implemented with frameworks in this article.

	Pros ✅	Cons ❌
LLGL	Supports many APIs	Need knowledge of each platform
The Forge	Supports many platforms	Need knowledge of each platform
Diligent Engine	Same code for platforms	No Metal support
bgfx	Same code for platforms / Easy	No tessellation shader support¹
oryol / sokol_gfx	For embedded and Web	No computing shader
Methane Kit	Win / Mac compatibility	No mobiles support
bs::framework	For game engine development	Only stable in Windows

LLGL (Low Level Graphics Library)

https://github.com/LukasBanana/LLGL

License: BSD-3 clause
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	✅	✅	-
Mac	-	✅	-	✅	-
Linux	-	-	✅	✅	-
Android	-	-	❌	-	✅
iOS	-	✅	-	-	❌

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	✅	✅	✅	✅

( Different shaders needed for each platform such as glsl/hlsl/metal/spv. No automatic cross-compilation. )

Summary:

Few dependencies and easy build using cmake. Supporting DirectX / Metal / Vulkan / OpenGL (ES), and every types of shaders. I think this is the most comprehensive and high performance framework, with compact implementation.

This framework wraps low-level APIs, but you have to configure every parameter for different platform, and sometimes different codes using macros are needed. So the highest performance on each platform can be achieved, but you need advanced knowledge of Metal, DirectX and Vulkan, and also GPU.

Additionally, different shaders are needed for each platform. In this case, cross-compiling your shader code by yourself makes it easier, using spirv-cross or shaderc and so on. This can be bothered, but separated shaders are good point when higher performance and detailed configuration is needed.

The Forge

https://github.com/ConfettiFX/The-Forge

License: Apache-2.0
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	✅	❌	-
Mac	-	✅	-	❌	-
Linux	-	-	✅	❌	-
Android	-	-	✅	-	❌
iOS	-	✅	-	-	❌

( Also supports XBOX, PS4, Switch, Stadia. )

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	✅	✅	✅	✅

( Need different shaders for each platforms such as glsl/hlsl/metal/spv. No automatic cross-compilation. )

Summary:

This is very high-quality framework created for implementing renderers of custom (or your own) game engine. However, OpenGL (ES) is not supported. So you can't use this for older smartphones or PCs.

This framework seems to be stable and well maintenanced. CI and unit tests are used in many cases and already used in many products.

The usability is just like LLGL. Advanced knowledge of each platform is needed, but you can configure as you like if high performance is needed.

Diligent Engine

https://github.com/DiligentGraphics/DiligentEngine

License: Apache-2.0
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	✅	✅	-
Mac	-	❌	✅ (MoltenVK)	✅	-
Linux	-	-	✅	✅	-
Android	-	-	❌	-	✅
iOS	-	❌	✅ (MoltenVK)	-	✅

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	✅ (`*2`)	✅	✅	✅

( *1 Shaders are automatically cross-compiled from HLSL )
( *2 Can not use compute shader in Mac OpenGL, because Mac only supports OpenGL 4.1 or lower )

Summary:

Few dependencies and easy build using cmake ². This framework's name has "Engine" but this is lightweight and portable framework.

Noteworthy, the same source code (without macros) and shaders are applied for every platform. In most cases, rewriting your code is not needed.

However, disappointedly, Metal is not supported so that compute shader cannot be used on Mac OpenGL (because Mac's OpenGL version is lower than 4.3.) Except for that, there is very efficiently implemented modern API, when compared to bgfx (similar framework, describes later),

bgfx

https://github.com/bkaradzic/bgfx

License: BSD-2 clause
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	✅	✅	-
Mac	-	✅	❓	✅	-
Linux	-	-	✅	✅	-
Android	-	-	❓	-	✅
iOS	-	✅	❓	-	✅

( Supports WebGL with Emscripten or asm.js. Also supports Raspberry Pi )

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	✅	❌	❌ (`*2`)	❌ (`*2`)

( *1 Automatically cross-compiled from original shader language like GLSL )
( *2 For DirectX and OpenGL, there is an unofficial fork which enables hull/domain shader, but not maintenanced for a long time... )

Summary:

Released and being developed since 2015, there are many products using this framework, and many examples and forums' Q&As can be found. Building this framework is also easy with cmake, and an original build manager called GENie makes it easier.

Just like Diligent Engine, the same source code is used for multiple platforms without macros (in most cases). APIs are very simple and easy to understand and very extensible with libraries you want.

However, only one regrettable point is that tessellation shaders are not supported, but computer shader enables it (see the official examples.) And this can be done in Mac and iOS because Metal is supported, this is very strong point when compared to Diligent Engine.

About shaders, an original shader language like GLSL will be automatically cross-compiled for all platforms. But it is a little unique, variable definition of input and output as a header file for them.

At last, please note that some functionalities are limited for platform compatibility, such as
not complete command buffers, tessellation shader (described above). The compatibility seems to be treated as the most important point in this framework's development policy. I feel this is the good point, but can be a burden of the performance. Moreover, some APIs is not so modern and not so efficient when compared to Diligent Engine. But this may be improved because recently often updated.

oryol / sokol_gfx

https://github.com/floooh/oryol
https://github.com/floooh/sokol

License: MIT (oryol), zlib (sokol)
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	❌	✅	-
Mac	-	✅	❌	✅	-
Linux	-	-	❌	✅	-
Android	-	-	❌	-	✅
iOS	-	✅	❌	-	✅

( WebGL is supported, and you can run on Raspberry Pi with OpenGL ES. )

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	❌	❌	❌	❌

( For sokol_gfx, you should prepare shaders for each platform. )
( For oryol, GLSL-like language is auto cross-compiled. )

Summary:

oryol and sokol_gfx are created by the same author. sokol_gfx is a header-only single file library for C language, and oryol is a lightweight C++ framework. It is designed as Orthodox C++, so you can probably use it with C++11 with older compilers.

These two are very compact file-size libraries, having sufficient functionalities. This feature will work well with WebGL, the total file size will be very small when compiling with asm.js/wasm.

The only feature I miss, is that compute shader is not supported. But the author says that it may be implemented as another library as an addon (for sokol_gfx). This is very good news if true.

Methane Kit

https://github.com/egorodet/MethaneKit

License: Apache-2.0
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	❌	❌	-
Mac	-	✅	❌	❌	-
Linux	-	-	✅ (`*1`)	❌	-
Android	-	-	❌	-	❌
iOS	-	❌	❌	-	❌

( *1 Linux/Vulkan version is currently in development )

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	❌	❌	❌	❌

( HLSL 5.1 is used for auto cross-compiling. )

Summary:

This framework is based on C++17, and much focused on **Desktop. Windows/Mac compatibility is treated the most important in this framework. You just need the same source code and shaders for Windows/Mac. Recently, Linux/Vulkan version is announced and now in development.

This is very young framework which is published on GitHub a year ago, and now very actively updated recently.

bs::framework

https://github.com/GameFoundry/bsf

License: MIT
Supported Platforms:

	DirectX	Metal	Vulkan	OpenGL	OpenGL ES
Windows	✅	-	✅	✅	-
Mac	-	❌	❌ (`*1`)	✅ (`*2`)	-
Linux	-	-	✅	✅	-
Android	-	-	❌	-	❌
iOS	-	❌	❌ (`*1`)	-	❌

( *1 Implementation via MoltenVK is under discussion, at the time of writing. )
( *2 Not working properly on Mac at the time of writing. )

Supported Shader Types:

Vertex	Fragment	Compute	Geometry	Hull (TC)	Domain (TE)
✅	✅	✅ (`*2`)	✅	✅	✅

( *1 HLSL subset language is auto cross-compiled. )
( *2 compute shader is disabled on Mac, because Metal/Vulkan is not supported and OpenGL 4.3 or above is required but not on Mac. )

Summary:

This is an integrated framework which provides functionalities for/as game engine, created by the author of Banshee 3D Engine. This is still in beta version and very young, the first version was released only a year before.

Based on C++14, and provides the functionalities like Unity / UE4, scene component system, physics, file loading functions, animations, sound players, low-level graphics APIs. Well documented and well-structured.

However, not working properly on Mac at the time of this writing, and mobiles are not supported, and more, Metal is not supported ³.

Other frameworks

Acid (https://github.com/EQMG/Acid) ....... Game engine with Vulkan / MoltenVK.
magnum (https://github.com/mosra/magnum) ....... Game framework with OpenGL / WebGL. Considered to be implemented in Vulkan.
Wicked Engine (https://github.com/turanszkij/WickedEngine) ....... Game engine with DirectX, only for Windows.
Rizz (https://github.com/septag/rizz) ....... Tiny C framework using sokol_gfx. glslcc is used for cross-compiling, and can use compute shader on DirectX as experimental.

Note: In this article I focused on low-level graphics APIs, so I intentionally wrote nothing about OpenGL-related frameworks, such as openFrameworks or Cinder. However, there are Vulkan implementations (openFrameworks-vk, Cinder-Vulkan). But it is experimental and not seems maintenanced well...

If you want to know about OpenGL related creative frameworks, I recommend awesome-creative-coding.

Similar Frameworks ( Implemented in Other Languages )

gfx-rs (https://github.com/gfx-rs/gfx) ....... Implemented in Rust language. This is the most complete framework in this theme. Maybe you can use it with C API from C++?
veldrid (https://github.com/mellinoe/veldrid) ....... .NET Implementation.
Kha (https://github.com/Kode/Kha) ....... Haxe Implementation. Many platforms and APIs are supported. It seems easy to use this. Probably you can use this framework if cross-compiled to C++.

Conclusion

It became too long article than I expected... Thank you for reading. Any comments are welcome :)

I made simple comparison table:

	Pros ✅	Cons ❌
LLGL	Supports many APIs	Need knowledge of each platform
The Forge	Supports many platforms	Need knowledge of each platform
Diligent Engine	Same code for platforms	No Metal support
bgfx	Same code for platforms / Easy	No tessellation shader support¹
oryol / sokol_gfx	For embedded and Web	No computing shader
Methane Kit	Win / Mac compatibility	No mobiles support
bs::framework	For game engine development	Only stable in Windows

I maybe use bgfx if I need one in my production, because of its easiness and compatibility.

LLGL and The Forge are strong options for high performance. These two can be use for your own original game engine development. However, in some case, it have to be compared with Unity, or Unreal Engine 4.

References

awesome-vulkan (https://github.com/vinjn/awesome-vulkan#Libraries)

Tessellation with compute shader is supported. ↩
In this time, Windows script is not prepared. So you have to read scripts for Mac/Linux, and mimic it and you need type some commands. ↩
For building, Hello World can be built soon, but Examples needs many additional files before building by script, and every time fails downloading. You may need many modifications of your cmake file. And some case not working properly on mac, I could not work it well on my laptop, with pre-built binary and original build from master branch. ↩