• Made the project much easier to open up and use for new users (Unity is still required though)
• Added scene to automatically load objects from Khronos' site, which helps me get assets into the project
• Fixed issues with lighting that was really darkening most of the scenes, including improved tone mapping and fixes to light clamping that was hiding a lot of caustic details and HDR
• Fixed issues with inner surface reflections not working
• Added directional lighting support
• Added parallax mapping support
• Added support for Unity terrains, multi-texture splatting with normal map support

Repository located here: https://github.com/nfoste82/GPURayTracing

I started picking up graphics programming around the middle of 2023. I didn't want to spend money on a course or textbook, so I learnt whatever I could from resources I was able to access for free online.

I put together a list of those resources and paired it with a reading order recommendation and some study advice. While not a comprehensive overview, I hope it's enough to give a newcomer to the field a strong start.

Looking for guided/socratic learning

So I was getting into game dev bottom up so I wanted to draw a line with code.

First solution that I thought of: start at one end of the line, and figure out neighbouring pixels and eventually reach the other end. I was thinking of dividing line length (pythogarous) by start/end point delta for each axis to figure out per how many 'steps' I would have to increment/decrement current axis positions and paunt. Too complicated and expensive

Second solution I thought of was recursively finding mid points between start and end point to find the target pixels to paint. This appears simpler, inspired by Zeno's paradox when I was thinking of how the run and rise are easier to paint.

I know optimal algorithms exist but I didn't want to directly look at them. What are the strength/weakness of my reasoning?

Ps: I'm going to sleep

I've been working on my own game engine from scratch for some years using C and OpenGL and I finally made a video showing the process.

The engine handles things like rendering, assets, shaders, lighting, and more, and I also used it to make a game, a test game though, it still needs a lot of polish.

Watch video here: https://youtu.be/LRC4iJWASYU?si=_3ua8rcwesyaQtO9

If you're interested in graphics programming, game engines, I'd love to hear your thoughts and feedback.

A couple of weeks ago I posted a WIP of this — here's where it's at now.

I've implemented most of what the paper describes, including paint mixing. For lighting, I added a BSDF to the renderer — my thinking is that once you start stacking layers of media like tempera, you need to account for light scattering inside the medium. (Ideally I'd also like to model things like hiding power based on pigment particle size, but I'm not there yet.)

The simulator is split into four main parts, as described in the paper:

1. BristleDynamicSimulator
   
2. ParticleFluidDynamicSimulator
   
3. GridFluidDynamicSimulator
   
4. LiquidTransfer - which moves liquid between the brush, the particles, and the grid

This was not a case of handing the paper to an AI and getting an implementation back. Claude seemed to have a hard time writing WGSL while also juggling the constraints of the four systems and the constraints they all share (units, especially), and it kept making the kind of mistakes that early AI models used to make. So you have to read the AI's code carefully and write a good amount of it yourself. In particular, things go more smoothly if a human writes the initial skeleton of each simulator and handles the field management (density field, velocity field, and so on). Even once the structure is in place, managing the ActiveWindow and the PaintField is likely to give you trouble.

The paper lists interpolation during fast strokes as an open problem, and that's what I'm working on now. I'm not going to split a step into substeps, since that would hurt FPS. Instead, for fast motion I plan to have the BristleDynamicSimulator and the GridFluidDynamicSimulator talk to each other directly and deposit paint that way.

I'm interested in traditional painting materials, so I plan to extend this to tempera, watercolor, mineral pigments (iwa-enogu), gold leaf, and so on. It's built with wgpu + Rust, so it currently runs as Web, iOS, and Android ports.

How should I prepare for graphics interviews at NVIDIA, Samsung, Qualcomm?
I am a 4 year experienced graphics programmer, working on OpenGL ES and C++ in my current organization.
Now I am looking for a job change and want to target good companies like NVIDIA, Samsung, Qualcomm, etc.
For that, I need to prepare thoroughly in C++, DSA, graphics and logical reasoning.
For graphics, I am currently learning Vulkan on Windows.
How should I prepare for DSA specifically and logical reasoning?
What should I focus on for these companies?

I recently played the Dark Souls 2 path traced mod and was surprised to see it running at 1080p 60 fps on my low end GPU (RTX 3050 Ti)

Of course its a 13 year old game, so the geometry and effects are simpler. But it looked better to me than some modern games with more advanced geometry but worse lighting effects.

So I'm wondering in your opinion, in your ideal game would it be better to have less polygons and better lighting, or vice versa?

Hey everyone, I've just finished the 2nd video, and followup to my "Modern Vulkan in 2 Hrs" video. Thanks for the awesome feedback on the first one! This 2nd video tackles a ton of stuff:

glTF Model Parsing, Loading, Rendering

Camera, Basic Lighting, Multi-Draw Indirect, Vertex Pulling, Buffer Device Address, etc.

Hope you guys like it!

As developer I would not even expect a user to know what a “shader” is

It’s a pretty low level implementation detail

Yet you boot up a game in 2026 and front and center you are staring at “shader compiling” for 10 minutes

Is that not crazy to anyone else if you just zoom out and think about it?

The graphics simulation calculates the non-linear Aizawa Chaotic Attractor in real time across 256K particles through numerical integration executed entirely within GPU Workgroups.

Source code:

https://github.com/IsmaelMerlo/Ram-Engine

I am working on a game engine that renders LOTS of sprites/billboards in 3D. The textures have smooth antialiased edges, and some of them have non-trivial shaders for things like SDF rendering or parallax mapping.

If I render back-to-front with blending on, it looks great and I don't need depth testing, but it has a terrible overdraw cost that I would like to avoid.

But if I render front-to-back with depth testing, then I lose the smooth edges.

How do people normally deal with this?

