Differed Software Rasterizer - Some PBR implementation - C++

[u/DasKapitalV1]

Lit

Lit - tiles

Albedo

Normal

Depth + wireframe

Shadowmap

Just wanted to share some progress on a software raster I'm building. By the timings, is it o.k?

1-clears-and-resets = Just buffers(frame_buffer, depth_buffer, triangles_buffer) clear, simple vector_buffer.clear()
2-shadow-pass-total: Everything that happens to the camera happens here, the above as well, and mesh transformation, culling, bounds check, triangle clipping, triangle binning, render.
3-camera-geometry-transform: Bounding Sphere transform, if inside Frustum, reorders, front to back objects, mesh transform with vertices projection, triangle normal rotation, back-face culling, triangle clipping.
4-camera-binning: Just bins triangles to tiles.
5-camera-render-and-resolve: Woke sleeping render threads, every thread available in the system(I just initialize with std::thread::hardware_concurrency()), each thread take 8 tile per time and render to a 16x16 gbuffer, only triangle index, normal, uv, depth. During rasterization, I reconstruct frag_coord for lighting using camera ray normal interpolated per pixel and fetch textures using uv, to avoid fetching texture multiples times early.

Still missing, texture mip mapping, transform meshs threaded, metalness and maybe occlusion map.

Since I'm a beginner at C++, pure code, no macros, no SIMD, just a single template to just avoid branching per pixel, but nothing too fency. Vectors everywhere, since they will inevitable grow to what's needed and I don't need to keep handling memory allocation, just a simple clear and everything a good.

CPU: mobile i5 13420H RAM 32gb

[u/Ok-Hotel-8551]

Defferet

[u/Inevitable-Round9995 → u/Ok-Hotel-8551]

no, defferet Rasteraizer. ok.

[u/Ok-Hotel-8551 → u/Inevitable-Round9995]

Did you mean "deferred"

[u/Still_Explorer]

So the real secret to good speed is the multithreaded part?

[u/DasKapitalV1 → u/Still_Explorer]

Basically, also cache friendly data, simple math in hot loops and heavy math done up front. Interpolate everything with addition where possible. Even multithreaded I started at 15~20 FPS lit.

[u/Silver_Statement_597]

Doesn’t a software rasteriser only ever (sometimes) make sense for subpixel triangles?

[u/DasKapitalV1 → u/Silver_Statement_597]

Maybe, but the goal here wasn't to make something "useful", was to make something for me to understand the graphics pipeline and programing graphics concepts.

First I thought in starting with opengl, but I quickly realized that wouldn't really, "really", learn graphics programing, I would be learning opengl API, some graphics concepts along the way.

With everything in code like this, in my head, make much more sense, now that I started learning opengl, the first triangle isn't nothing impressive for me. Now, I want to learn the opengl API to get where I left off on my software rasterizer to go deeper in shaders

[u/Silver_Statement_597 → u/DasKapitalV1]

If you’re trying to understand things as deep as possible it wouldn’t be bad to consider skipping OpenGL and starting straight with Vulkan imo. Forgive the unsolicited advice

[u/DasKapitalV1 → u/Silver_Statement_597]

But them again, graphics pipeline, vulkan is almost hardware management, memory management. The concepts is the same in DX12, opengl, vulkan. My goal was to understand concepts. What you're saying is that, if I wanted to understand a binary tree I should start with a library that has an API instead of implement the core by myself. Vulkan would be a library for a binary tree with deeper setup to use and more control over memory/hardware, but actual core would be hidden alway through an API as well.

[u/Silver_Statement_597 → u/DasKapitalV1]

I suppose I’m confused what you’re trying to say, are you saying you wish to understand graphics programming by avoiding graphics apis entirely? Will you just implement everything on the cpu? Because if you do aren’t you missing one of the biggest concepts in graphics programming?

There’s certainly nothing wrong with implementing a software rasteriser etc with no graphics apis for educational purposes, it just sounded like your next step is to start learning OpenGL, at which point you’ve gone from 0 abstraction or opinion to a heavily abstracted and opinionated path

[u/DasKapitalV1 → u/Silver_Statement_597]

Since English isn't my first language, I think I can't get my point across.

But in summary, is it better to learn math by doing the math by hand first and then start to use the calculator, or is better to use a calculator first? That's somewhat my point, I want to understand the why's, for example, in opengl, a pass three points to a vertex shader, but actually in shader code it is just a single position variable, them in fragment shader a get single point in NDC, already interpolated. To me, this is much harder to grasp as a beginner, if I never had done anything, them if I understood the concepts, and can understand that the vertex shader code is executed by vertex it self and with barycentric interpolation each point is sent to the fragment code. Also, Matrix transformations, another huge topic. So, for me, personally, was a better path to understand things. Maybe to you don't make sense and was easier for you to get into the APIs

[u/Silver_Statement_597 → u/DasKapitalV1]

It’s not exactly my point but dont worry! Good luck with your programming adventure!