Engine Update

What’s new?

A lot has happened since I made the last post, especially in terms of engine architecture and features. It would be really difficult to highlight absolutely everything that has changed, but I will do my best to highlight the major aspects.

New name

I decided to name the engine “Pacha” after the Quechua word for the earth as a hint to my Peruvian heritage.

New Features

I added a project management interface to make it easier to work with multiple setups and make my life easier when testing features.

  • You can see the scene in the scene view!
  • Updated the look and feel of the UI
  • Added manipulators for objects in 3d space and a toolbar to manage them
  • Levels can be serialized to JSON to be able to save/load them
  • Texture and Model assets have information about them on the resource panel
  • Models can be drag and dropped into the scene view
  • Implemented a render pipeline/render pass architecture model to handle rendering
    • The editor uses the Editor Render Pipeline which runs the following passes:
      • Depth Prepass
      • Shadow Reduction and Rendering
      • Standard Render Pass
      • Gizmos Render Pass
      • Post-processing stack
      • Icons Pass (also writes the Icon Ids)
      • Selection Render Pass
      • Editor Highlights Pass
    • The Standard Render Pipeline, which the standalone game uses, is the same as the Editor one but without the editor specific passes
  • Selection highlights that can be either filled or outlines only to better know which object you are currently working with
  • Gizmos pass that render helpful visual aid like bounding boxes, camera frustums, light direction - cones and radius
  • Icons pass which draws icons and their ids into the scene for objects that have no physical representation such as cameras and lights
  • GPU based object picking by writing objects Ids and current state and asynchronously reading them back to CPU
    • The Ids are also used to generate the outlines based on the difference in editor state
  • Render passes can be manually synchronized using semaphores making it possible to add fibres so that passes can be generated in parallel (this is on the backlog)
  • Added both CPU and GPU timers to accurately time sections of the code
  • Added Multiview rendering support
  • Shadow cascades are rendered using Multiview rendering when available.
    • According to my tests, it yields better performance than four separate passes even with the excess in draw calls due to inaccurate culling
  • Terrain rendering using indirect drawing, tessellation and GPU culling
  • Added scripting support using daScript, a high performance interpreted language that can also be AOT compiled into c++
  • Added Compute shader support in both sync and async modes
  • Engine runs and has been tested in both Linux and Windows
    • Android, OSx and IOs (Using MoltenVK) should work but I haven’t got around to testing
  • Shaders can be recompiled at runtime for faster iteration
  • Automatic shader parameters reflection and material editor interface for editing said parameters
  • Editor specific resources are bundled inside the executable so that the distribution is a single .exe file that contains everything needed to run the editor

Running the game

You can preview changes and run the game directly from the editor in a separate executable by pressing the play button on the top right corner.

This works by spawning a second Editor process with special command-line arguments to make it run as a standalone game.

What I am currently working on

At the time of writing this post, I am currently working on optimizing the render pass generation, so far I have added a dynamic AABB tree for accelerating frustum culling and implemented hierarchical culling, added proper OBB culling for better accuracy on leaf nodes, added faster sorting and batch generation of draw commands and I’m currently working on reengineering the material system so that it both makes it faster to fetch necessary data and generate commands as well as reducing descriptor sets usage.

This will open the doors to a fenceless model for frame submission, something that I have wanted to get rid of for a long time but never got around to changing the material system to make it easier to handle descriptor sets in that specific scenario.

Share