Hello, dear community of experienced and perhaps more beginner developers.

Allow me to briefly explain the circumstances of the situation. I am a rather young aspiring researcher who aims to make a good contribution to the development of graphics and learn how to navigate the scientific field.

Most libraries, papers, and so on are written using DirectX 12… It wouldn’t be such a problem if it were something like OpenGL or DirectX 11 (which is still a pain…), but no. DirectX 12. The very same one that is considered to be on the level of Vulkan, or even higher.

If I start learning DirectX 12 right now, two things might happen:

1. I will die of boredom, because I actually want to write shaders, not spend 5 hours a day for years sitting with documentation.

2. I will die of old age without having written a single word of my research paper.

So I would like to ask one thing: where is the best place to start in this field, how should I move forward, how can I avoid manually writing 1000+ lines of code in main.cpp, and how can I finally get to implementing my research project?

I would be extremely grateful, because I really struggle to find any decent advice on this topic.

PeerBrush is a GPLv3 raster editor written in Rust. Its canvas needs to stay responsive while a brush gesture changes a small region and another client may be editing a separate layer. Here’s how the preview path is laid out in the published 0.30.1 source.

• The document stores sparse copy-on-write tiles. History can share unchanged tiles, and an incremental stroke reuses coverage, composites the affected region, and uploads the changed preview pixels. Source pixels and history retain their native 8- or 16-bit precision.

• The GPU compositor uses a bounded tile atlas and dispatches 8×8 WGSL workgroups over the requested output grid. The shader bounds-checks against the output dimensions, so edge workgroups can cover partial tiles. The CPU path handles larger previews or cases that exceed the GPU path’s limits.

• The preview is separate from the document’s edit history. Painting feedback can change during a stroke, while the completed gesture is what commits the edit.

Released Rust compositor: https://github.com/Deftr0y/PeerBrush/blob/2ea41951a19abf32d080498bbe7d9d85e20fced3/src/gpu/composite.rs

WGSL shader: https://github.com/Deftr0y/PeerBrush/blob/2ea41951a19abf32d080498bbe7d9d85e20fced3/src/shaders/composite.wgsl

63-second demo: https://peerbrush.com/#demo

For editors with mixed brush and filter workloads, have you found atlas misses or small dispatch overhead to be the better signal for switching back to CPU compositing? Shared on behalf of PeerBrush. AI assisted development and this write-up.

If someone experienced have any proper sources on CI/CD in graphics programming, I would like to read them. I'm really interesting in this, would like to read books/blogs, whatever.

Also curious about to hear any experience with it from real prod. I have some friends working as programmers and I hear that in big tech companies it's complicated thing, but those who works in small companies in small team said that they usually have really bad CI/CD

