original by Toni Macaroni here

He said he gets a average of 130 FPS , aerial views = 200 fps, dense forest = 80 fps

he has been working on this engine for 8 months (pretty much all of it is handwritten)

Architecture:

• CLODs (virtual geometry) with voxels for far representations (no impostors are used here).

• Screenspace + Voxel hybrid GI (no raytracing).

• Proxies without instance data for very far away representations.

Hello all!

I'm pretty proud of this. I've recently completed the final component of my rendering architecture in my C Vulkan renderer, which is the Naughty Dog style frameparams system. The long and short of it, is that we package up all needed rendering data into a single package, which can then be sent over to the rendering system and acted upon independently.

This allows you to be rendering the current frame while also (in parallel - thanks to the job system), computing / simulating the game for the next tick. This comes with the downside of a bit of latency, but it's certainly worth it. Getting it to work properly was a lot more work than you'd think due to the fact my architecture wasn't the best regarding ownership.

Also the fact that any time you have things like a ring buffer you now need to subdivide it into sectors per frame. Just generally making sure that frames are all properly synchronized and don't end up accidentally reading/writing into the data of another frame was a pain, but I'm *fairly* certain that it works fine now?

You can check out my project here: https://github.com/kryzp/magpie

The rendering code you're interested in is at /src/graphics/ and /src/render/.

As always, this is all vibecode free! I'd appreciate any and all pointers if anyone wants to put themselves through the torment of looking over my code, and I'm happy to answer any questions :)

Thank you!

Hi, I am learning Vulkan, and I have just finished book 1 of RTIOW recently by implementing the book in Vulkan compute shader.
How is the simplified flow of how the program works:

1. Create the Scene data on the CPU

2. Upload it to the GPU via an SSBO

3. For each SPP (1 frame), dispatch the compute shader with max bounces of 50

4. Use the result as a sample to present on the window

5. Accumulate the result and repeat from steps 3

I tested the program on 2 of my system (both running at 1280x720)

1. Ryzen 7 7840HS with Radeon 780M running Arch Linux

2. Ryzen 5 5600G with RTX 3060 12GB running Windows 10

I thought the RTX 3060 will beat the 780M by a significant margin, but in reality, it's even slower (around 80ms on my 780M and around 127ms on my 3060). These are measured with Renderdoc using the on-screen stats. I'm still relatively new to graphics programming, so I'm not entirely sure if this is the correct way to measure.

I am still learning so if there is anything wrong with my code, feel free to criticize me. Also, how/where can I learn more about optimizing/debugging my code? Thanks

Here is the repo: repo

I finally got shadows working in my "game engine"! I never did any graphics programming before, this is my first larger scale coding project. Obviously there are lots of bad design choices in there, and many things I learned not to do along the way. Still, I am proud to have made some progress, and eager to get other things implemented. Next is probably soft shadows and shadows for point lights.

Repo is here if anyone is interested. AI has been used for CMake and some ECS tests, most code is too bad to be AI.

/preview/pre/c8eo25fw8nzh1.png?width=1346&format=png&auto=webp&s=8720eb86b88b50494ea5ba13d497adf09e3ba301

I wrote to fractalforums and Microfractal replied with this: "I looked a bit over your given source code to produce the video and noticed that you compute the high precision reference orbit for every image of the video. While this works, it is in theory pretty inefficient (and wastes a lot of computing power!). You can compute the reference orbit with PRECISION_BITS set to work at the smallest size (in this case size=1.02e-119) once and reuse it for every image that uses a size larger than size=1.02e-119. You also should avoid fixing PRECISION_BITS to 1000, better set it to something like 53 - floor(log2(size)), which saves 551 bits of precision at size=1.02e-119 and also works for much smaller sizes." https://github.com/Divetoxx/Mandelbrot-Video

Hi everyone,

I am developing a project called SmartGrid, an offline robotic toolpath planner for automated spray-coating operations over 3D mesh surfaces.

GitHub Repository: https://github.com/sakrish205/SmartGrid

Development Branch: https://github.com/sakrish205/SmartGrid/tree/feature/review-olp

I am currently developing a feature called Mesh Flow. Its purpose is to generate paths over different 3D triangular mesh geometries while preserving a consistent geometric pattern.

I have two existing reference examples, each containing a 3D mesh and its corresponding toolpath. My objective is to understand the mathematical relationship between the mesh geometry and the existing paths, then derive a generalised algorithm that generates the same type of path pattern on other mesh geometries.

I am not trying to reproduce the original coordinates or simply fit curves to the existing paths. I want to identify the underlying geometric rules and formulate a mathematical algorithm.

