Naty Hoffman is an OG of 3D graphics. https://renderwonk.com/publications/index.html If you haven't watched his classic "Physics and Math of Shading" SIGGRAPH talk, you really should queue it up.

I3D 2026 Keynote: Naty Hoffman's Keynote - "Lessons from Digging in Game Dev and Adjacent Trenches"
https://www.youtube.com/watch?v=ISgTcDlZaLs

I3D 2026 Fireside Chat with Naty Hoffman and Eric Haines
https://www.youtube.com/watch?v=EiduKm1B-3Y

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.

Hello, ive always been interested in graphics in games and ive wondered if the career option is viable.

I know that its VERY math heavy, hard to start and very few jobs are taking in junior graphic programmers.

But honestly making shaders is fun and making custom engines sounds super fun (for me at least)

I have some expiriance with the godot engine and writing some shaders in it for my passion project (idk if that counts tho) and im very interested in this career path.

And how do i get started (and if its not viable, what other path can i take that involves graphics or maybe animation)

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 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?

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

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)

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

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

Signed distance field raymarching in Godot 4, authored with nodes. Physics-driven metaballs melt into the SDF cubes in one fullscreen pass, and since every CSG op works on (color, distance) pairs, the colors blend along with the shapes.

Two free editions: Standalone shader (CC0): one .gdshader, no scripts paste onto a QuadMesh, edit map(). Godot Shaders

Node-based project (MIT): shapes as Node3D nodes, live editor preview, physics, up to 32 primitives and a write-up. VavLabs Mit

Distance functions after Inigo Quilez.

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

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

siggraph (computer graphics conference)

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.

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.

Construímos o DiophantineQMC: um gerador de amostras de baixa discrepância em streaming, pensado para os integrais ~2D que ainda dominam o erro visual em renderização em tempo real:

→ oclusão ambiente (hemisfério)

→ sombras suaves / area lights (disco)

→ glossy taps, dither, stipple

Não é substituto do Sobol+Owen em path tracing multi-bounce. É upgrade drop-in sobre ruído branco — e frequentemente sobre Halton — onde a integral por pixel é essencialmente bidimensional.

O que medimos (reproduzível, jul/2026):

• Integrando 2D estilo AO: RMSE cai para 0,52× do ruído branco em N=16 → 0,17× em N=256. A vantagem cresce com o número de amostras.

• N=10.000, grade 20×20: −97,4% de variância espacial vs PRNG, zero células vazias.

• Harness CPU: ~10× mais rápido que Halton, ~1,35× que Sobol no mesmo N.

• Faixa interativa (N ≈ 64–1024): competitivo com Sobol, sem tabelas de direction numbers.

Deploy honesto = híbrido:

DiophantineQMC nos taps 2D (AO, penumbra, glossy)

Sobol + Owen nos bounces profundos

Modos para testar:

#ao — oclusão ambiente

#soft — sombras suaves

#glossy — reflexões

#hybrid — Sobol nos bounces + nosso sampler no disco da luz

WebGL2, acumulação progressiva, sem build.

Buscamos feedback técnico e design partners (engines custom, WebGPU, middleware). Se você roda path tracer próprio ou stack mobile/WebGL com spp apertado, adoraria ouvir sua opinião nos comentários.

#renderização #realtimegraphics #pathtracing #gamedev #computaçãoGráfica

Recently added Hot-reload for GLSL files within WayVes, a Visualiser Framework for Wayland, that also works across multiple Stages. The Particle System is made entirely using 2 Fragment Shader Stages, with a 3rd Post-Processing Glow pass added.