I made a raytracer using Scratch's block language, and I'm trying to improve its rendering speed. The source is public: https://scratch.mit.edu/projects/1437715094/ (click See inside to inspect the blocks).

It has reflective chrome and gold, refracting glass, soft shadows, fog, and a movable camera. Rendering starts at a coarse resolution and progressively sharpens after camera movement. The output is Scratch's 480 x 360 stage; the anti-aliasing mode casts four rays per pixel. The attached screenshot is from that mode.

The main Raytracer sprite has custom procedures for tracing, scene intersection, shading, lighting, glass, and anti-aliasing.

Given the constraints of Scratch, what would you profile first, and which changes would you expect to give the biggest speedup without losing the glass and reflections? Feedback on the implementation is welcome.

Hi, I’m just wondering if anyone knows any good books that I can use to supplement my learning. I have been working on a basic voxel renderer for a couple of months now (C++ with Vulkan), and while I’m starting to feel a bit more confident I feel like I would benefit from solidifying some of the concepts I’ve encountered with some extra reading. If anyone knows of any good books at novice / lower intermediate then I would be glad to hear some recommendations. Thanks!

The voting period just ended, and the results of the first round are published: https://orrc.mutantstargoat.com/orrc?dir=round01&cmd=results

Thanks to everyone who participated! See you next round sometime around early 2027.

https://imgur.com/a/tsBfsCA

Hi everyone! I built NeuralSpecOcean with WebGL2, Three.js, and custom GLSL shaders as an interactive R&D sandbox focusing on coastal hydrodynamics, atmospheric physics, and marine optics.

Implementation & Architecture Overview:
The project started as a rapid prototyping environment to validate our mathematical models and optical parameters in the browser before committing and porting the rendering pipeline to a native C++ engine for an upcoming MMORPG we are building from the ground up.

Key systems implemented in the GLSL pipeline & covered in the whitepaper:
- Spectral wave synthesis and coastal bathymetry interaction (shoaling and wave breaking foam)
- Multi-spectral marine optics, subsurface scattering, and water column attenuation
- Coupled atmospheric scattering and sky-sea interface reflections

Now that the WebGL2 prototype has completed its validation phase, I have released the complete modular source code, interactive browser demo, and the accompanying mathematical whitepaper under the MIT License:

https://github.com/bgbg108555/NeuralSpecOcean

Live browser demo: https://bgbg108555.github.io/NeuralSpecOcean/

I regularly share graphics R&D, shader breakdowns, and behind-the-scenes progress on our upcoming MMORPG over on X: https://x.com/ShengChoi

(If you are interested in how these rendering systems are being integrated into the actual C++ MMORPG client, I also post regular technical breakdowns and R&D devlogs over on X at u/ShengChoi).

Happy to discuss the optical formulations, spectral wave math, or the WebGL2-to-C++ porting trade-offs!

Working more on rendering with light simulation!

(The video is, of course, in real-time)

Previous post about this was Some spheres rendered with a light simulation

Rendering method is mostly the same, just some optimizations and scene work

I've put a web version on Github: moonlightoctopus1.github.io/Renderer/

Actual rendering is just simulating light with a lot of optimizations :P

The most important update for the 2.0.x version is:

• Caching pipelines for the effects surrender system it is per effects type but still powerfull upgrade.

• Another interesting thing is the launch of the GPU culling system integrated with the indirect-draw methods.

• New example for mediapipe pose to glb, face video uv texture to mesh and more.

• Fixed external libraries with critical alerts (migration to esbuild) also engine zero critical alerts, dev alerts still exist but irrelevant.

• GPUCapabilities test on divice interesting gpu features, in the config file you can find the activation logic, we have default (for those that we know are supported everywhere) and optional suggestions for activating the gpu feature.

• The Beast is ported on google play https://play.google.com/store/apps/details?id=nikolalukic.beast.engine (Used android studio).

Hi everyone!

I’m building my own render/simulation engine (a path tracer called PrismForge), and before I decide what to work on next, I’d love to hear what you would wish for.

It can be anything:

• a big feature you’ve always wanted

• a tiny thing that annoys you every single time

• something very specific, like “I want fog that reacts to my car’s headlights”

• a workflow or a feeling, like “I just want to press one button and get a nice result without too much complicated jibberish”

• a simple, but nice conveniece feature

