[redgpu]

Hello, world! :)

My name is Constantine Tarasenkov, I'm 33 years old, slightly more than 10 years ago I was a 3D character rigger and visual effects artist for a couple of movies (my dusty imdb page), and now I'm a hobby low level C graphics and tools programmer for video games.

Before the full introduction below, a few examples of video game-oriented 3D graphics programming I did at different points in time:

My latest real time ray tracing 3D engine running on a 160 watts RTX 2060 video card, based on some Nvidia tech currently featured in Portal RTX and Half-Life 2 RTX games:





3D rigging and animations (at 3:50) in my other, simple rasterizer-based 3D engine called Game Script which can recompile its C++ code on the fly at runtime with 'Rerun' button, the whole game code is one file edited within the app itself:



Simple 3D soft shadows and a 3D gizmo programmed in engine:


Other videos can be seen in this playlist, I also ported the engine to Android and Xbox One, it can edit and rerun its code at runtime on Android and Xbox One too, which is bananas if you ask me. :)

Here I program an app in C++ from scratch that draws a 3D scene called Sponza in both Vulkan and DirectX 12 GPU APIs using my single file library called REDGPU API that abstracted these two GPU APIs into one back in 2019:



Full introduction:

I think I never introduced myself anywhere on the Internet, I guess I was known in very very small circles of hobby C and minimal C++ programmers as the first guy to share on Github a public domain, reusable, single-file only, generic and engine-agnostic quaternion-based first person flying 3D camera back in 2016 (my Github profile from back in the day, and an archive copy of my camera code), you'd think this is not a big deal, but the context was very important: back then, Github was mostly filled with academic students and programmers that most of the time didn't care about making their code reusable or single file, instead of going quaternion route they often used transformation matrices which are prone to axis skewing, and coming from academic not gaming field 3D cameras were mostly programmed with 3Ds Max or Maya-like orbit controls, while mine was the first to really double down on using the familiar to any gamer WASD controls.

I then was featured on Hacker News for my 3D graphics library called glFast that back in 2016 tried to be explicit about GPU programming when Vulkan and DirectX 12 were not available yet, an archive copy: https://github.com/nlguillemot/glFast

I was also the creator and maintainer of CMake build system for a C++ framework that sometimes was used to program video games back in the day called openFrameworks (for example, William Chyr wrote his initial prototypes of Manifold Garden in openFrameworks before switching to Unity).

Back then I also programmed 3D software rasterizers every day for 2 weeks, inspired by Mike Acton's training of writing and deleting all the code to not be emotionally attached to it. :)

I also at some point saw a video on YouTube that showed that Counter Strike Source's stairs were still buggy, so I wrote my own reliable 3D collision detection algorithm in a day that didn't have Valve's problem, which was cool. :) I still invent completely new algorithms that are not based on anything to this day, here's the latest one for my pet programming language that turns math expressions into assembly instructions:



Later, in 2019, I started to research and program in low level GPU APIs like Mantle, Vulkan, DirectX 12 and Switch NVN, while as side projects creating separate standalone gamedev-related applications such as Tiny Level Editor 3D, which is a very simple engine-agnostic 3D level editor: https://procedural.itch.io/tinyleveleditor3d





Currently I do various stuff, but mostly maintaining and adding new features to all my C and C++ code to stay up to date, and researching real time ray tracing on Nvidia RTX GPUs and latest AMD and Intel GPUs. I'm deeply familiar with 3D vector algebra, low level computer graphics, C and modern GPU programming, so my area of interest always gravitates toward these topics. I don't know if you can feel through this text, but I'm very passionate about 3D graphics and gamedev tech. :D I like to write code that runs *fast*!

[Jack]

Yo this is wild! Excellent stuff!

I know absolutely nothing of rendering outside of the basics. I drew a triangle once a long time ago lmaoooo. It's something I've been wanting to dive into further but keep getting sidetracked.

[redgpu]

Yo this is wild! Excellent stuff!

I know absolutely nothing of rendering outside of the basics. I drew a triangle once a long time ago lmaoooo. It's something I've been wanting to dive into further but keep getting sidetracked.

I know nothing about rendering outside of the basics either. I know how to rasterize a triangle and I know how to intersect a ray against a triangle (with accelerating structures and without them), and how to get a uv coordinate from a sample to lookup a texture pixel and that's it. Everything else is always added on top in case you want something more sophisticated (we always do), but the reality is: 3D graphics is, I like to quote Chris Hecker here, "heartbreakingly" beautiful in how simple it is. :) I've played Half-Life 1 a few months ago on my Android phone while I was on the road, and it still holds up, dispite lacking every modern graphics feature you can image that supposedly sales a game, once you have texture mapped triangles and a 3D camera, you did it.



If triangles look too flat unshaded, or if runtime shading doesn't look right, you can always bake the lighting values to textures in, say, Blender, like I did here in the video below (can skip to 25:00 to see the final shaded look), and the job is done again, the eyes start to perceive triangles as a real world again. It's truly beautiful how minimal you can go to make an interactive 3D world you can at the very least explore spatially. :)

[Jack]

This is excellent info. I never really dove into any of this so maybe I can actually give it a shot I always thought to was too dumb for most of this stuff lmao. You explain it well. Not making my own engine but I can dive into rendering to learn more for sure.

[redgpu]

This is excellent info. I never really dove into any of this so maybe I can actually give it a shot I always thought to was too dumb for most of this stuff lmao. You explain it well. Not making my own engine but I can dive into rendering to learn more for sure.

What's weird is that the lowest levels of computer graphics are somehow mostly kept in secret on the Internet, I can only remember looking up 'scratchapixel' tutorial on perspective projection years ago and that was basically all I could find, I don't know what info people use nowadays but I bet it will be already too complicated for what it needs to be and filled with nonsensical 4x4 matrices that shouldn't be taught anyway because for a rasterizer you can project camera and transform objects with separate projection, scale, rotation and translation math and gain better understanding than just "use this magic matrix that is mostly filled with zeroes and multiply it by this other matrix you was handed which you don't know how it works". Even starting with a GPU API like OpenGL or Vulkan or whatever teaches more about how a set of current GPU hardware works and not how a graphics renderer is structured or can be structured and how it actually works in math and code (because code is often obscured behind giant and mostly closed source GPU drivers).

If you think what I wrote above is a micro rant -- it's because it is, if I wouldn't rant constantly about computer graphics, I wouldn't be a programmer today, I'd be lost and frustrated like I was for a long time decades ago before actually understanding how stuff actually works in reality for real. 😄

[Jack]

I know very little about this sort of thing but I'm interested in diving in. Not sure where to start it's been years since i drew on screen from 0 or not using some sort of toolkit to aid me so it will be fun. I also had planned on learning some old stuff like 6502 because I think that would be fun to perhaps make a rom for NES eventually. Nothing crazy but I've always been interested in learning how stuff worked back in the day.

Everything is a lot more accessible nowadays but finding the right resources may be like a needle in a haystack but I will be keeping your thoughts in mind on overcomplication. I'm generally pretty decent at figuring out what is/isn't necessary and gutting so we will see how i do.

Probably will use Clang and OpenGL since OGL is more beginner-friendly.

[Jack]

Added to the main site https://industrydevs.com/constantine-tarasenkov/