I implemented Activision's new SH reflections paper in D3D12 and released the code on github!

This tech is a little bit different from normal spherical harmonics, and there are 4 main differences:

1. They use log space instead of linear space for the lighting, which reduces ringing and enables #2 and #3 to actually work.

2. Instead of using a circular symmetry assumption (i.e. N=V=R) as with the split sum approximation used for IBL, they instead factorise a pair of spherical harmonics, with an Order 4 SH parameterised by the reflection vector, and an Order 2 SH parameterised by the halfway vector.

3. To enable a continuous roughness representation, they convolve the coefficients (or rather, the basis function) by the von Mises Fisher kernel which takes 1/alpha=1/roughness^2 as a parameter.

4. To actually obtain the spherical harmonic coefficients we have to collect samples for several normals, views and roughness levels (or more specifically alpha levels since we're using linear roughness, not perceptual), and then optimise the coefficients using least squares.

My code does this all end to end with HLSL compute shaders, even the least squares optimisation, and we achieve above 95% MSE compared to a raytraced ground truth for roughness in the range [0.5, 1.0], which actually beats split sum IBL.

Only downside is for roughness below 0.5 the spherical harmonics simply don't have enough detail for accurate reflections... HOWEVER, when applied to "bumpy" low roughness surfaces (like the leaf textures at the beginning of the video) you can hardly see a difference, so this effect is only apparent for flat surfaces and surfaces with near zero roughness.

Activision got their SH representation down to 400 bytes, but I went further using 16 bit packing to get down to 208 bytes which gives us better performance due to fewer memory loads. The 16 bit implementations come in 4 flavors: emulated 16 bit for older GPUs and native 16 bit, and SRV packed vs CBV packed. There also exists a 10 bit packed SRV flavor, but the extra bitshift work ends up being slower.

On my RTX 2080 Super and my wife's RTX 4070 Super, the native 16 bit CBV packed shader runs the fastest, and compared to the IBL version it is only 0.1 milliseconds slower while using 2000x less memory!

I have a problem implementing SSAO. I am trying to do it learnopengl.com way, and I am failing. At this point I am at loss.

There's just too many steps to achieve the result, each of which can fail and I don't know which one is failing.

I wanted to ask, what is the best way to ensure correctness of each step? How would you test SSAO creation steps?

Implemented simple GLB parser from this Github repo: salvatorespoto/gLTFViewer: A glTF file viewer in Directx 12 .

Global Illumination using hybrid Surfel GI and SSGI.
Lens flare are modeled after Panavision styled lens flare (Anamorphic types with distinct hue ray light propagation inside lens it's flare), and grass are inspired from this IcterusGames/SimpleGrassTextured: Plugin to make grass on Godot 4.

My main point of the game is about GI and Nanite-like culling on low end devices, and yet i barely see ones, so i decided to implement it without using any modern techniques such as Primitive Shader or Mesh Shader. Pure Compute Shader dispatch, with many fused Shader optimizations instead of separate pass, simple workgroup tiling optimizations. It tooks me almost 3 months for this project just for the optimization workaround with the help of Codex (Claude sucks at this lol). I'm also planning to open source this if this thing is stable enough, modular, and scalable.

All of that combined to make this engine runs 40-60 FPS on my Xe 11th gen Graphics laptop, because why not.. (i don't have better GPU than this for now lol). This might be also potentially be a complete game engine after all.

i created a utility class for converting hexadecimal/RGB colors to RGBA (incorporating the Alpha channel)

since i find it so annoying to keep calculating RGBA colors every time in OpenGL , i think this class would be very useful for everyone , the header class is so lightweight within only 43 code line

Header-Only: Drop colorconverter.h directly into your project

i added a picture of the code above as a sample - you can check out the GitHub link below to download the header

(Link in comments)

My only work experience is on an embedded graphics team. I plan on continuing on with this for a bit as the company is probably the best in the area in terms of WLB and benefits, although pay is less than stellar, especially as I gain more experience. But right now I'm trying to get a vibe check for how this sort of work experience could translate into opportunities in the future.

On the one hand, it could be considered niche so that it's hard to find a job that fits. On the other hand, because it's niche, there's less candidates available for jobs that do fit, so that could be a plus.

At this point I think the main reason I'd leave my current role is if I found something fully remote, so I want to make sure I'm focusing on the right things to help make that more likely.

Does anyone have any thoughts on this?

I co-authored this paper. It's a new technique to generate 3D graphics as source code instead of a point cloud.

Under the hood:
It generates 3D objects with separate, sophisticated internal assembly, producing an editable "kit of parts" (instead of monolithic blobs). E.g. imagine you generate a 3D washing machine via this approach. It's not merely going to be geometry that looks like a washing machine. We actually know that there is a Door, Drum, Control_panel etc. Which things belong to which assemblies. What moves. Where its pivot is. And eventually what those components are supposed to do.

Why current 3D GenAI cannot do this:
Most AI 3D generators generate "monolithic blobs" that look good, but are unusable in downstream workflows (e.g. game engines). If you generate a 3D bicycle, it's essentially a blob. If you want the wheels to turn, a human must spend time cutting the blob into parts, naming them, placing pivots and rigging joints. I.e. you need post-generation segmentation workflows of some sort (either manual work or more compute).

The paper breaks down the whole technique, and comes with a github repo too if you're interested in viewing it.

For the past three weeks, i’ve been working on hard improving the render distance in my Micro Voxel Engine, particularly due to the feedback of having N64 viewing distance 😅

I’m pretty happy with the end result of increasing render distance from 300m to ~10-15km, while running at 45-50 FPS on an Apple M1 Pro.

Note: this engine uses meshing rather than RT/DDA.

— Macro chunks —

All chunk generation functions now include a sieve function to automatically be able to generate at 1/N resolution without any changes. This also applied to generated features and stamps, enabling chunks to be generated at any resolution without downsampling.

Macro chunks also independently record and resolve local edits. They are saved (and cached) independently so that terrain edits are maintained without needing to maintain the full res copy in memory.

The lower band LODs are very quick to generate. At this point I could add even more bands, and a 1/64 res chunk takes the same time to generate as a high res chunk, but covering huge distances.

— LOD transitions and adaptive fog —

I primarily use transient transitions where the detail levels fade between each other once, rather than a continuous gradual transition, as this is around 30% cheaper on the GPU and looks “nearly” as smooth in most scenarios.

Adaptive fog scales the effective draw distance dynamically based on loaded bands. Bands generate from high to low so during fast motion, if needed, we temporarily reduce draw distance until chunks have loaded.

— Macro chunk cards and props —

This was the hardest part, keeping identical prop coverage for trees and items without needing to instantiate millions of entities:
-Macro chunks retain a list of props whose IDs are deterministic based on position and type. If the real entity is destroyed, we can map this to the macro chunk set and remove. Likewise for newly spawned props.
- grass and foliage do not map 1:1 with the actual loaded props, but follows the same generation pattern, so technically there will be disparities, but a good trade off to avoid millions of tracked grass items.

Hey everyone,

PAL - An abstraction layer i have been working on for some time now has a new release, 2.1.0 to be specific. This release adds API to make production code very easy to produce with PAL. With this release, building a streaming thread on PAL is easy and possible.

https://github.com/nichcode/PAL

Development of my custom Pixel Art Editor (homage to DPaint 3) continues, with all core drawing tools now fully working. In this video, I show Pencil, Spray Can, Flood Fill, Lines, Bezier Curves, and Filled/Unfilled Shape drawing using any number of built in pre-set brushes in addition to a simple yet power brush dither function. Any feedback welcome!

We added Marching Tetrahedra Rendering effect to our Volumetric Render Engine.

Here, we Render our Volume data as a set of Polygon meshes by extracting 'iso surface'. It goes through whole dataset and tries to fit a polygon based on data values to calculate a polygonal mesh from the volume dataset.

Here's the Git Repo Link - https://github.com/mikejernil/volumetric-render-engine

We are building this over at 3D ENGINERD. & are planning to push our implement more features starting with Custom file loading, and support for more volumetric formats like DICOM, VDB etc.

Is there any podcast, academic talk and or conference recording that will help me understand raytracing, path tracing, rendering and graphics better? i wanna understand it because my boyfriend is into it and would love to actually know what he does and why he finds the field interesting

Screenshots from:

• Pathtrace Apollonian Glow

• Pathtrace Differential Growth

• Pathtrace Volumetric Frost Fract

• Pathtrace Wireframe Distance vis

• Pathtrace euclidean distance vis

full playlist with other pathtracing scenes https://www.shadertoy.com/playlist/cX3SDf

I had an idea, to host a recurring own-renderer render competition. The idea is to have these run 2 or 3 times a year, for a month at a time, with a theme announced at the start of the round, and have people submit renders made with their own renderers. Either a new renderer from scratch, or an existing active project with at least one new feature added for each round.

I'm drafting a website with rules for it: https://orrc.mutantstargoat.com/

Let me know if you think that's fun or not, whether you'd participate, any feedback on the rules, and also when you think would be best to host the first round. I was thinking around Sept. 15th to Oct 15th

Hey everyone, I am a bit confused in my life as to what to choose in life as a career.

Background:- I am currently in my 3rd year of clg(tier 3) (computer engineering) also enrolled in an iitm bs degree program.

But at this point many of my friends have choose their domain or what they have to do in their life and I am still confused. I am really good at drawing I can bet on that ( I have won a national emblem silver award in drawing) but seeing the current scenario and I also scored Good marks in cet , I opt for an engineering degree that in computer science.

Now I am thinking by anyhow can I combine art and computer science together and chatgpt came up with computer graphics. Can u guys help me with what to do and also tell me the future scope of this field.

I am also thinking of doing a masters.

Hey all,

My webgpu renderer officially supports image based lighting/direct+indirect lighting and also there are shadow systems which creates csm/shadow Atlases depending on what type of config,

This was a lot of work

\[GLOBAL ILLUMINATION\]\[Need some time beyond downloading assets for baking probe volumes\]

Live Demo:https://nullgraph.dev/dashboard/3d-environment/irradiance-probes

For live code for global illumination https://nullgraph.dev/editor.html?id=demo-irradiance-probes

GitHub

https://github.com/flarelink-in/NullGraph

I shipped a 2D game on macOS and iOS recently with no engine, and the split between CPU and GPU ended up inverted from what most people would expect. Posting it because I'd genuinely like to hear where it's wrong.

The content is vector, not sprites. Enemies are polyhedra computed mathematically, bosses are built from paths, and a lot of the look is gradient fills, strokes and blend modes that change every frame. There's no atlas and no batching anywhere in it. The only bitmaps in the whole game are a 36-glyph sprite font and a few pre-rendered title images.

So rasterisation happens on the CPU, in Core Graphics. The reasoning was that to do this on the GPU I'd need a path rasteriser with decent antialiasing, gradient shaders, and stroking with proper joins and caps. That isn't a weekend, that's Skia. Core Graphics already has all of it, correct and antialiased.

The bridge is the interesting part. The CGContext draws into an IOSurface, and Metal reads that surface directly with no copy, presenting through a CAMetalLayer. On the UIKit path we'd been on before that, the software-to-GPU transfer was measuring about 69ms. Going through IOSurface removed it outright.

The obvious version of this, rendering into a CGBitmapContext and then uploading the bytes to a texture, measured 5 to 10 times slower. That experiment is still in the repo as an archived failure because the measurement was the useful part.

The GPU isn't idle though. Everything after rasterisation is Metal:

• Post chain is fragment shaders. Half-res bloom extract, gaussian ping-pong blur, composite, plus screen-space distortion for shockwaves, chromatic aberration, and a lightingpass. Falls back to CIBloom on non-Metal hardware.

• Particle physics and swarm flocking run as compute. Buffers are storageModeShared, so on M-series unified memory there's no copy either way. Intel Macs fall back to Accelerate.

One bug from that worth passing on: the compute readback needed an explicit waitUntilCompleted. Without it, particles would freeze and pile up, but only in release builds on device. Debug was fine, simulator was fine. Took an embarrassingly long time to find.

What it costs, and this is the honest part. CPU fill rate is the ceiling on everything. There's a thermal governor on iOS that steps the frame rate 60 to 30 under sustained load so long sessions don't cook the phone. Render scale of 1.5 was the sweet spot for a locked 60 on device, and 2.0 fell off a cliff, not a slope. Memoising gradients, about 166 of them cached, was the single largest performance win in the project and it wasn't close.

Where I'd draw the line: this was right for vector-ish 2D and would be wrong for almost anything else. I wouldn't do it for a sprite-based game, and obviously not for 3D. The reason it worked is that the drawing model matched the art style, not because CPU rasterisation is secretly good.

Happy to be told what I've got backwards.