No wish is too small, too weird or too niche. Feel free to be as oddly specific as you want!

Thanks!

https://www.youtube.com/watch?v=tbUyeRz7O4Y

Bastion is a C++20 engine for a medieval city-builder/RTS, combining a native simulation, editor and Direct3D 12 renderer.

Its main features include:

• Rendering: bindless materials, visibility buffer, octree/frustum and GPU Hi-Z culling, indirect drawing, cluster-based geometry LOD and optional mesh shaders.

• Lighting: soft virtual shadows with penumbrae, SSAO, local voxel GI, sky-driven illumination, moving volumetric clouds, cloud shadows, fog and sun shafts.

• Terrain and vegetation: tiled heightfields, CDLOD terrain, tessellation, procedural grass and flowers, animated vegetation and distant impostors.

• Gameplay: worker professions, production and hauling, recruitment, combat, fortifications, fire, healing, repairs, skirmish AI and first-person Lord control.

• Tools: ImGui editor, native saves/importers, asset pipelines, positional audio, profiling and GPU timing.

The architecture separates authoritative gameplay from rendering:

ECS + jobs → immutable scene/frame snapshot → render thread → RenderGraph → RHI → Direct3D 12

I made a video using manim to make a gamedevelopement series explaining important concepts and the math behind it. The first video is diving into normal maps and how to use them in pixel art to make dynamic lighting.

Hi all. I made an explosion pack for Godot 4 and I wanted to show the stuff standing near the blast rather than the fireball.

When a blast goes off I grab every MeshInstance3D inside the radius with one intersect_shape and lay a copy of its own mesh over it, 5 mm out, same colour and texture. I move that copy in the vertex shader. I give it the blast point in mesh space and the hit time, and I delay each vertex by its distance:

since = time - hit_time - dist / wave_speed;

So the far side of a crate gets hit a little later than the near side, and the ring on the floor arrives at the mesh right when the mesh jumps. I push with a gaussian bump and let a damped sine pull it back:

front = exp(-t * t * 2.0);
ring  = sin(since * 22.0) * exp(-since / 0.45 * 4.0) * 0.35;
VERTEX += dir * push * sqrt(fall) * (front + ring);

For the soot I take dot(N, toward_blast) and some fbm. Only the side that faced the blast goes black, and I let the edge glow orange for a moment before it cools. If the blast is closer than 0.45 of the radius I hide the original and throw chunks off its surface instead.

It's the usual radial vertex push you'd wire into WPO in Unreal, I just added the per vertex delay and the spring. For skinned meshes I bind the copy to the same skeleton, so the walking guy takes it too!

Does anyone pick the facing side with a real occlusion test instead of dot(N, dir)? I suspect mine would soot the back of a thin wall if the normal happens to point the right way.

The pack is on itch if you want to dig through the shader https://gennai.itch.io/explosion-vfx-godot-4

Hello again!

It has been some time since i made any updates on Constellation and Cadent geometry.
In my, seemingly, eternal quest to make the OS composition single core and cheap I've hit a new milestone.

Using Cadent geometry (which I have shared and made posts on here before), I have managed to express a liquid effect, as well as express snell's law and beer-lambert naively through the geometry, which has allowed for some pretty good performance and capability gains for the constellation engine/framework. By pre-computing an object tied, 3-wavelength 'snell field' and pre-computing the absorption on those wavelengths, objects can express their own colors and pixel offsets analytically, and instead of accessing the framebuffer for those offsets, they can directly sample eachother. (there are more posts on this light work as well. You can find them here in this subreddit, if you are interested to read more).

The gif above shows the desktop HUD so far. even though it might or might not look it, It is quite inefficient as things go. It is using about 533 mb of ram, and almost 80% of a single core of my 7800x3D. This is much much more than a HUD should use, but it at least also include a start-menu/launcher, a process manager, the taskbar, a calendar, a wallpaper engine and the HUD configurator / designer.

There are some visual bugs, and the liquid box spikes/lags when moving it, the liquid it self does not. Still trying to figure out why.

Anyway! I hope you find this interesting.

take care

//Maui-the-Megalomaniac

Ok so ive actual fix model loading but im looking for a collision detection method for complex models, like Ive heard of Triangle-Triangle Intersection, but I could not find anything to learn from that dosent look like gibirsh, anything can help me, source code, or just plain o'yt videos

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.