Forward Rendering Pipeline

[sholloway]

Create a robust rendering pipeline for v0.2.0 of the engine.

Characteristics

• Renders the landscape.
• Renders multiple agents.
• Can optionally render vertex normals.
• Frustum Culling
• Ambient Lightning (Objects are just visible)
• Point and Directed Lighting (Objects are lit by lights).

Rendering Architecture

Renderer Style: Forward Rendering

Render Graphs/Frame Graphs

• Original Render Graph GDC Talk
• Render Graph 101
• Why Talking About Render Graphs
• GFX Frame Graph Resources
• Render graphs and Vulkan — a deep dive
• AMD Render Graph SDK
• GDC Talk about AMD's Render Graph SDK

Task Graphs

• Task Graph Pattern
• Task Graph Renderer at Activision

Resource Allocation & Management

• Ring Allocator
• Linear Allocator

Bindless Rendering

• WebGPU Investigation
• WebGPU Bindless Tracking Issue
• Bindless rendering

Considerations

• Leverage GPU render bundles and draw instance calls.
• Javascript Example
• WebGPU Render Bundle best practices
• Z coordinates in WebGPU
• Depth Precision Visualized

Other Resources

• Frame Breakdown of GTA V

[sholloway]

GPU Lines

https://arxiv.org/pdf/2405.00127

https://linebender.org/gpu-stroke-expansion-paper/

[sholloway]

Consider ways of simplifying the complexity of working with buffers and uniforms.

The Frame Graph/Render Graph pattern seems like it might be a good fit for what I want to do.

A thought is have "nodes" that are declared in a similar fashion to data classes but generate the boilerplate of working with buffers an uniforms.

For example, something the like below.

def uniform(cls):
    class Uniform(cls):
        custom_attr = 42
    return Uniform

@uniform
class MyRenderNode:
    pass

The idea being that the class decorator will dynamically add boilerplate attributes and methods to classes.
See Real Python's article on Metaclasses for other techniques.

[sholloway]

On eventually scaling the engine to enable parallel processing on tasks.

Current Challenge

A Task in Python is a coroutine. Coroutines cannot be pickled and shared across processes. This is currently a blocker for migrating the existing Task based implementation to work across multiple worker processes.

Key Question

Could tasks be defined through the combination of data and function pointers?
The idea that data that is changing can be serialized and passed between various worker systems in a thread safe way.
Either a function pointer or some other way (magical thinking) of referencing the code to run could be passed around.

Exploration

The Task Graph pattern worked well for the simple 2D version of the engine. Things that might help this pattern apply to the 3D engine:

• Adjacency Matrix view of tasks when the sim is paused or running.
• Being able to slow down the engine at run time to watch tasks being executed.
• Graphically visualizing the Task Graph at the various stages of the life cycle.
• Graphically mapping tasks at design time.
• Having different type of Tasks predefined.
  (e.g. LoadResource, Compute, AsyncTask, SyncTask, RenderStep, RenderPass, RenderToTarget)
• Have a centralized place to define the task graph for a sim vs the extension mechanism that the 2D engine used. Perhaps a graph focused DSL?