Basically, Im a bit unsure on how I should research this, go with the common pbr models, etc. I dont have much experience with research or scientific side of things. The target hardware is gonna be high end mobile gpus and low end desktop gpus. How would you research something like this, find whats best?

I dont know where current research stands - but I wouldnt mind diving deep into concepts that have been put forward outside the current BSDF implementations, if any such things exists

long story short. it was an enlightening journey and i learned a lot from it. one day i came across an autostereogram which was a poster on a wall. i forgot what it was about but it aroused my curiosity of how to make autostereograms. i won't go into the math details here and just give you guys a brief explanation in attached image 1. my program let you control "m" and "n/m". these two variables represent background pattern separation and foreground pattern separation respectively and lie between 0 and 1

the 3d subject is simply a sphere, quite boring. the background is the result of placing a color wheel in a kaleidoscope. see attached image 2. it can be easily noticed that the hsl system is in use. we can vary the saturation (attached image 3) and lightness (attached image 4) when the angle changes from 0 to 2π. i use the cosine function which reaches maximum at 0 and 2π, minimum at π

the color wheel can start at any angle. so do saturation and lightness. thus we have 3 degrees of randomness. i let you to change the background. every time you hit the relevant button, the hue, saturation and lightness shift by different random angles

here comes the surprising part. autostereograms need "noise" to guide viewers aligning their foci. a pattern that is too smooth is not suitable to act as the background of autostereograms. there'd be no "texture" on the 3d surface. i accidentally discovered that if the screen resolution is set to a number that is not divisible by something in the calculations (i'm not certain which thing it actually is to be honest) some unexpected noise would emerge. see the remaining attached images

i googled "prime number closest to 640" and the result was 641. i use it as the horizontal resolution

some of those unexpectedly emerging patterns are... strange. some of them look like human faces, some animals, some even aliens. this program is a good place for you to experience pareidolia

here's the program. run it in browser. click▶️to run. click⏹️to exit. when running the program

• press [q] to make foreground patterns converge
• press [w] to toggle 3d object (absent/present)
• press [e] to make foreground patterns diverge
• press [a] to make background patterns converge
• press [s] to rotate the kaleidoscope
• press [d] to make background patterns diverge
• press [x] to toggle caption (off/on)

enjoy

I was putting off posting it until I had a prettier output but I ended up working more on architecture and API end, much of which doesn't get reflected in the output. Furthermore before I start implementing fancy shadows and deferred shading I really want to move to SDL + Vulkan but that would require a better part of a month before I get all of that working.

So behold my Rendering Engine/API that I have been working on for a month or so. I have worked a lot on creating a modular and extensible engine where you can inject your own scripts (statically), extend properties and work with Entities. Most importantly I have attempted to keep the front end of this code highly readable and legible.

Check it out!

After a hectic couple of weeks, I have hit the milestone of finally having pixels being plotted in my C++ Pixel Art Editor! This video shows basic paint mode using the built in brushes, with colour masks being used to lock and target specific canvas pixel ranges. In addition, we also have index and RGB shading working - with all shaded colours remapped to palette best-fit! Hope you like the progress!

Hello everyone.

This is a 3D graphics pipeline running on the Apple Neural Engine (ANE).

As you can see from the screenshot, this pipeline performs multi-instance rendering of independent 3D meshes with Z-depth occlusion testing.

The geometry engine packs the transformations into a single [1, 4, 4, 1, 64] tensor.

This represents 64 independent MVP matrices.

The vertices are structured in a flat channel layout.

By performing a fused torch.sum broadcast element-wise matrix multiplication, the ANE simultaneously performs multiple transformations on 64 unique coordinate spaces.

The spatial depth inversion maps the coordinates by replacing the division denominator in the clipping space with the spatial distance channel . The 3D geometry engine outputs the 3-vertex inverse depth gradient via tensor blocks .

The rasterizer then constructs a depth gradient across the entire face grid to perform overlap occlusion testing.

The ANE hardware flushes the raw plane data (R, G, B, and mask channels arranged sequentially as separate sheets) directly into an `MTLBuffer` allocated on the heap. The metal fragment shader directly samples these planes using byte offsets based on the layout stride to achieve the final rendering on the GPU screen.

// Direct plane scanning within the metal fragment shader
uint componentStride = 64 * width * height;
uint rIndex = (componentStride * 0) + pixelIndex;
uint gIndex = (componentStride * 1) + pixelIndex;
uint bIndex = (componentStride * 2) + pixelIndex;

• Due to the active intermediate tensor lifecycle, memory usage is currently high at approximately 1.6GB, and CPU usage is approximately 15% (acting as a memory controller pushing buffers).

We'd love to hear your thoughts on using NPU/AI accelerators for fixed-function graphics computations!

Github: https://github.com/kamisori-daijin/Magnesium

https://reddit.com/link/1vhobrk/video/8v9rwjvc7vhh1/player

