SuikaSibyl / SIByLEngine2023

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SIByLEngine 2023.1

SIByLEngine is a personal toy game engine by @SuikaSibyl. I am planning to keep working on it for a long time and implement lots of realtime & offline effects in it.

Previous version could be find in: SibylEngine2021. Version 2023 is a complete refactoring including better and more extendable structure, solution, design.

EditorDemoImg

Builds

Only support Windows platform and MSVC compiler for now.

Either directly open SIByLEngine.sln with VisualStudio 2022 on Windows, or use any CMake tools to open the CMake project (Visual Studio open Folder / vscode / CLion etc.).

By default, Nvidia GPU with Turing or higher architecture is required to correctly run the engine, as vulkan hardware raytracing is defaultly used. In the future, better compatibility with CPU raytracing fallback might be supported. If no corresponding GPU exists, compilation should still be successful, but you should manually turn off ray-tracing-related features to run it without fatal error.

Design Decisions

  • NOT Use C++ 20 Module for the all the modules. Although I had previously used it extensively and found it to be a great feature. Despite MSVC's support for the feature, compilation is not always stable, sometimes resulting in weird 'internal error' messages that force the process to be abandoned. Moreover, as the project grows, both IntelliSense and ReSharper struggle to provide proper code highlighting and intelligent code completions, which makes coding extremely painful. Also, analysising the project eat up all the memory quickly and get the IDE and compiler super slow... Given these challenges, I have opted to deprecate the feature.

  • Only Support Vulkan Backend for RHI module. It seems that there are some API logistic differences between Vulkan / OpenGL / DirectX. But the main reason is probably simply because I am too lazy to implement and test for all the backends for now. As Vulkan is supporting most of the features exists, I find no good reason to support other backends at this stage.

  • Use Render Graph to manage GPU pipeline. The main motivation is that Vulkan is too verbose about memory barriers. Render graph helps me to support automatic barrier insertion (within the graph) and resource management. It may also be a good idea to do automatic barrier insertion at a lower layer like RHI, which may be helpful to support a more flexible pipeline, but I am not sure with that for now.

Modules

  • Core Modules

    • SE.Core.Log: Log print system from scratch.
    • SE.Core.Memory: Memory management system from scratch (experimental).
    • SE.Core.ECS: ECS system from scratch (experimental).
    • SE.Core.Resource: Resource management system from scratch (experimental).
    • SE.Math: Basic math computation library from scratch with SIMD acceleration.
  • Rendering Modules

    • SE.RHI Module: Abstract layer with WebGPU-style API supporting Vulkan backend.
    • SE.Tracer: CPU ray tracing implementation based on PBRT v3 (GPU implementation see SE.SRenderer)
    • SE.Image: Image loader/storer for various format.
    • SE.Video: Video loader/storer for various format, decoding via ffmpeg.
    • SE.GFX: Higher-Level infrastructure on top pf SE.RHI
      • Defining scene, with many basic components and resources.
      • Providing serializing & deserializing via yaml-cpp.
    • SE.RDG: Render Dependency Graph System (experimental).
      • Pass: rhi-pipeline-level (rasterize/fullscreen/compute/raytrace) atomic node in graph, with automatic pipeline and resource binding layouts creation via spirv-cross reflection of SPIR-V shaders.
      • Graph: a directed acyclic graph of Passes, automatic resource management and barrier insertion.
      • Pipeline: a interface enabling cross-frame switching between multiple Graphs.
    • SE.SRenderer: Retained mode renderer based on SE.RDG
      • Retained mode rendering infrastructure for both rasterization and ray tracing
      • Providing lots of RDG Pass/Graph/Pipeline algorithm implementation.
  • Physics

    • // TODO.
  • Editor

    • Editor_Core module: ImGui-Vulkan interoperate and extensible GUI framework.
    • Editor_GFX module: Provides many editor widgets for SIByL Engine.
    • Editor_RDG module: Provides DebugDraw system via RDG and RDG Viewer (no RDG editor yet).

Demo Gallery

 
Interactive GPU implementation of BDPT (left) [code] and MMLT (right) [code]

 
Axis-Aligned Filtering for soft shadow (left) [code] and and global illumination [code]
(aliasing is caused by gif compression)


2D FLIP Fluid Simulation [code]

 
3D tetrahedral elastic body simlation [code]


Vulkan tiny-MLP writen by Differentiable Slang with glsl WMMA


Calling Vulkan functionality in PyTorch in [SE2024] ! A simple differentiable rendering demo is shown.

Selected Feature List

Dependencies

References

I learned a lot from various renderers to build up this engine, here are some great references for those who might be interested.

  • PBRT: Rendering bible.
  • Lajolla Renderer: Well-written offline renderer, learned so much from it.
  • Hazel Engine: Fancy usage of ImGui editor and good tutorial on engine development.
  • Falcor: Easy to use, I especially imitate its RDG interface.
  • Unreal Engine: Needless to say.
  • Unity: The most commonly used engine for me, I am deeply influenced in many ways.

About

License:MIT License


Languages

Language:C++ 72.3%Language:HLSL 13.4%Language:C 8.3%Language:GLSL 5.6%Language:CMake 0.4%