PoC renderer by sp0lsh · Pull Request #14 · Pillware/Pill-Engine

sp0lsh · 2025-10-14T08:29:39Z

Benchmarked with 60k dynamic pills (30k -> 60k since previous benchmark), 30 FPS @ 1920x1200 on Mac M1.

Reference: HypeHype Mobile Rendering Architecture, Aaltonen23

PS: Please mind that it's my first time with Rust

…location, 15ms -> 0.4ms, 5k capsules

MattSzymonski · 2025-11-30T17:37:44Z

@@ -0,0 +1,7 @@
+pub struct RendererBufferTag;


Is core module a good place for such tags? Can't they be somewhere in rendering-related file in engine?

I think no, because XYZTag is for common ResourceManager implementation. I'd keep it in Core until the engine matures with a couple more demos.

Separate engine ResourceManager and RendererResourceManagers cause many headaches, duplication and additional complexities at this stage.

MattSzymonski · 2025-11-30T17:53:18Z

+
+// --- Borrow-only render query bundle and alias ---
+
+use crate::ecs::{CameraComponent, ComponentStorage, EntityHandle, TransformComponent};


Should be moved to the top of this file

MattSzymonski · 2025-11-30T17:58:08Z

@@ -158,10 +159,21 @@ impl TransformComponent {
    }

    fn get_rotation_matrix(&self) -> Matrix3<f32> {


MattSzymonski · 2025-11-30T17:58:19Z

-
 }

 pub fn update_transform_matrices(transform_component: &mut TransformComponent) {


another nice one

MattSzymonski · 2025-11-30T18:01:16Z

-}
+
+    // Peek system timer without taking ownership (cloned snapshot)
+    pub fn peek_system_timer(


Maybe name it clone_system_timer?
I'm not used to "peek", but it may be only my thing

Yeah, seconding that - if we clone we clone 😁

MattSzymonski · 2025-11-30T19:55:49Z

+                        key: render_queue_key,
+                        entity_index: entity_handle.data().index as u32,
+                    };
+                    engine.render_queue.push(render_queue_item);


what about sorting the queue again after this batch update?

Sort is done in PassScene (opaques) where context of selected camera view is present.

So sort depends on the pass logic, imagine OpaquePass (front to back) vs TransparentPass (back to front) sampling queue from the same world state

MattSzymonski · 2025-11-30T20:00:22Z

