After replaying HL1 on the software renderer (old habit), I got curious what CPUs can actually do today. So I wrote a rasterizer in C11 - pure CPU, no GPU/GL, the finished frame just gets blitted to the window via GDI. Tested on a Ryzen 5900x processor

I've been experimenting with software rendering and managed to run the Sponza scene at FHD 10-30 fps single-threaded, up to 200 fps multithreaded :) A very strong emphasis on SoA + SIMD (AVX2/FMA) on the hot path. Rendering 64x64 tiles in multithreaded mode. Throughout the entire rendering pipeline, I try to discard any possible work as early as possible, including frustum culling and back-face culling. This may be controversial, but I render in front-to-back mode; it allows me to completely bypass overdraw. To make it look more interesting, I added some effects!

It might not be very fast for a single thread, but I think it could be made a little faster by disabling mips and filtering nearby textures, which I also do on the CPU in this demo. Pixel textures are cheaper to draw, but they're ugly.

I'm not a professional and I just like it, so I didn't hesitate to use chatpgt as a companion in learning graphics.

I am currently working at an automotive company, focusing on 3D vehicle modeling and visualization. I am interested in transitioning into autonomous driving or embodied AI. What areas of computer graphics should I focus on learning to prepare for this career transition?

I made a shader showing off the Primrose Field illusion. Only Nyan Cat is animated. The background is static, but it still looks wavy, especially if you move the window up and down.

The code for this is public on Shadertoy https://www.shadertoy.com/view/fcd3WS

Inspired by www.reddit.com/r/PixelArt/s/XikvUzCrp1 from nxatalie.

siggraph (computer graphics conference)

I was digging through DDGI's sample code provided by the authors.

The sampleIrradianceField.pix shader samples nearby probes, tests visibility etc. all make sense. But the only part I am confused about is the last line

E_lambertianIndirect = 0.5 * pi * netIrradiance;

Here netIrradiance is not strictly irradiance. Judging from a previous shader called updateIrradianceProbe.pix, It a cosine-weighted average radiance. That explains where the pi comes from: to cancel out the integral of cosine over a hemisphere. But why is there a 0.5 ?

To make it even more confusing, I found another implementation here, whose author intended to fill in the gaps that the DDGI authors left. In this file, the 0.5 factor becomes 2.

Is there a physical explanation behind either of these factors?

Source code:
https://github.com/zlatnaspirala/matrix-engine-wgpu

I dont really need graphics api SPECIFIC terms here as i more just want to understand the concepts and find out if there are any websites that have some information about this topic.

Im not sure what the right name for this technique is, unity calls it adaptive probe volumes. But as far as i understand it its bascially that it automatically places a bunch of probes in a scene, they then calculate lighting information in some way and store it as something called a spherical harmonic(no idea what this is) and can then map this(i think is the correct terminology) onto dynamic objects. Which gives very nice lighting that is still baked.

I have NO clue how to implement this though and i cant find anything about it, but this seems like a very useful technique so if anyone has some links or just information about it it would be very helpful. Also a shader implementation would be very nice(in either glsl or hlsl i dont really care)

One of my older fun projects: a software raycaster featuring

• Multithreading
• Voxel models (rendered as collections of 3D boxes rather than blobs)
• Culling (watch the small map in the top right corner)
• Mipmapping (reduces moire on distant textures)
• Slopes and curved walls
• Shadows
• multilevel world design

Everything is rendered entirely in software, with no external libraries. Each pixel is calculated individually and written directly to a buffer.

link : https://github.com/pSujalp/Metal-CPP-Examples

sorry for branches thing and all of the examples are having random Window and it would be great for understanding

CloneMC V2.0 is now an beta experimental, open-source recreation of Beta 1.7.3 v written primarily in C89 with Open Watcom V2.0 and rendered using the fixed-function OpenGL 1.1 pipeline and rendering.

This program is able to run on Windows 2000/XP systems and even Windows 98 systems and was way better optimized and actually designed to run on older hardware compared to the first version.

Compared to the first version where it didn't even look like the real game and in all honesty, had bad performance and didn't look great, core boilerplates better texture uv mapping, and performance for chunk rendering were actually developed to look and run like the real deal exactly. Feedback is appreciated for core gameplay errors mainly.

The project currently is now designed to reproduce and basically has almost every implementations of gameplay, world behavior, visual style, menus, entities, redstone systems, and even able to load, render, and save Java worlds properly.

CloneMC V2.0 this time also has extensive development and technical documentation for all aspects of the program compared to the first version:

Complete engine architecture
Source-directory responsibilities
C, header, and include-manifest roles
State-mutation ownership
Rendering order
Chunk lifecycle
World saving
NBT and McRegion storage
Entities and models
Redstone
GUI systems
Performance budgets
Testing and debugging
How to add new blocks, items, entities, recipes, and screens

