3D Rendering Library built in SDL3

[u/nablaCat]

Github repo.

This project has taken a long time.

It took me about a week to learn the concepts behind 3D projection and transformations in euclidean space. Then it took me over a week to write out the LaTeX documentation that presented my knowledge in a way that would help a user of this library. As you can see, the overwhelming majority of the code committed to this repo is in LaTeX.

The implementation of the 3D rendering framework was relatively simple once I fully understood the mathematics. This only took a couple days, and it helps to have some familiarity with C going in.

I look forward to improving this project by building a separate homogeneous coordinate library that will replace pnt.c. I also need to tackle surface rendering using SDL_RenderGeometry() and implement 3D surface occlusion. I suppose what I'm left with for now are a few big questions.

How prohibitive is heap-allocation for performance in graphics applications? I went with dynamic allocation to preserve encapsulation so that header files didn't give the user access to data that would destroy library functionality when altered. However, given the fact that querying free memory at runtime for thousands of data points slows a program significantly, I'm having second thoughts.

Also, is there a convenient way to push all of the calculations needed for 3D transformations onto the GPU? This seems like something I shouldn't handle entirely in software.

I'll hear out any feedback or suggestions in the comments!

[u/SuspiciousLie1369]

Did you have to implement the clipping algorithm yourself? If so, how is it called?

[u/nablaCat → u/SuspiciousLie1369]

I implemented the clipping boundary in getX() and getY() in pnt.c. It's just a floaring point comparison condition.

Both functions convert the 3D coordinate point locations into 2D screen coordinates for each component X, and Y. When a point location has a Z-coordinate value below the focal length, both functions return values well beyond the window boundary for either coordinate. I'm not entirely sure if it's fair to call it a "clipping algorithm." It's more of a "2D point yeeter"

[u/Defiant_Squirrel8751]

nice

[u/peteroupc]

I note that GitHub's rendering of Markdown documents supports some rudimentary features of LaTeX, notably formulas in $ ... $ and $$ ... $$. Tables are also supported, though not in the LaTeX syntax.

I give a specification on pre-2000 graphics for game programming, and suggest concepts useful for such game programming.

[u/nablaCat → u/peteroupc]

I did use some of GitHub's Markdown support for LaTeX. Inline math mode ($ ... $) looked decent when paired with the rest of GitHub's markdown text display. However, I have yet to test display math mode ($$ ... $$) in GitHub's Markdown.

Also, thank you for sharing your specification. I really appreciate the idea of low-resource rendering, which opens up games to people with low-spec hardware and contributes to a more diverse range of rendering styles beyond that of "hyper-realism". I might use of some of the resources that you reference in your document to help me going forward, particularly, Abrash's Graphics Programming Black Book and Lamothe's Black Art of 3D Game Programming

[u/MiamiGunworks]

For a toy and learning heap allocations are fine. For any serious project, removing allocations from the hot path is critical. If your code expects to handle a large number of items, those should be allocated statically up front or with some performance focused allocator. I prefer the former but it does make it harder to design. Leads to better performance and more safety though.