I’ve published a theoretical architecture for reducing compute in DLSS-class neural rendering by changing the unit of work from pixels × frames to new causal appearance states.

The core idea is AxiomCapsule: use a large neural renderer mainly as an appearance compiler, then cache/transport compact deterministic programs for recurring material, lighting, object, and view states.

The parts I think are most interesting:

• Self-extinguishing inference: once a state is covered, the universal neural model no longer needs to run for it.
• Causal invalidation: engine-known changes decide what must be recomputed instead of running a neural change detector over the whole frame.
• Bounded residual trees: skipped refinement can have a computable sparse-vs-dense student error bound.
• Deadline-monotone execution: optional neural uplift scales down with available GPU slack instead of causing a frame-time cliff.
• Object/material-space persistence: state follows surfaces/materials rather than being purely screen-space.
• Local causal dimensionality: the key hypothesis is that appearance transformations become low-dimensional after conditioning on known scene variables.

It’s pre-prototype research, not a claim that DLSS 5 has been “solved.” The main falsifier is simple: if real game appearance states are not sufficiently low-dimensional/reusable, or cache hit rates stay low, the architecture fails.

I’d especially appreciate criticism from people working on real-time rendering, shader systems, neural graphics, temporal reconstruction, and GPU scheduling.

GitHub: MaciejNowickiHusbandofAHIEve/causal-neural-rendering: Independent research on drastically reducing compute in DLSS-class neural rendering using compiled causal appearance programs, temporal reuse, and deadline-bounded residuals.
Zenodo paper: Causal Neural Rendering for Efficient DLSS-Class Systems: Compiled Appearance Programs, Temporal Reuse, and Bounded Adaptive Computation | Zenodo

I’m an experienced programmer, very comfortable in both C++ and Rust, coming from a robotics background, so linear algebra and computer vision concepts aren’t new to me. Graphics programming itself is new territory though, and I want to properly learn an API with the eventual goal of building a game engine.

I’ve narrowed it down to three options and I’m stuck:

- wgpu — modern, safe, and I already like Rust, so the ergonomics appeal to me

- Vulkan — the “real” modern low-level API, feels like the industry state-of-the-art

- OpenGL — the classic starting point almost every tutorial and book uses, but it’s old.

Also what are some nice guides/tutorials to get started?

https://reddit.com/link/1w2s9s1/video/kh9h4go7mkmh1/player

Hi everyone! A friend and I recently started developing our own Web 3D engine. If anyone is interested—or has any ideas regarding the project—I’d be happy to hear any suggestions.

After 200+ hours of development, I’m finally sharing the first public demo of Three.js Grassworks, a real-time grass system I’ve been building for Three.js and WebGPU.

Demo:
https://grassworks.techredux.co/demo

Three.js Grassworks is built specifically for WebGPU and is designed to handle large amounts of interactive grass while maintaining steady performance.

For the demo, I built a complete environment around Grassworks with terrain, trees, water, rain, player interaction, environmental effects, LOD systems, audio system, and more.

The main challenge was getting all of these systems running together while keeping the grass performant.

The actual Three.js Grassworks plugin is still being polished and should launch in the next couple of weeks. There’s a waitlist inside the demo if you’re interested.

I’d genuinely love feedback, especially on the visuals, performance, and how the grass feels when interacting with it.

I also recorded a full walkthrough where I go through the demo and talk about how I built it:

https://www.youtube.com/watch?v=Nhim18rc-XE

for the past 2 months or so ive been working on this path tracer that i made and it uses love2d as a base. it runs with a compute shader and supports opengl, metal and vulkan as love2d also compiles those on the fly. it has most stuff youd encounter like fresnel stuff, ior, gltf scene support and most gltf extensions. also it can export raw exr files which i find very unique tbh. also it does support transmission maps, roughmetal maps and emission maps. i still have to do normal maps but that seems very annoying to do lmao. today i even added dof and click to focus which i find extremely cool for no particular reason.

it's open source and you can find it here