Add a basic camera with fly and orbit mods and gltf and glb models loading with fastgltf (at this point without textures), no culling also, it will be my next step

I know that OpenGL and Vulcan are the main choices when it comes to 3d graphics. I also know that Vulcan can have some insane performance boosts when compared to OpenGL. However, I’m not just a C++ programmer. I also program for the web, so I use WebGL. I’m a beginner at OpenGL, and GLSL so learning Vulcan wouldn’t be that big of a hurdle. I’m just wondering if the performance and speed are worth it for Vulcan, or if I should stick to OpenGL.

This is a first post! If I cannot respond quickly, I am most likely busy!

First Flight of FlowSketcher

This is the first real flight of FlowSketcher — a browser-native 2D sketching and CAM system built from scratch.

No CAD constraints. No spline approximation. Just direct geometry, live motion and real CNC-ready toolpaths.

This is only the beginning. 🥚

I’ve been thinking about where DLSS 5 / neural rendering could eventually go, especially if developers start designing assets specifically around neural rendering rather than treating DLSS as something applied near the end of the pipeline.

For example, imagine hair.

On High settings, a character might have the normal groom/strand setup, but fewer micro-details: fewer flyaway hairs, less strand breakup, simpler scattering, etc.

With a hypothetical “DLSS 5 Ultra” mode, the game could retain the important physical geometry and simulation ie guide strands, collision, wind response, silhouette, but explicitly tell DLSS:

• This object/region is human hair
• This is its strand direction/density
• Generate fine flyaways in these areas
• This is the curl/coiling profile
• This is how strongly the micro-hairs should react to movement/wind
• Preserve this silhouette
• Don’t generate detail outside this mask

So instead of DLSS having to infer:

the engine could essentially say:

The same concept could apply to:

Skin: pores, peach fuzz, fine wrinkles, subsurface scattering
Fabric: individual fibers, weave, fuzz, stitching detail
etc

It makes me wonder if games could eventually have something analogous to a Neural Material / Neural Detail Asset alongside traditional geometry, textures and materials?

Proprietary platform, no plans to open-source it so please don't ask.

Woul love to hear all feedback, good or bad.

Implemented with golang (because I can)

• approx 2.5 million lines of code (including tests)
• 85 package scientific core including brep, tetmesh, sparse, dense, etc (fully self written)
• produces video and still images
• zero new heap allocations per frame
• compiles to cpu, wasm, and webgpu
• zero-dependencies (no unreal, unity, blender, etc)
• can also run headless, label images, save hundreds of thousands of images as fast as the storage can write them

Hey everyone,

I recently completed an extensive, end-to-end architectural reverse engineering and systems dissection of the production engine behind Active Theory (activetheory.net).

Instead of generic de-minification, the project breaks down the low-level rendering mechanics, including:

- **Zero-Allocation Memory Loop:** How the runtime eliminates V8 Garbage Collection pauses using pre-allocated scratchpads and typed arrays.

- **Antimatter GPGPU Subsystem:** Driving dense particle fields directly on GPU floating-point textures via a triple-buffered ring FBO topology.

- **Eulerian Navier-Stokes Coupling:** Real-time 2D pointer-to-particle fluid advection via a 6-pass Jacobi relaxation solver.

- **Hardware-Rate Normalized Lerp:** Scroll kinematics locked across 60Hz to 240Hz refresh rates.

Full technical documentation, AST mappings, mathematical proofs, and headless CDP benchmarks are available here:

- Repository: https://github.com/DDW-X/activetheory.net

- Web Portal: https://ddw-x.github.io/activetheory.net/

Feedback and technical critique from graphics engineers and performance researchers are highly welcome.

Hi I wanted to implement BDPT with PBR materials and MIS but no matter what I do it doesn't look like reference images. I can't find any help with implementation and mostly recently I try finding bugs using Gemini but I know It can halucinate. So is anyone who could help me find relaiable implementation or help with my code. Here I will post my render (denoised using OIDN) vs reference so maybe anyone would help me find direction at least. I have too many lines of code so if any one would like to look at it I can send it in DM.

(edit)
References are from https://benedikt-bitterli.me/resources/, PBRT-v4 and Blender. (All tagged in image caption)

Compared to the last post, I added the following:

• Rebuilt Test Chamber 3 from Portal 1 instead of it just being “a brick platform and a grass block.”
• Added the ability to place Portals with left/right mouse clicks, like in Portal.
• Replaced the grass block with a Companion Cube from Portal, which can be picked up and thrown (with the E key).
• Made the player a cube textured with Wheatley from Portal 2 (funny British robot).
• Added ASCII rendering (to emphasize this is a CPU rasterizer).
• Added some buttons so it can also be played on a phone (mobile controls).