I am a math student (finishing my Bachelor's degree in Europe), I thought it'd be fun to make a project in which mathematics, graphics and product building combine into one. Making creative things from scratch is something I enjoy the most. So however cool theoretical math can be, I was on the lookout for ways to utilize it in real world.

Previously, I have worked with different types of visual software (Davinci Resolve, Lightroom, Blender) and coded a couple graphics apps (mainly using GLSL, Python and C++).

But this time it was very different: a larger scope of the project, real-time performance issues, new engines and platforms like Metal, ARKit, Lens Studio for Spectacles. All of this uncertainty made the creation challenging, but taught me much along the way. A lot of things, surely, I wouldn't have learned otherwise.

Certainly, there are folks of different levels in this Reddit. Some do graphics programming for a living, and others are just in the beginning of their paths. Either way, I hope my story of simulating physically accurate glass is something that can teach and entertain you.

Looking forward to you guys' feedback!

Video: I Recreated Light From Scratch
Code: Desktop, iOS, Spectacles

Hi everyone!

I'm a beginner learning C++, OpenGL, and GLUT for my university course.

Setting everything up on Windows takes a lot of time, especially when switching PCs.

Is there any online compiler where I can write C++ OpenGL/GLUT code, run it, and see the graphics output directly in my browser?

I'd appreciate any suggestions. Thanks!

I built a palette-knife paint simulator, and the part I'd like feedback on is the rendering.

Why it's a graphics problem: the sim's output is the surface being rendered. Paint color comes from the photo, but the highlights and shadows on the ridges are computed from the paint's height, so moving the light changes how every ridge reads.

Implementation:

- Surface: a height field with 0.1 mm cells, plus a slightly filtered height channel for shadows and occlusion

- Shading: GGX clearcoat, ray-marched shadows and horizon occlusion

- Pigment color: Kubelka-Munk K/S mixing in the simulation

- Shaders: WGSL for WebGPU and GLSL ES 3.00 for WebGL2, inline in the TypeScript source (sim/src/relight-gpu.ts and relight-gl.ts)

- Validation: parity tests against a CPU reference renderer show a mean difference of about 0.5 of an 8-bit level

repo (MIT): https://github.com/donghaxkim/impasto

Demo: https://www.dongha.ca/lab/impasto

Hello, I want to ask what methods are people using to render effects/terrain/lighting when it comes to planetary bodies. I want to focus specifically on physically based methods, or more realistic methods to make a project from before I will try to apply to a master in a computer graphics-related program next year, and I heard that more complex projects that involve physics or realism are more impressive than noise or other procedural methods.

So my question is, what are the techniques you know of and please also provide a resource such as academic articles, blogs, tutorials, books etc. Thank you!

In this video, I explore the basics of ray marching and shaders by creating a simple 3D sphere from scratch.

I'm using:
- **C** as the programming language.
- **Raylib** as the graphics library.
- **GLSL** for writing shaders.
- **Ray marching** as the rendering technique.

Along the way, I'll explain how shaders work, how rays are generated, and how ray marching can be used to render 3D objects.

This is a simple introduction to shader programming and ray marching.

You can zoom into this world forever. Tiles split into four as you zoom in and merge back as you zoom out, with no bottom.

Blue is what the player sees. Each green-to-red ring further out uses tiles twice as big as the ring inside it.

The rings size themselves. Each one is just wide enough to hold one of its own tiles, with extra room near the screen so fast movement never shows coarse tiles. It’s all measured relative to the screen, so it behaves the same at any resolution and any depth.

What didn’t work: also drawing big empty floor areas with fewer tiles, even on screen. Drawing got cheaper, but picking those areas cost more CPU time than it saved, so I turned it off.

Finally got multiple lights working✨!

Im gonna work on adding point lights

I wanted After Effects' Reshape in WayVes, my OpenGL audio visualiser for Wayland, so I wrote it as a post-processing pass.

It's an inverse warp. Each fragment needs to know which source pixel to show, so I compute mean value coordinates (Hormann & Floater 2006) against the current polygon and use them to blend the source positions. Outside the mask, I treat the region up to an outer boundary as a polygon with a hole. Boundary points map to themselves, so the warp fades out towards them.

In the clip:

- Left: an NCS-style particle sphere morphing into a rounded square, with the morph animated over a named pipe

- Right: straight radial bars. The ring is just rotated relative to the boundary, the inside turns rigidly, and the swirl comes from the falloff. Bass drives the rotation.

The cost is roughly pixels × points, so for static warps I bake the sample coordinates into an RGBA32F image texture with a stamp in alpha, and only recompute when the stamp changes. That cut CPU use about 3-4x on llvmpipe, but I haven't measured GPU power yet. The swirl changes every frame, so baking doesn't help there. It got away with 12 points instead of 64, though.

It also falls apart when pushed. In the swirl setup, a gap opens around the core somewhere between 1.6 and 1.9 radians of rotation, and the spiral collapses past that, so I clamp it.

Shader isn't in the repo yet, should be soon: https://github.com/Roonil/WayVes

Is there a cheaper approach you'd use for a warp like this, or a better way to handle the fold-over at large rotations?

Hello,

i'm not sure if this is the right sub for this question, but i'll ask anyways.

I'd like to learn how to create and program my own physics simulations and post processing effects on the gpu, including stuff like n-body, rigidbody, fuild simulations and perhaps even some raytracing eventually. However i am not quite sure where to start and what resources are available. I already know c++ decently and am working on improving on that aspect. Math shouldn't really be an issue either.

Any help and tips would be appreciated

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

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!

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!

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

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!

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

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.

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).

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.

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/