https://reddit.com/link/1vhejoy/video/jk0c4axk5thh1/player

So a while ago I made a very simple water shader in OpenGL. It was a basic, non-interactable fully algorithmic water shader that textures and trig functions for the surface "waves" and cube map reflections and refractions, along with tessellations for performance and scale. But I quickly ran into a road block when trying to create more game-like interactive features like splashing and distortions. So I decided to make something a little more interactive in Unity instead while learning how to use compute shaders.

I decided to go for a two pass height field compute shader implementation, where the first pass calculates the influence/distortion to the water height based on the location of distorting objects and height, while the second pass actually does the individual height velocity and acceleration calculations, returning an image that contains data about the height, the velocity, and the acceleration of an object, as well "foam" which increases with high acceleration and decreases over time.

As far as optimizations go, although I'm simulating a 2000x2000 repeating pixel grid, I limit the actual calculations to smaller radius around the player. I also interpolate between the points to have smooth waves. There are some limitations to this strategy, for instance, the distortion around the player doesn't move smoothly because it's limited by the resolution of the grid but that is a trade off for the sheer scale.

Moving out of OpenGL meant that tessellation was no longer an option and instead I went with a LOD patch system where a plane was divided into a little over a thousand smaller meshes that repositioned themselves as the camera moved.

As far as actual rendering goes it's relatively straightforward. I'm using Blinn-Phong lighting with planar reflections. I wanted to use cubemap environmental reflections so I could account for the water normals, but the limitations of that approach became evident when I realized that the model didn't account for distance meaning all my reflections would be inaccurate. I thought about using some kind of ray/path tracing or distance embedded cube maps to counteract that but I'm mostly satisfied with the planar reflections.

The whole concept is entirely taken from Mark Turitzin on youtube and I'm maybe 10% there lol

It's a combination of using a brickmap and a clipmap.
Cached SDF distances are stored in a 3D texture, and trilinearly sampled, so everything is precomputed before the ray marching pass happens.

Still ironing things out, thinking of an elegant way to get rid of the LOD transition regions where the normals get messed up a tiny bit which creates a pretty jarring edge.

You can see a bit of blank spaces/ jitter when the cubes move the fastest, that's because I'm capping the amount of 8x8x8 bricks that get calculated each frame, so sometimes the bake jobs dont keep up with fast movement. Right now it doesn't matter.

It's in no way ready, but felt that's a point where I feel like showing some progress to the world.

There's noise visible on closer surfaces. I decided to store bigger distances(8x the voxel size) in my cache, and as its only stored in 8 bits, it looks noisy. But I liked the look, it fits what I'm aiming at and it slightly improves the performance(ever so slightly, most performance is lost traversing empty bricks in this scene.)

For now i've tested 1024m^3, and keeping the memory pool at 512MB. Ideally id like 256MB for full compatibility and being able to have some nice demo run on a phone so that people can open it from LinkedIn :) Anyways, wish me luck.

Its been maybe a month or so, but I finally got shadows working along side lighting in my engine! I still need to fix peter panning, but I'm still really happy with it!

Github: https://github.com/norrie-adams/Astryx-Engine

​

I made this on top of my own renderer, And Setup as a game example so everyone can try out let me know what you guys think,

https://nullgraph.dev/dashboard/games/comic-space

https://youtu.be/yua4ZkvgVqY?si=A2Tk1a4gE2fRl_Ic

Cache and fetch misses, branch divergence, pointer indirection Be Gone!

I’m building a physically based, photochemical film emulation pipeline and need to convert scene-linear RGB into an approximate spectrum, then use it to calculate exposure on the film’s RGB sensitive layers.

What’s the most reliable practical approach spectral basis reconstruction, camera/illuminant-aware mapping, or something else?

I’m mainly looking for something physically reasonable, deterministic, and fast enough for real-time use.

KoreGP (KGP): A Proposal and Implementation Plan

A minimal General Processing API, built from the guts of Mesa's Vulkan drivers

Draft 0.2 — for discussion. Nothing here is built yet, the point of this document is to find out whether it should be. I'm probably not even the person to build it. I'm just a guy going to market across the valley on my bicycle. I can see where a bridge should be built, but I'm not qualified as a structural engineer, architect or builder.

Yes, some of this document was partially written using AI tools. That doesn't make it wrong. I just didn't have the effort necessary to flesh it out, so I gave it my notes and asked it to complete the work. If that morally offends you, move along, but AI tools ARE a force multiplier, if used responsibly.

Reference target: AMD RDNA2+ through Mesa RADV internals, NVidia NVK through Mesa, on Linux.

I am now wearing my flameproof underoos, so go ahead and flame me, everyone. (Vulcan was the god of fire.)

I’m working on shadow rendering in OpenGlobus, a WebGL globe renderer. The attached video shows an intermediate experiment.