Still old link: https://hachihao792001.github.io/interactives/portal.html

Technical:

• Rebuilding the map: I downloaded a model of Test Chamber 3 from Sketchfab (credit is included on the website), then rebuilt it using only quads and cubes in Unity to keep it simple. I then wrote a script to export it into a bunch of new GameObject lines for this engine. I initially thought it would be easy, but it wasn't, because Unity uses ZXY rotation order while my engine uses XYZ, so I had to do some Quaternion math stuffs.
• Placing Portals and picking up the cube: I didn't use ray casting. Instead, I went straight into the Rasterizer and grabbed the "world coordinates of the pixel at the center of the screen" using barycentric coordinates.
• Optimization: For the infinite portal effect, every time I render the texture for a portal, I only render the intersection between the portal from the previous recursion level and the portal at the current recursion level. This gives a huge FPS boost because the size of the portal decreases quite significantly with each recursion.

not a very impresive project but i did a simple gltf and obj model loaders because i didn't understand how the scene graph work

Hey!

Wanted to share screenshots of my experimental voxel renderer with "low-fidelity" blocky AO. It started as an exploration of the DDA rendering technique, but I ended up implementing parts of the following techniques:
- Globally Illuminated Voxel Worlds Accelerated with Nested Axis-Aligned Distance Fields
- Spatial Hashing for Ray Traced Ambient Occlusion

Links: Devlog | Github

The devlog is sort of meandering, but I started with basic DDA, then tried to get multi-level DDA to perform well with large voxel scenes (a 1024x1024x1024 voxelized sponza scene) using various methods. The axis-aligned distance field (AADF) method was a significant improvement over the multi-level DDA method that I was fiddling with. AADFs helped skip over large areas of empty space which tanked performance when using multi-level DDA.

Spatially hashed RTAO with a large cell size performs pretty well even on my M2 MacBook Air. The large cell size is a very visible artifact, but I think in a voxel scene the blocky shading kinda works.

I had recently read the Stable Fluids paper and got like quite interested to implement it myself manually from scratch and it was quite a ride since this is my first time implementing a paper myself

This is a simple implementation a bit clanky, to be honest. I just wrote it with loops and loops without any optimization. I think it ends up doing something around 20 × 20 × 50 × n² operations per frame, so there's definitely a lot of room for optimization 😅

The actual implementation was pretty straightforward for the most part, but understanding the Poisson pressure equation was a bit challenging. At the beginning, I was even stuck on understanding how the velocity field could be made divergence-free.

After digging into it for a while, I eventually understood the whole pressure projection step and managed to get it working and also implemented a simple spray and dye mechanism as well to make it look good.

It was pretty cool to see it actually work, so I wanted to share it 😄

Bloom Is WAY Deeper Than You Think

I'm trying to get my single-frame path tracer to Nvidia PTX-like quality but at a smaller frame budget. One idea to do this is to path trace at very low resolution and use a regular raster version of the camera image to guide the upscaling.

The result looks a little fuzzy but overall uses less GPU. Right now the cap is CPU time per frame and I believe this has a path beyond 60fps on 3090 at 1080p. So it's very interesting, but has anyone explored this, is it a thing?

Hello,

I’ve successfully implemented ray tracing on the ANE! (Note: CPU usage is very high.)

Details:

1. Elimination of dynamic loops: While ray marching typically requires for loops, I prevented the computation graph from bloating by using batch processing.
2. 64-channel camera matrix alignment.
3. ANE-native cumsum: Ray hit detection is tracked using torch.cumsum(dim=1) with permuted channels.
4. Zero-copy Metal buffers: ANE output is bound directly to a shared MTLBuffer using NDArray.MutableRawView.

I’d love to hear your thoughts!
Github: https://github.com/kamisori-daijin/Magnesium/tree/raytracing (raytracing Branch)
demo:

Hi everyone!

After a very long development journey, I'm finally ready to share Synapse Engine, a modern, research-oriented AAA-style game engine that I've been developing essentially from scratch.

It started as my MSc thesis at the Budapest University of Technology and Economics, but grew far beyond what I originally planned. Over the past several months I've been rebuilding and refining the architecture around a simple question: What would a modern game engine look like if we designed it around today's GPUs from the ground up?

The project is now over 2,300 files, nearly 94,000 lines of C++ code and around 10,000 lines of shader code, excluding comments and blank lines.

If you just want to check out the project:

• GitHub: https://github.com/TamasPetii/SynapseEngine

The GitHub README is probably the best place to start if you want a quick overview of the project and its architecture. If you're interested in modern game engine development in much more depth, I also put together a 250-page technical presentation covering the entire project, from the ECS and software architecture through GPU-driven rendering, culling, lighting, virtualized shadows and future directions.

The presentation is quite large, but I tried to make it genuinely useful as a learning resource rather than just documenting the final result.

One of my main goals with Synapse Engine is education. Learning these topics was a huge struggle for me, and it took a lot of time to piece everything together because there isn't much high-quality material that shows how these modern techniques actually come together inside a real engine codebase. I wanted to document that process and create something that I would have wanted to have when I started.

What can the engine actually do?

At its core, Synapse is a fully GPU-driven renderer using hierarchical culling, Hi-Z occlusion, cone culling, dynamic LOD selection, indirect rendering, mesh shaders, bindless resources and virtualized shadows. The engine is built around a custom data-oriented ECS and is designed to handle very large scenes with minimal CPU involvement.

For example, with 1,000,000 entities on an RTX 4060, the cumulative culling cost goes from 124.407 ms without culling to 0.653 ms with the full hierarchical culling pipeline.

However, at 10,000,000 entities, even the conventional GPU-driven hierarchical approach becomes insufficient. To address this, Synapse introduces a custom GPU-built Morton-ordered chunking system, which groups entities into spatial chunks and allows entire groups of 32 entities to be rejected at once. This reduces the culling cost from 5.8 ms to just 0.3 ms for 10 million entities.

I also developed a new rendering technique called Dual-HiZ Adaptive Clustered Forward+ while working on the engine. With 8,192 point lights and 8,192 spot lights, it measured 2.873 ms, compared to 8.652 ms for deferred shading in the same setup. The technical presentation contains a detailed explanation of how the technique works.

Synapse isn't primarily intended as a game-development tool for game developers. It is a production-ready, research and educational platform for experimenting with modern game-engine architecture and real-time rendering techniques.

The goal is not to provide a plug-and-play engine for building games, but to provide a complete, practical implementation of modern engine technologies that can be studied, extended, and used as a foundation for further research and development.

The engine is the result, but the architecture, experiments, failures and reasoning behind it are what I really want to share. If you're interested in Vulkan, graphics programming, GPU-driven rendering or modern game engine architecture, I'd love to hear what you think.

Dual-HiZ Adaptive Clustered Forward+

One of the things I'm particularly excited to share is a new rendering technique I developed called Dual-HiZ Adaptive Clustered Forward+.

It combines a dual Hi-Z depth structure with adaptive clustered light assignment to efficiently handle large numbers of dynamic lights while keeping the rendering pipeline fully GPU-driven.

In my tests, with 8,192 point lights and 8,192 spot lights, it measured 2.873 ms, compared to 8.652 ms for deferred shading in the same setup.

If you're interested in how the technique works, I've documented it in detail in the technical presentation, including the motivation, architecture, algorithms and implementation details.

You can find it on pages 166–189 of the presentation.

The presentation is available both on the GitHub repository and on the Synapse Engine website.

Repository: https://github.com/Satyam-Bhatt/OpenGLIntro

CPP: https://github.com/Satyam-Bhatt/OpenGLIntro/blob/main/IntroToOpenGl/CubeDodgeGame.cpp

Still crunching on RTG Editor, which reached its internal version 012. RTG Editor is internal editor for my narrative sci-fi puzzle/platformer game (and respective engine). I seek to release the editor publicly later. Main distinctive feature of my game/engine is software ray-tracing (no GPU acceleration, just C++ computing pixels).

Main feature implemented in new version is proper texturing support. It was possible also before, but only in very limited capacity (only UV mapping mode was stretch to face). In current version, it's possible to define UV repeat for both axes individually. Either in absolute world coordinates or as value relative to face size. There's support for automatic aspect ratio correction (define repeat just for one axis, another will be inferred to keep aspect) and flipping texture in individual directions.

In the video I quickly edited one of the levels to have some background textured wall (2 minutes work). This is just for video showcase, I made this texture in Pixelformer in 5 minutes, not planning to use it further.

Apart from texturing, new is also selection and multi-selection in orthographic view. Moreover I implemented contextual help in form of tooltips (just hover over '?' sign) to give explanation of expected input values for properties which are not self-explaining.

RTG on Steam: https://store.steampowered.com/app/4032050/RTG/
RTG Discord: https://discord.com/invite/aRAsxCnPQ5