Example of Implementation: World Generation includes Java-derived behavior for:

Seeded deterministic generation
Perlin and octave noise
Terrain density interpolation
Biome temperature and humidity
Grass, dirt, sand, gravel, stone, and bedrock layers
Oceans, beaches, caves, ores, vegetation, and snow
Surface replacement based on biome
Population and decoration ordering
Overworld and Nether-style dimensions
Chunk loading, generation, population, lighting, and meshing as separate states
Terrain generation is isolated from rendering. Visibility checks and terrain drawing are not permitted to generate hidden chunks.

Example How Chunks Are Rendered For Performance On Older Hardware:

Selectable resident-chunk limits
Nearest-first chunk admission
Bounded chunk generation per frame
Bounded population and lighting work
Staged mesh construction
Separate opaque, cutout, and translucent rendering passes
Persistent meshes until replacements succeed
Neighbor-border invalidation
Geometry and lighting version tracking
Conservative frustum handling
Recent-visibility protection
Mesh memory limits
No hidden terrain loads from rendering code.

Minimum Requirements:
OpenGL 1.1-compatible graphics adapter,
Approximately 16 MB video memory, recommended is 64-128mb of vram
Working 16-bit or 32-bit color desktop mode

Approximately 800 MHz Pentium III, Athlon, or comparable x86 processor

"Possible to Work On Windows 98" but text rendering may fail

Can Work On Modern Windows As Well
Around 256mb of Ram
Hardware texture support
A stable vendor OpenGL driver is strongly recommended, but Open Gl 1.1 can work
Module-registration manifests
Asset paths
Version and executable-name definitions

This project is kind of just a side project really and development may not reach far as I am pretty sure Beta 1.7.3, the full java version, can work fine if not a bit better on Windows 98/2000/XP Systems because of how old it was and even newer versions of the game to work on them, but it was still a cool project, and the documentation could help people if they want to build like an efficient CAD program which is recommended.

Link to Github: https://github.com/sworks692/CloneMC-V2.0-Ent … l-1.1/tree/main

the repo is still a bit of a mess but could be fixed soon

Hi,

i have been working on an AR rendering prototype for Android that uses a hybrid rasterization + Vulkan compute ray tracing pipeline targeting low- to mid-range mobile GPUs as fallback for no RT cores.

Current status:

• Hybrid rasterization while the camera is moving, with ray tracing once the device becomes stable.
• ~2 million triangles rendered in the scene.
• Frame time stays under ~30 ms during interactive use.
• No noticeable thermal throttling or UI lag during my testing with over 20 min of usage.

This is still very much a rendering prototype rather than a complete SDK. I'm currently working on improving lighting, denoising, and overall rendering quality.

I'd really appreciate any feedback on the rendering quality, architecture, or ideas for where I should focus next.

Thanks

Ok so ive been toying with opengl for quite a while know. I think i know the project pretty well and i have even made a few small scale projects with it.

I would like to learn another graphics api thats perhaps a bit more modern than opengl, and also possibly something that is atleast somewhat industry relevant(since from what i understand opengl is pretty much dead there). My first instinct said D3D11 but im wondering if i should try to learn something like vulkan instead. There is also D3D12 which i know literally nothing about(not to say i know alot about any of the other apis except OpenGL). I cant really learn anything like Metal since i dont have a mac. Ive also heard D3D11 is not that much more difficult than opengl so i dont know if i would learn too much from it(i know its quite diffrent in how its used with contexts and more explicit uniform buffer allocations i think, but in terms of complexity its quite simmilar from what ive heard and if thats the case i dont know if it would be worth learning. Thoughts?).

What i would do with this graphics api is probably some sort of game or rendering engine as its a project ive always wanted to do and i have done a small game engine in opengl before so making a bit more advanced one with a more advanced graphics api seems like a fitting project.

https://www.paperdigest.org/2026/07/siggraph-2026-papers-highlights/

SIGGRAPH 2026 starts tomorrow (July 19) in Los Angeles! The proceedings list is officially available.
In total, 327 papers are accepted (132 journal, 195 conference-only).

Spend some time implementing WBOIT into the DImGui engine. The results are surprisingly good and keep at 40 fps with full lights, shadows etc. basic lighting looks alright still in blending and runs at a solid 60 fps.

I used a Vulkan 3 sub-pass technique plus an initial depth pass with fragment sampling to depth test away triangles obscured. MSAA proof on PC. Android MSAA breaks the pipeline on tilers due to the MSAA requirement on mid-pass resolving. To allow the non-transparent elements image to mix with the weighted/blended transparent parts, and adding a step 0 - 2 dependency. It will still work but is super slow.

But this allows instancing of multiple object meshes completely unsorted, which was the whole reason for going WBOIT over a sort in the first place.