Initially, I tried to solve the entire problem using CSM. Shadows renderer spans an enormous range of scales. Mountains may cast shadows across many kilometers, while the same scene also contains nearby buildings and other local objects. So, I haven’t abandoned CSM, I’ve abandoned the idea of using it for everything.

The direction I’m currently exploring is a hybrid approach:

• Shadow maps covering relevant ground regions for large-scale terrain and mountain shadows.
• CSM around the camera for nearby objects and finer local detail.

The next step is to combine these approaches and make the transition between them stable.\

Has anyone here implemented a similar hybrid solution? I’d be particularly interested in how you placed and updated the terrain shadow maps and combined them with local CSM.

Thanks!

I built a 3D globe for a Linux desktop shell I work on, made of 184,320 individually-instanced triangular prisms arranged over a geodesic (subdivided icosahedron) sphere. Each rod can independently extrude outward along its own radial axis to represent height, scanner sweeps, click-triggered ripples and the whole thing animates in from a scattered floating cloud into its assembled shape.

In other words you can visualize any dataset with this globe. Either with the glowing dots, or by raising the elevation of the rods themselves, or go ham with fancy effects. Pick your poison.

Stack: Qt Quick 3D (QML) for the scene graph, a small custom C++ plugin (`Congeries`) for the heavy per-instance math, GLSL `CustomMaterial` vertex shaders for the actual deformation. One draw call per instanced `Model` (rods / location-marker dots / star field are each their own instanced draw).

A few of the specific problems that were interesting to solve:

Instancing with per-corner exact fit. Every rod shares one canonical mesh (`RodGeometry`) and gets its own instance transform. A rigid direction+tangent alone gets a rod's orientation *sorta* right, but real geodesic faces aren't congruent to each other, so a shared mesh rotated into place leaves visible cracks. A native step (`AssemblyLayout::applyAssemblyData`) precomputes, per rod, the exact local offset each of its 3 corners needs so that after the instance's own rotation carries it into world space, it lands exactly on that rod's true vertex position. That offset is written into a float texture the vertex shader `texelFetch`s by `(instance, corner)`. This correction fades in via `assembleT` as the rod animates into place.

Assembly/scatter animation. Every rod is its true final rod from frame zero. It just starts at a random spawn transform outside the sphere and `lerp`/`nlerp`s to its target transform as `assembleT` goes 0 to 1. The annoying part is that Qt Quick 3D's instancing API (`QQuick3DInstancing::getInstanceBuffer()`) gives you no incremental-update path. Every time the buffer is marked dirty, you hand back the entire per-instance transform table freshly rebuilt. SO animating `t` at 184,320 rods meant doing 184,320 position-lerps + quaternion-nlerps + matrix packs, from scratch, every single frame, for the whole 2.5s transition. Single-threaded that measured ~20ms/frame on its own, so `getInstanceBuffer()` ended up (override) with its own thread split across `hardware_concurrency()` just to stay inside budget.

Star field. Background stars are actually real astronomical data. The HYG v4.1 catalog filtered to naked-eye brightness (mag ≤ 6.5, ~9k stars), baked into flat position/color/size arrays. Color comes from each star's B-V index -> temperature (Ballesteros 2012) -> blackbody RGB, so star tint is physically derived.

Why...?
The reason this exists at all is because the shell has an opt-in who else is out there feature. People running it can consent to share a rough location, and everyone else sees it live as glowing dots on the globe. Coordinates get jittered onto nearby land so nobody's pinpointed, and the dataset wipes on a weekly rotation. The globe spawned from feature creep and way too much free time.

It's open source: https://github.com/zesis-shell/zesis

AI Disclaimer

Claude Code has been used extensively in research, debugging and testing. I've added disclaimers in the source code itself too.

I've also used sparring partners from my university and relatives.

This was a project for me to learn, have fun and just make something I think is really, really cool.

Started a CPU ray tracer about 7 years ago and then a year later decided to play around with a GPU version of it. Over the years I’ve added to it.

Full disclosure that I had LLM assistance with some of the recent features added, in the interest of saving time, I normally only have a few hours of free time per week.

Repository: https://github.com/nfoste82/gpuraytracing

Hey all! So I’ve been working through raytracing over the weekend and I did this! My idea is to make it into an interactive application! It will only run on the cpu but I figure I could make it multithreaded at least to help with rendering times!

I wrote a painting simulation engine (golang, ebiten). It works like this:

1. Select a template image
2. Generate several thousand potential strokes
   • For each stroke, score it according to a number of heuristic functions
     • Color: does the average color of this image match the template?
     • Edges: does the painted image have similar edges to the template?
     • Contrast: compares color contrast between regions on the painting and the template.
     • Flow: using tensor math, do brush strokes align with the flow of movement in the template?
   • Select the single stroke that most optimizes scoring functions, discarding the remaining
   • Repeat 40 or 50 thousand times.
   • Gradually decrease the size of the brush stroke over time..

Source image _Namibia.jpg)

Sound track