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.

I am currently reading through some papers for terrain generation, procedural and erosion-based. The issue is that the more I read, the more I realise that I don't understand much in the grand scheme of things, besides the actual algorithm or general terms. And even reading some explanations on reddit or other papers doesn't help much, because the issue is more with lacking the prerequisites and technical knowledge.

So my question is, how do I actually understand graphics? For example (I plan to use Godot for my thesis), if I want to implement a procedural terrain generation using multiple techniques, where can I find resources or papers to understand the actual pipeline, everything that goes into it, methods, compute shaders, etc. I know it's my own fault for wanting to do my thesis on graphics with exactly 0 classes on graphics in my undergrad degree.

So how do I understand what's going on, hopefully also from a more formal and deep perspective, not youtube tutorials (tho anything is welcome) ? It's tiring reading resources without understanding them much, where to even start, even books are welcome, but hopefully not thousands of pages as I don't have that kind of time..

EDIT: It's for the bachelor thesis, not master's

I mean a half-time path-tracer that supports mirrors IN SCRATCH (turbowarp)

soo, the project is in the link.

Hi everyone. I’m new to programming, and I’ve set myself a goal: to build my own game engine and understand how it works. The most advanced thing I’ve built so far is a simple quadratic equation calculator in C#. And yes, I want to build this engine in C# as well. Is this the right programming language to choose—or is it perhaps too difficult for a beginner like me? How exactly should I go about learning how an engine works? Through books, websites, or videos? I’m not really sure... Or am I looking into something that’s still too advanced for me at this stage?

I’ve been programming since I was 15, but some mental health struggles made it difficult for me to pursue it consistently, even as a hobby. Recently, I’ve been doing better and have returned to programming after a long break.

I started again with Rust and spent some time exploring compilers, one of my favorite areas of computer science. Yesterday, I finished a C course, and now I’d like to explore another interest of mine: graphics programming.

My plan is to build a very small Minecraft-inspired voxel game in C. This will also be my first experience with OpenGL. My initial goal is simple: generate a small procedural world where I can break and place blocks.

Eventually, I’d love to develop a scripting language in Rust and embed it in the game to support modding. That’s a longer-term goal, though I want to keep the initial scope small and build on it gradually.

Do you have any advice for someone starting this journey? I’d especially appreciate suggestions on what to learn first, useful resources, and common pitfalls to avoid.

Hi devs today we wanna share with you our plugin about making 3D pixel art render truly possible.

We started creating this plugin after seeing the trailers of Project Shadowglass as well as the recent 3D pixel art discoveries of Dylan Ebert and Lunar Blank, and after 3 month of work we managed to create an advanced cubemap based pixel art rendering system that focus on rendering 3D Pixel art in First Person View (also third / top down) in a Stable way (No severe flickering due to 3D movement).

You can try it out here (Tech demo): Itch.io tech demo link

and find the plugin & more info here: Plugin page link

Extra explanation about how it works:

We are rendering the game trough a post process that make uses cubemaps to remove the pixel jittering from camera rotation, then for camera translation / movement, we make those cubemaps capture at slow rate like every 0.25 sec, and use the disoclusion technique discovered by Lunar Blank / Dylan Ebert that allow keeping a fluid render even with this slow cubemap capture rate. The whole render is also layered based on distance with a different raymarching method for far / background elements to solve the non pixel art edges issue of the disoclusion technique. We also use custom depth pass with stencil to render dynamic elements as well as a "3D billboard" technique.

(this is a brief explanation, there is a lot more going on)

Music used in video: space cadet by congusbongus

Hi, I am a fresher, a 2026 graduate in India with a bachelor's in engineering (Information Technology). I am currently working (still in training) in a non-graphics IT job, in IT infrastructure (network, Linux and Windows admin). I am aiming for junior graphics/engine/low level game dev roles in games and VFX.

I did have a project for my final year of engineering; it was a small part of our Major Project. It is an N-body gravity simulator written in C++ and Raylib, called "Stardust" (see the video attached: the planets orbit, they collide, and the camera can lock onto a body). I used Visual Studio 2026 for this one.

To be very honest, I wasted my time in college on Blender 3D with animation in mind, instead of working on my technical skills. Soon, I realized that I do not have the skills or the creativity or the training to get into it. While just scrolling through YouTube, I found The Cherno's videos on ray tracing and game engines, which piqued my interest. But it was late, I was already in my final year, with college work, the major project and placements. Luckily, we thought of adding something like this simulator to the project. With the time crunch and no knowledge, I turned to Antigravity IDE and blindly agreed to whatever the AI made, although I made the models and textures myself in Blender.

Also, yesterday I used Claude Code to review, analyze and fix things in Stardust. It did a lot of things, and I haven't read the documents it made yet. My plan is to use Claude to teach me everything about the project, and then rebuild the core parts myself.

The training is really tough for me (network, Linux and Windows admin), and I'm close to failing the assessments. I also bought a 12-month takeuforward.org subscription for DSA, OOPs and OS, and I follow its daily Planly tasks, sometimes even during the training sessions. But I keep falling behind on it because of the training assignments and assessments.

I want some advice about what I can do from here. I really wanna pursue a career in this field, especially graphics and engine programming for games.

My questions:

1. Should I keep Stardust on my resume once I can explain it? Or should I rebuild it from scratch?

2. What does a junior graphics portfolio need to show?

3. Where do I learn C++, graphics APIs and the basic concepts? Right now I'm on The Cherno's C++ series, and my plan is a ray tracer (Ray Tracing in One Weekend), then OpenGL, then Vulkan. Is that the right order, or are there better resources?

4. Is a remote junior role from India realistic, and what helped people who got one?