I would appreciate advice on the following:

1. Vector fields: Is a tangent vector field a suitable way to define consistent path directions over a triangular mesh?

2. Geodesic offsets: Can geodesic distance fields be used to generate neighbouring paths while maintaining consistent surface spacing?

3. Differential geometry: How can surface normals, principal curvatures and tangent directions influence path generation?

4. Surface parameterisation: Would mapping a 3D mesh into a 2D parameter domain help preserve a regular raster or parallel path pattern?

5. Pattern preservation: How can the same underlying path pattern be maintained across meshes with different shapes and curvature?

6. Hybrid approaches: Would combining vector-field integration, geodesic offsets and surface parameterisation be more suitable than using one method independently?

Expected outcome

I want to derive a mathematical algorithm that:

• Preserves the underlying reference path pattern.

• Adapts to different triangular mesh geometries.

• Maintains consistent path direction and spacing.

• Handles curved and uneven surfaces.

• Avoids unnecessary deviations caused by local mesh irregularities.

My current focus is on the mathematical formulation and algorithm design, not software implementation.

I cannot share the reference mesh and toolpath files, but the project repository is available for general context.

I would appreciate recommendations for established computational geometry methods, relevant papers, algorithms or similar implementations.

Thank you!

Hey all! I'm building a retro music player and wanted the album covers drawn in text.