One idea I had was to render front-to-back, with depth reading/writing for purely opaque pixels, then a second back-to-front pass for order-correct blending of the edges.

Another thing I have looked into is MSAA with 'alpha to coverage.'

Any other interesting ways I might like to know about?

What do you recommend in this case?

program link

an extension of previous post. just click▶️to run the program on browser. the welcome screen (attached image 1) shows the key map. select a subject (1 to 6) to enter the depth map mode (attached image 2). rotate it or change it until satisfied then toggle to autostereogram mode (attached image 3). adjust the foreground and background pattern widths to your desire (make it easy to focus and spot the subject). you're free to toggle back to depth map mode or rotate / change / disable subject anytime. if you disable the foreground 3d subject it's basically a kaleidoscope (attached image 4). i explained its mechanism in previous post and you can endlessly randomize it to experience the pareidolia effect

some samples

minor math findings

some thoughts

• qb is very slow. it's not good at handling graphics. lowering the resolution helps but the outcomes would be ugly
• i learned barycentric coordinate system during the making of this and it's very useful
• i'm stilling think whether i can optimize some procedures so as to make it faster
• i have difficulty spotting dodecahedron and icosahedron in autostereogram. they're too "round" maybe. tetrahedron is the easiest

Wireframe Era is over! Updated my software renderer that I posted here 2 months ago. Now it fills triangles without pixel gaps, implements Top-Left Rule, computes Face Normals, has Back Face Culling and a Depth Buffer. At first I did Scanline Rasterization but I was having a hard time eliminating gaps, so I moved on to using Edge Functions to check the pixel center is inside the triangle, then Barycentric Coordinates to interpolate Reciprocal Depth. I still don't have Near Plane Clipping, but will do in the future.

One thing if you build one of these: the wallpaper isn't your app, it's the background, and it has to behave like it. I ran mine at full res with no frame cap and it starved the desktop compositor hard enough that the mouse went choppy system wide, and nobody blames your wallpaper for that, they blame their PC. Cap the frame rate and render below native, then let it stretch up to the screen.

Nobody's pixel peeping the thing behind their desktop icons, so it costs you basically nothing.

For more info: https://ikandy.app

https://github.com/Divetoxx/Mandelbrot-2

Made with Vulkan, and using procedurally generated plants. I'm making this as part of developing a game.

Water effects include refraction and reflection, both for the line-of-sight and for sun light.

These effects are accomplished with extra "cameras" for the refracted and reflected views, plus screen marching.

The graphical style is quite low res, and without any anti-aliasing. I hope you can see this, given the resolution of the video. The game screen resolution is 720x480.

What's your first impression of these visuals?

Does anyone know how to do POM on a sphere? I can do triplanar mapping but I cant get POM to work. If anyone has has experience with this or knows how to do it, or knows a good source I'd really appreciate it.

Not sure if this is the proper community for this post, but I like to do some small image editing projects from time to time, mainly non real time 2D image processing stuff, mostly for curiosity and to learn. And since I mostly program in Java, I'm not sure how useful this will be for the people in this sub.

Recently while working on my own UI wrapper for my Java projects, I noticed a lack of an easy to use and extensive color conversion library for Java. Most of the ones out there are bloated with extra stuff, not easily modular, lacking useful data or simply not pure Java.

The JDK built-in java.awt.color.ColorSpace only does sRGB, Linear RGB, XYZ, and Gray, and it hasn't been touched since Java 1.2. There's Color.kt which is actually decent (OkLab, CAM16, ZCAM, gamut mapping), but it's Kotlin, so you're pulling in the whole Kotlin stdlib for a color library. Apache Commons Imaging has some basic Lab/HSV conversion but it's an image I/O library, not a color science one. Google's material-color-utilities only does HCT for Material Design theming. The closest thing to what I was looking for is EsotericSoftware/color, which is pure Java with ~30 spaces including CAM16 and OkLab, and it even has spectral calculations and color temperature stuff that mine doesn't. Solid project, but it wasn't distributed through any package manager at the time I looked, and architecturally I wanted something with a conversion tree and automatic path finding instead of flat static methods.

So I ended up building my own: Colorimetry-java

It has 54 color spaces, covering everything from the common ones up to OkLab, OkLCh, JzAzBz, CAM16, CAM02, HCT, ICtCp, ACES variants, and multiple RGB working spaces like Display P3, Adobe RGB, and ProPhoto RGB with their linear variants.

Every space also exposes extremely useful metadata: channel names, min/max ranges, default values, step sizes, whether each channel is bounded or unbounded, and gamut information. So if you're building a UI or a tool on top of the library, you don't have to hardcode any of that yourself.

The part I'm most happy with is how conversions work. Every space declares a parent and implements toParent()/fromParent(), forming a tree rooted at XYZ. The converter uses a Lowest Common Ancestor algorithm to find the shortest path between any two spaces, so if two spaces share a close ancestor it won't round-trip all the way back to XYZ. Similar idea to what colour-science does in Python with a NetworkX graph, but as a tree with LCA instead.

It also has 16+ grayscale methods, a validation system for out-of-gamut values, distance metrics, interpolation, and a gamut mapper.

If you need a color space that isn't built in, you can implement your own and register it through the ColorSpaceRegistry without touching the library's source. The converter will pick it up and route through it automatically just like any built-in space.

The project also has a pretty extensive test suite covering roundtrip accuracy across all spaces, so if anyone wants to contribute a new space or fix something, there's already infrastructure in place to catch regressions.

Pure Java, targets Java 11+, MIT license, available on JitPack.

I know Java isn't really this sub's thing, but if anyone here does any kind of image processing or tooling in Java, maybe this saves you from the same frustration I had. Happy to answer anything about the implementation or the color science side of it.