-        &mut timer
-    ) {
+    // Build WorldView with raw pointers to avoid borrow conflicts
+    let world_view = {


using pointers in rust is an antipattern.
You should use splitting borrow pattern (disjoined borrows)
Always prefer passing the ownership

As I've already discovered :P

Pls help C/C++ dev, that wants code fast pixels, with these Rust Shenanigans

Yeah, basically arm yourself with a gun:
https://doc.rust-lang.org/nomicon/borrow-splitting.html

MattSzymonski · 2025-11-30T20:02:18Z

-}
+}
+
+fn init_default_resources(engine: &mut Engine) -> Result<(), Error> {


should be in renderer.rs like all bootstraping logic IMO

MattSzymonski · 2025-11-30T20:29:28Z

@@ -1,25 +1,47 @@
 #![cfg_attr(debug_assertions, allow(dead_code, unused_imports))]


General thoughts about proposed shader passess architecture.

Right now all materials are dynamic. Shader resources read external shader files, figure out what uniforms and samplers they need, and then create pipeline objects (descriptors) with the appropriate fields.
Users still have to define shader parameters manually, but we can add proper reflection so this becomes fully automatic.
With this setup, we don’t need to hardcode render passes as Rust structs with fixed fields. I initially explored that approach but ended up going with generic dynamic objects instead.

Additional points / concerns:

I really don’t like the idea of having shader code embedded directly in the engine.
It breaks normal workflows (syntax highlighting, tooling, error messages, file diffs, etc.), and it forces engine rebuilds every time you tweak a shader.

IMO we should stick to HLSL, because that’s the market standard. Anything else immediately scares people off (including myself! (while developing this engine I would like to learn shader development as well, but not in <1% market share shader language)). Same situation as wanting to use Rhai (which is great) but picking Lua because that’s what devs expect, unfortunately.

A hybrid setup with Rust-GPU + HLSL is too messy and confusing. Two shader languages doubles the mental overhead.

Not even sure if Rust-GPU supports hot reload in a practical way. Tooling around it is still pretty limited.

External shader files give us all the benefits: hot reload, version control diffs, modding support, cleaner debugging.

Most graphics programmers already know HLSL. Keeping things familiar makes onboarding way easier.

Also we may end up with an explosion for render pass code files that will duplicate a lot of the same logic (setting up the descriptors, etc)
It looks like this is already happening.

I really don’t like the idea of having shader code embedded directly in the engine.
It breaks normal workflows (syntax highlighting, tooling, error messages, file diffs, etc.), and it forces engine rebuilds every time you tweak a shader.

I don't like it too, moreover, It's not put into a proper place yet, and it can be put into files etc.

IMO we should stick to HLSL, because that’s the market standard. Anything else immediately scares people off (including myself! (while developing this engine I would like to learn shader development as well, but not in <1% market share shader language)). Same situation as wanting to use Rhai (which is great) but picking Lua because that’s what devs expect, unfortunately.

Huh? I don't even know how currently used shader language is called, I just went with the existing flow. I've spent more time with GLSL and I've never heard of HLSL being any standard apart from DirectX APIs (which AAA engines may like due to M$ support on XBox).

I do not care as long as the shader compilation pipeline (SPIRV) is simple for targeted platforms (x64, arm, web)

Also we may end up with an explosion for render pass code files that will duplicate a lot of the same logic (setting up the descriptors, etc)
It looks like this is already happening.

Duplication at this stage is intended. I copy-pasted with a cold blood to see what code will be the same when exploring the performant modern rendering code. This way it is easier to change before prematurely optimizing the code with complexities. To be cleaned up and deduplicated when reaching the scope of the demo. Until the feature scope is reached, I do not have enough observation to cleanup.

If this is a living PR, then even better - we can discuss, iterate and conclude with much better code. I cannot add more because I am not a rendering expert. My aim would be to keep it optimized/quite simple (not intimidating with complexity) - something Aaltonen managed to achieve in his presentation.

MattSzymonski · 2025-11-30T20:38:44Z

+#[derive(Copy, Clone)]
+// HOT(ish): per-material UBO bound during draws; keep compact (<= 64B ideal).
+// Layout is 3x vec3+pads → 48 bytes total, 16-byte aligned to match WGSL/std140 rules.
+pub struct RendererMaterialParamsStd140 {


I know that structs with shader parameters are more elegant...
I was researching this topic and ultimately went with accessing material parameters via their names as strings.
This is the approach that both Unity and Unreal use. It is the most flexible one allowing to have generic material objects instead of hardcoded ones.
This way we can have PBR material, cartoon material and skybox material declared as the same material/shader type, all automatic/dynamic. No separate mental-overhead (engine-hardcoded!) structs required.
Current approach to this is not a random one, it is intentional and long considered.

PoC system is based on IdTech6 and HypeHype. The core pass PBR that is most minimal and performant.

Unreal explodes with shader combinations which I dislike as an architecture choice and Unity well... they tried.

But hey, we have encapsulated Passes, so 80% of shaders can benefit from core, fast pipeline. For remaining others 20% we can provide the custom path with string lookups and other thing but do not quote us on performance numbers there.

I like that in Unity I can create an experiment shader and drop on an object - this will be custom pass.
Unreal has PBR materials on nodes that I hate, however PoC PassScene can be extended with similar PBR material interface, however when you know what you are doing, IdTech6 did UberShader for easier low-level shader execution tuning.

If you really want to draw 100% meshes customized, feel free to copy-paste our performant baseline Pass and modify as you like.

JDuchniewicz · 2025-12-01T06:18:05Z

@@ -0,0 +1,16 @@
+[build]
+# Enable SIMD optimizations for math operations
+# This will auto-vectorize cgmath operations when possible


Please rebase on glam - we probably get auto-vectorization from the get-go

JDuchniewicz · 2025-12-01T06:18:35Z

+rustflags = ["-C", "target-cpu=native"]
+
+# Alternative: More conservative SIMD flags
+# rustflags = ["-C", "target-feature=+avx2,+fma"]


sometimes we might want avx512 etc

JDuchniewicz · 2025-12-01T11:26:59Z

 use std::fmt::Formatter;
-use core::fmt::Debug;
 use std::iter::Enumerate;
-use std::num::{ NonZeroU32};


Please rebase after #16, #17, #18 are merged - they remove these obsolete fields anyway

JDuchniewicz · 2025-12-01T11:28:50Z

+        self.counters.insert(label.into(), value);
+    }
+
+    // pub fn increment_counter(&mut self, label: impl Into<String>, delta: u64) {


Let's not commit commented out code

JDuchniewicz · 2025-12-01T11:30:59Z

 use cgmath::{Deg, Matrix3, SquareMatrix, Zero};
-use anyhow::{ Result, Context, Error };
-use serde::{ Serialize, Deserialize };
+use glam::{Mat3, Mat4, Quat, Vec3};


Please use pill_core names for types since we already merged #15

JDuchniewicz · 2025-12-01T11:32:17Z

+
+    // Normal matrix: rotation only
+    let n = Mat3::from_quat(q);
+    transform_component.normal_matrix = n.to_cols_array_2d();


I think we already talked about that - please also check if what I replaced in #15 is faster or if this is, just merge the faster alternatives 😄

JDuchniewicz · 2025-12-01T11:36:11Z

@@ -0,0 +1,241 @@
+# Pill Renderer vNext (wgpu) – Minimal MVP, API-Correct


Can we move all documentation related entities to docs - even better - annotate the code with documentation?

JDuchniewicz · 2025-12-02T11:11:55Z

@@ -0,0 +1,10 @@
+Building game project from /Users/mk/dev/demo/Pill-Demo...


do we need the log file staged?

JDuchniewicz · 2025-12-02T11:14:41Z

 crates/pill_standalone/Cargo.toml
 examples/*/Cargo.toml
+
+engine/Cargo.toml


I know why you are doing that, though this is probably not the best solution 😓

The launcher will constantly update the paths in engine/Cargo and show this file as changed. Honestly did not find a good solution for that except calling git add engine/pill_* when staging files.

JDuchniewicz · 2025-12-10T09:20:28Z

+                env_tex_rt,
+                prefilter_handle,
+                ibl_brdf_rt,
+                5,


in general we have a lot of magic constants - I know it is very math-oriented and settings-oriented code, but we still should strive to have as many documented variables as possible. Even better - having one simple place to tweak them (even later we could allow for tweaking at runtime if some of them are changing the visual output of the system).

JDuchniewicz · 2025-12-10T09:21:06Z

+                5,
+            );
+            {
+                let self_ptr: *mut dyn crate::graphics::PillRenderer = &mut *engine.renderer;


I would put the imports at the top of the file and call relative imports instead of absolute ones.

JDuchniewicz · 2025-12-10T10:34:55Z

+pub struct MaterialDesc<'a> {
+    pub label: &'a str,
+    // Factors
+    pub albedo: [f32; 3],


Maybe use SIMD types?

Materials will not be involved in much CPU compute. Most often set value, copy to WGPU buffer and upload to GPU (mem bandwidth). On GPU shaders do heavy ALU operations.

So if anything can be squeezed then the material precision -> size of GPU buffer / cache line fit in the loop over many materials.

JDuchniewicz · 2025-12-10T10:35:49Z

+    fn resize(&mut self, new_window_size: winit::dpi::PhysicalSize<u32>);

-    fn destroy_texture(&mut self, renderer_texture_handle: RendererTextureHandle) -> Result<()>;
+    // Creates a 256B-aligned uniform buffer (COPY_DST) and returns its handle


cache-line size?

Yes, the intent is to be able to create small buffers fitting the cache, suitable for the hot path. Another that on Mac, Metal failed to allocate buffers smaller than 256B, hence the padding alignment for the time being. To be checked on other platforms.

JDuchniewicz · 2025-12-10T10:36:50Z


+// WorldView raw-pointer based view to avoid borrow conflicts at call site
+pub struct WorldView {
+    pub active_camera: crate::ecs::EntityHandle,


same as above, can we use Rust's no-pointer approach here?

sp0lsh added 25 commits October 13, 2025 18:00

fix: mac renderer start

fc6fc48

fix: launcher, create new project

3c6d256

fix: template res names

64bcc21

feat: renderer design

e4832ac

docs

8ee28c4

m1: black window

8164662

feat: m3, render bunch of pills

455f7ca

feat: M3, refactor culling

73553f1

feat: M3, group draw calls by meterial and mesh

212bee5

feat: M4 bring back the material

5bbbc97

feat: M4 update time measure

c0b57bc

fix: build warning

f943910

feat: inlining pipeline

ffbf786

feat: M4 prebuilt PSO

2d159e5

feat: timers

9cb7de5

feat: marix update 15ms -> 0.5ms with SIMD

c36fd74

feat: M5 per frame ring buffer to avoid dynamic uniforms per frame al…

fb6de9e

…location, 15ms -> 0.4ms, 5k capsules

feat: mac retina preferred window setup

c5a1dfc

feat: stop log spam

8f29d33

feat: egui, show resolution

2a3ca06

feat: demo project

344b94e

feat: remove double sorting queue

0252abb

feat: comments vs rendering talk

b40a988

feat: instance batching +5-10 fps

813a29b

feat: add counters

3cca425

sp0lsh changed the title ~~Feat/poc render~~ PoC renderer Oct 14, 2025

sp0lsh added 4 commits October 14, 2025 19:22

feat: ignore due to file change each build

0241ce5

feat: M6 render to offscreen RT and compose to framebuffer

959e969

feat: M6 HDR, tonnemap

eec95f3

feat: M6 overlay quad pass

01832a7

sp0lsh added 5 commits November 15, 2025 05:00

consolidated renderer in engine with wgpu rhi

40bb2f3

fix path

4a5e8b8

cleanup resource manager

be47968

cleanup resource manager

51a6a77

feat: PassEgui

2dd2e91

sp0lsh force-pushed the feat/poc-render branch from 8720f7b to 2dd2e91 Compare November 16, 2025 02:51

sp0lsh added 3 commits November 16, 2025 16:53

cleanup warnings

8c54158

feat: ibl, TODO: cleanup

594c6a3

feat: linear depth

c1d7636

sp0lsh force-pushed the feat/poc-render branch from 04b6f32 to c1d7636 Compare November 17, 2025 20:23

MattSzymonski reviewed Nov 30, 2025

View reviewed changes

JDuchniewicz reviewed Dec 1, 2025

View reviewed changes

JDuchniewicz reviewed Dec 2, 2025

View reviewed changes

JDuchniewicz reviewed Dec 10, 2025

View reviewed changes

sp0lsh added 2 commits December 14, 2025 01:03

feat: depth of field pass, fixed depth projection

b2aa66f

feat: velocity buffer + per object motion blur

4500973

sp0lsh force-pushed the feat/poc-render branch from cbb389c to 4500973 Compare December 14, 2025 02:57

feat: lastest demo

b324f33

sp0lsh force-pushed the feat/poc-render branch from c5da079 to b324f33 Compare December 14, 2025 03:49


		// --- Borrow-only render query bundle and alias ---

		use crate::ecs::{CameraComponent, ComponentStorage, EntityHandle, TransformComponent};

		@@ -158,10 +159,21 @@ impl TransformComponent {
		}

		fn get_rotation_matrix(&self) -> Matrix3<f32> {


		}

		pub fn update_transform_matrices(transform_component: &mut TransformComponent) {

		@@ -1,25 +1,47 @@
		#![cfg_attr(debug_assertions, allow(dead_code, unused_imports))]

		@@ -0,0 +1,241 @@
		# Pill Renderer vNext (wgpu) – Minimal MVP, API-Correct

		@@ -0,0 +1,10 @@
		Building game project from /Users/mk/dev/demo/Pill-Demo...

Uh oh!

Conversation

sp0lsh commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sp0lsh Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sp0lsh Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sp0lsh Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sp0lsh Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sp0lsh Nov 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JDuchniewicz Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

sp0lsh commented Oct 14, 2025 •

edited

Loading

sp0lsh Nov 30, 2025 •

edited

Loading

sp0lsh Nov 30, 2025 •

edited

Loading

sp0lsh Nov 30, 2025 •

edited

Loading

sp0lsh Nov 30, 2025 •

edited

Loading

sp0lsh Nov 30, 2025 •

edited

Loading

JDuchniewicz Dec 1, 2025 •

edited

Loading

sp0lsh Dec 10, 2025 •

edited

Loading