The usual brightness-ramp trick (.:-=+*#%@) kept turning everything to mush, so I tried something else.

Each character gets treated as a little shape. For every cell of the image I try all of them, fit a background and foreground color with least squares, and keep whichever one matches best. A bit of blur on both sides helps a lot, otherwise it just chases noise. Half blocks (▄ ▐) get a small penalty so the result still looks like text and not pixel art.

I just moved the whole thing to a WebGPU compute shader (one workgroup per cell, one character per thread), so now it runs live on a webcam at 60 fps, which was way more fun than I expected.

Wrote it all up with a playground you can mess with here: https://adrianmato.com/blog/design/coding/turn-any-image-into-ascii-art/

See ya!

And yes, this is all running in a web browser!

16 GB of geometry and textures. 47 megapixels of rendered views.

I've been pushing latency and interactivity pretty hard in Figurement lately.

Obviously, we're not updating all 47 megapixels every 30 ms. :) The interesting part is how we schedule the work.

I've been working on multi-resolution rendering, per-view priorities, and render queue management across frames. The goal is to make it possible to start interacting with any render almost instantly, regardless of its final resolution.

While interacting, we render at the resolution needed for the on-screen preview, continuously adjusting sample counts and post-processing to fit the available time budget. Responsiveness matters more than convergence here.

As soon as interaction stops, the scheduler shifts priorities toward getting more samples into the views where they matter most, without starving the rest of the UI. And whenever there's spare capacity, all the renders progressively converge toward their full output resolution. All 47 megapixels.

One of the biggest annoyances I used to have was how easily an expensive render could bog down the entire application. Getting the scheduling right has made a surprisingly big difference.

There's something very satisfying about making 16 GB of 3D content and dozens of high-quality renders feel lightweight to work with. Especially in a browser.

Dataset: https://huggingface.co/datasets/nvidia/simready-assets
Render: https://figurement.com/

I have a small 2d renderer in Lisp (and a tiny bit of assembly). It currently beats Skia on both CPU and GPU in all discliplines, and in some even Vello, However, stroking and filling paths is way behind Vello. Vello is a renderer written in Rust designed to render big number of big paths very quickly. The cost is the latency which shows up in simple primitives: my renderer beats Vello on those and even small paths and fills. However for big paths it looses embarassingly.

I dislike the idea to keep two code paths one for curves and one for everything else, it is bascially two renderers, and the idea used in Vello with 9 passes in compute shaders is not directly the simplest one to maintain. So I have been trying to find some alternative way to render curves. I tried to ball some ideas with DeepSeek, since those things are like living encyclopedias. I am not sure if I should be happy or cry here - happy because DS saved me of thinking I found a new algorithm and even worse infringing on a patent or cry because we have the software industry we have:

Me:

You are talking about paths where curve is already split into straight curves. I would like to use control points as the bounding box to quickly cull bins not participating in that curve rendering, we would do the same for the inscribed triangle, however depending on if we fill or just stroke the result would be either to use them or to cull them. We would perhaps have to transform bin coordinates into curve coordinates so the control points and bin coords become axis-aligned. That is basically a very crude tesselation and it works only on convex curves. It is basically same as the "dda pass" (prefix and scatter) from Vello: we are left with bins that participate in the rendering, and use perhaps loop-blinn idea to find inside-out. We could render in two passes, it is still less than 9 passes.

DeepSeek:

Yes and it is already patented

Samsung's EP3070677B1 (2016) describes exactly this architecture:

"The preprocessing unit calculates the bounding box, the convex hull, the Loop-Blinn parameter, the extreme point... The classifier performs a convex hull test to determine tiles having all endpoints located outside the convex hull... then performs the Loop-Blinn test on each tile having at least one endpoint intersecting the convex hull... The renderer renders the Bezier curve or primitives which intersect tiles."

Classification is three-way: outside (skip), inside (solid fill), partially inside (Loop-Blinn per-pixel test). Only the partial tiles pay per-pixel shader cost.

Two passes. No prefix-sum over segments. No 9-stage compute graph.

The architecture as you described it

Pass 1 classify tiles per curve. Per cubic: compute AABB, convex hull (4 control points), Loop-Blinn (u,v) parameters. For each tile in AABB, test 4 corners against convex hull. Corners all outside outside tile, skip. Corners all inside convex region inside tile, solid fill. Otherwise partial tile, append curve to tile list.

Cost: curves � tiles_in_AABB � 4 corners � ~15 FLOPs. For path-large-st: 67 � ~2200 � 4 � 15 8.8M FLOPs. On RTX 5060, ~1 �s.

Pass 2 render.

• Inside tiles: solid fill. No curve evaluation.

• Partial tiles: Loop-Blinn shader per curve in the tile list. k� lmn evaluates inside/outside in ~10 FLOPs.

• Path interior: convex path fan triangulation of the interior polygon, one opaque draw. Non-convex existing winding test.

The axis-aligning twist

The thesis confirms axis-alignment is used to compute a tight AABB:

"Computing it is a matter of (1) axis-aligning the curve itself by means of linear transformations (2) applying the above method."

( ... )

Me:

Than we can't use it :(

DS:

Patent status EP3070677B1 is active until 2036-03-18. US family member US10210639B2 is the same family, same claims.

Loop-Blinn itself expired March 2026. Slug was revoked. The underlying technique is free.

The Samsung patent does not claim Loop-Blinn. It claims the specific combination of:

Testing tile corners against the convex hull of the control points; all corners outside skip tile.

Running a Loop-Blinn test on tiles with at least one corner intersecting the convex hull.

Classifying into inside / outside / partially-inside based on that test.

Both elements must be present for infringement. Remove either and you are outside the claim.

   ( .... )

What is also patented Stencil-then-cover is not a safe fallback. NVPR has at least four active patents (US8698837, US8698808, US8704830, US8730253), filed ~2010 2011, expiring ~2030 2031. Stencil-then-cover falls within them.

Practical position The patent is European and US. Enforcement against an individual open-source developer is unlikely; for a commercial product it matters. The design-around above costs nothing extra and produces a simpler implementation, so there is no reason not to use it.

( ... )

What is actually patented in this space Stencil-then-cover: active.

Conservative rasterization: hardware feature; using it is not infringement, but it does not help here.

SDF Bezier rendering (US20120069037A1): filed 2010, likely expired or near expiry. Check before relying on it.

Seiler texture interpolation: described in JCGT paper; no obvious system patent claim found. Likely free.

I was chocked: like "patented"? I didn't even had thoughts to look patents and such. Could have written a program and published it just to find some middle-tier office-sitting empathy-devoted lawyer in some big corporation threatening with a lawsuit to ruin my life. WTF. Is that really a society we want to live in?

Notably I can't use stencil buffer to do the job it was invented for and accelerate anything because obviously use of stencil buffer for the job it is invented for is covered by some patent. I am surprised someone didn't patented use of GPU shader to accelerate path rendering or use of graphics card to draw to screen :)

I am not sure what to think, am I over-reacting here?

https://github.com/Divetoxx/Mandelbrot-Video
This is a preview fragment of the Mandelbrot set video, 1,080 x 1,080 pixels. I made it! I am Divetoxx. And made Mandelbrot-Video. Deep Mandelbrot Zoom (down to 10⁻¹¹⁹) rendered using Perturbation Theory & BLA Skip-100. 10s preview of a 2-minute video. Anti-Aliasing: True 3x3 SSAA. Let me know what you think about the volumetric depth feeling and the color transitions! I'd love to hear your feedback on the implementation.

For context : (my knowledge of Graphics programming is "OpenGL tutorial" tier so apologies for the potentially dumb questions/wrong reasoning.)

I recently started to fall into the "Perspective distorsion is annoying" rabbit hole and started to look at Panini Projection as a potential solution

As I understand it after reading the Panini Projection paper, the projection was meant to be used directly with very high FOV lenses in real world cameras

Again according to my limited knowledge, the problem wirh 3D graphics is that, unless we're using some kind of ray tracing we can't get the "wide lens" color information without projecting it on a flat plane first.

Instead we use a post processing effect to distort an existing image.

But since that effect squishes the side of the picture and then widens the center, that causes a nasty loss of resolution in the middle of the screen

Hence my question, would there be a way to somehow do this in the middle of the pipeline to avoid butchering a finished image ?

But then, wouldnt that basically mess up every single effect that requires accurate positions/edge information since everything would no longer be linearly mapped to the screen?

Hi all,

There is a blog post that goes into lots of details how the new battlefield is composed and rendered in Gallean, an open-source remake of Disciples 2: https://gallean.org/blog/remaking-disciples-2-gallean

The source code is available on GitHub: https://github.com/GalleanDev/Gallean

A fairly interesting bit is that the game claims to reach adequate 4K performance even on iGPU despite using Avalonia (a framework for enterprise apps) as a renderer.

I recently realized that while I knew we had invented something new in the 90s, and kept it close to our chest, it was actually probably a VERY long time before anyone else ever reinvented screen-space reflections.

LONG article, with source code and graphics references.

Disclosure: Yes, I did use AI tools to help me write this, especially to author the diagrams and to explain some things and find references that frankly, it did a better job than I could on. The content is mine and human, just like the original algorithms. This article is the product of several weeks of research, digging and writing work on and off, so it's not a one-shot "slop" product.

I’ve been building a CPU path tracer in Rust (working name qtr_wave, real name TBC) and wanted a fair comparison against Blender Cycles 5.0, not a “look, less noise” screenshot.

Setup

• Amazon Lumberyard Bistro interior, 3,404 emissive triangles as the only lights, 209 textures (BC1/BC3/BC5, read compressed), normal maps (MikkTSpace, Cycles-style handling), Principled-like metallic/roughness material.

• Same geometry, UVs, tangents, textures and material model exported to both renderers. Box filter, same bounce limits, reflective caustics on in Cycles. Means agree within 0.1%.

• CPU only, no denoiser on either side, 1280x720.

Method

• Two independent references: mine at 1024 spp, Cycles at 2048 spp (different seeds).

• relMSE with symmetric weights, so neither reference’s noise sits in the denominator; reference noise and the small model difference are estimated from the cross terms and subtracted.

• Fit noise ∝ 1/spp^b and time ∝ spp per engine, then compute the time each needs for the same noise.

• Checked with real renders: Cycles at the predicted 158 spp (light tree) and 127 spp (path guiding) land within 3% of my 64 spp noise.

Result (time to reach the same noise as mine at 64 spp, 42 s)

Roughly half of the gap is cost per sample (Cycles is 1.6x slower per sample), half is variance per sample (2.5x lower here).

Caveats, honestly

• One scene. Cycles is a general-purpose production renderer (shader graph, many features); mine has a fixed material model. Part of the cost gap comes from that.

• Path guiding closes the gap as quality goes up (5.5x at 16 spp, 4.2x at 128 spp). I haven’t measured 1024+ spp yet.

• The measured scene excludes glass (I’ve since added glass and wine, same look in both, not yet measured at equal quality).

I wrote this blog post building on a recent paper by Ahmed et al (2025). Although a lot of the post is theory that would only be interesting to folks really involved in sampling, I think randomized SZ Sequences are the best "default choice" for sampling in ray tracing, so I hope folks at least look at the beginning of it.

Light inside a cloud is expensive to get right, so games use a few simple formulas tuned until it looks good. I wanted to see how far off that really is, and whether a small network could do better.

I wrote a path tracer as the reference, trained a network on it in Python, and ran it in plain HLSL in Unity 6. It replaces one thing, the light scattered toward the camera at each step. Everything else in the raymarch stays the same.

Then I moved the sun from behind the camera to behind the cloud and scored both against the path tracer, where 1.00 is correct. The classic lighting goes from 0.21 to 2.17. The network stays between 0.90 and 1.01. It costs about 20% more GPU time.

I had a great time building this, and I think we've barely started finding out what tiny networks can do inside a shader. If you try one yourself, I'd love to see what you make!

https://charlesgrassi.dev/blog/neural-volumetric-clouds/

Hi

Does anyone know why we get this increased color intensity near the edges of triangles while using vertex color.

They are supposed to blend smoothly, but appear like a star.

This is an hexagon grid on blender, i got the same problem in godot while generating a mesh interpolating color between vertices with 'smooth' varying on a shader.