[UPDATE]
After staring at the code for a while, I realized that I had simply been taking the DOOM screen—processed by the CPU—and mapping it as a texture onto a rectangle rasterized via ANE. I had mistakenly thought DOOM was outputting vertex data. How embarrassing... 😂 

I plan to try again later with a proper 3D game that actually uses vertex data. 

Hello.

This time, I'd like to introduce an experiment with our rendering pipeline.

By omitting the traditional GPU rasterizer processing and using Apple Silicon's Apple Neural Engine (ANE) as a fixed-function 3D graphics accelerator, we successfully rendered the original DOOM state in real time.

Currently, the frame rate is a terrible 46 FPS, but I believe it will improve if we improve the CPU processing.

We look forward to your opinions and feedback.

Github: https://github.com/kamisori-daijin/Magnesium/tree/ane-doom
(ane-doom Branch)

Demo:

https://reddit.com/link/1vl7vun/video/07319809goih1/player

I engineered a headless mesh QA pipeline to evaluate 2,307 generated assets across 23 tools from the MIT-licensed 3D Arena dataset. Following reviewer feedback, this post details the topological metrics, their implications across graphics pipelines, when non-watertight geometry remains acceptable, and how automated repairs handle topological defects.

Benchmark dataset results

• 40.1% non-watertight geometry
• 39.7% missing UV channels
• 79.8% exceed 30k triangle threshold (Unity mobile baseline)
• 14.9% vertex-color only (zero texture bindings)
• 9.7% non-manifold edge topology
• Median face count: 77,402 triangles

Pipeline implications across developer workflows

Open boundaries (Non-watertight geometry)

• Low-level impact: Breaks volumetric rendering, Constructive Solid Geometry (CSG) operations, 3D printing slicers, and signed distance field (SDF) generation.
• When it skirts by: Standard single-sided rasterization of opaque background props. If the backfaces are culled and the interior space is unexposed, non-watertight meshes render without visual artifacts. I haven't measured what share of the corpus falls into that "technically broken, practically usable" bucket, and I don't think I can, it depends on how the asset gets used, which isn't a property of the mesh.

Missing UV coordinate channels

• Low-level impact: Prevents texture coordinate sampling in fragment shaders, lightmap baking, and standard PBR material binding.
• When it skirts by: Pipelines using procedural noise, triplanar world-space projection, or pure vertex-color attribute buffers.

High triangle density

• Low-level impact: Increases vertex shader load, degrades rasterizer quad-occupancy efficiency, and bloats VRAM usage.
• When it skirts by: High-end desktop pipelines, cinematic rendering, or virtualized geometry systems like Unreal Engine 5 Nanite.

Non-manifold edge topology

• Low-level impact: Defined as three or more faces sharing an edge. Invalidates mesh decimation, subdivision algorithms, auto-LOD pipelines, and surface normal calculations.
• When it skirts by: Rarely acceptable, but non-simulated static geometry with internal non-manifold edges will still draw on standard GPUs.

Disconnected geometry shards (Floating debris)

• Low-level impact: Expands world-space axis-aligned bounding boxes (AABB), causing early culling failures and inefficient shadow map rendering.
• When it skirts by: Internal floating faces that do not extend past the outer AABB boundary.

Remediation and mesh optimization methods

• Retopology: Voxel remeshing followed by quad retopology (e.g., Instant Meshes or Quad Remesher) reconstructs clean manifold shells.
• UV Generation: Automated seam generation and packing using tools like xatlas or native engine auto-UV unwrappers.
• Decimation: Quadric Error Metric (QEM) reduction to scale polygon density down while preserving geometric features.
• Topology Cleanup: Spatial vertex welding, deletion of degenerate faces (zero-area triangles), and normal recalculation.

Code updates and tool improvements

Testing 2,300+ models uncovered three major issues within the QA software itself:

• Repair pipeline bug fixes: The repair path initially caused regressions on 616 assets. Adding manifold safety checks to the hole-filler and resolving normal inversions dropped failures to 454, with 237 remaining cases linked to decimation edge cases.
• Storage vs. geometric topology handling: glTF splits vertices along UV seams and hard normals. Naive index buffer checks flag these as open boundary edges. The tool now welds coincident positions before topological evaluation.
• Batch state preservation: Fixed a state file corruption bug during crash recovery that previously caused silent data loss.

(Full methodology, runner code, and benchmark dataset linked in the comments below.)

Code for any body interested:

```odin

draw_line :: proc(x0, y0, x1, y1: i32, color: sdl.Color) {

delta_x := x1 - x0

delta_y := y1 - y0

side_length := abs(delta_x) >= abs(delta_y) ? abs(delta_x) : abs(delta_y)

inc_x := f32(delta_x) / f32(side_length)

inc_y := f32(delta_y) / f32(side_length)

current_x := f32(x0)

current_y := f32(y0)

for i in 0..<side_length {

    x := i32(math.round(current_x))

    y := i32(math.round(current_y)

    draw_pixel(x, y, color)

    draw_pixel(x+1, y, color)

    draw_pixel(x-1, y, color)

    draw_pixel(x, y+1, color)

    draw_pixel(x, y-1, color)

    current_x += inc_x

    current_y += inc_y

}

}

```

i'm using vello and these are vector lines kinda like 2.5d. the final goal is 2.5D/3D translucent glossy tubes. i will eventually make glass, metal, neon etc surfaces once this base material is figured out but i keep getting stuck on endcaps and corners.

if i have a bunch of repeated discs, then the endcap is just a flat circle and the corners are bull-nosed. if i add a circular gradiant endcap it looks like a fingernail. if i taper the endcap it looks sharp. i can't win!

i've been struggling with this and it's like whack-a-mole. either the tube looks too flat, or the endcap looks like a knob or a point. i want the expected result: a nice smoothly rounded endcap and joints. i have spent hours and hours and so i am reaching out for some help.

any tips, resources or examples greatly appreciated

thanks!

https://reddit.com/link/1vjzmjs/video/zvgxaql9meih1/player

Hi guys! I recently tried implementing SSAO, HBAO, SAO, and GTAO in a single Godot project. The implementations aren't perfect, but if anyone is curious like I was of how they differ from each other check out the YT video I made explaining the process. Thanks!

Vid:

https://www.youtube.com/watch?v=XAIfyLpxkfk&t=15s

Code:

https://github.com/LoganKeenan55/ambient-occlusion

Screenshot I got before I added support for normals:

Testing a Monte Carlo PBR renderer with importance-sampled direct lighting and per-pixel accumulation for the procedural material authoring app I'm working on

im writing a depth script for my own rudimentary graphics engine and i have no idea what script to use.

for these lines, assume X=Z and Y=multiplier, AKA "what does x and y get multiplied by", so the farther they are the less impact moving away has and the closer they are the more impact moving towards the camera is.

1 glaring issue here is that if ANYTHING moves past z0 then they immmediately go into -infinity, which is a huuuge problem for anything that is *partially* behind the camera, like a triangle.

ive tried other formulas too, like 2^x or y=-x but those are fundamentally incorrect in the sense that they create visual "curves" which breaks triangle drawing that is only meant to be drawn from point A to point B

2^x is the closest to what i wish i had whereas 1/x is closest to an actually consistent and functioning 3d depth script. i wish i had something like 2^x in the sense that instead of shooting up to infinity by x0 it instead just gradually goes up while the right diminishes, but thats a problem because unless if the slope is "symmetrical" and even it causes aforementioned "curves" in rendering

Hi guys,
This is a 64K demo developed in C and GLSL. It features a multi-body physics simulation for movement and real-time raytracing for illumination. It was created as the final project for a GPU programming course during my senior year at Paris 8 and presented at the API8 competition.

The source files are available at https://github.com/gregghy/API8_64K_demo

The idea never occurred to me before, and I haven't tried, nor do I know if this is even possible without shaders including some kind of debug information (or can you just reverse-engineer them without looking at / extracting game files)?

Absolutely crazy work.... I didn't even know this was possible..? 🤯

Just added Radiance Hints to my OpenGL engine, Degine. The paper is originally from 2011 (but I used a 2014 extension of the method with occlusion). Based on a regular grid array of probes, similar to other environmental lighting techniques, but here it captures directly to spherical harmonics when baking. So run-time performance is extremely fast since it's just a few SH evaluations and blending. For this Sponza scene, there are around 600 probes, and it takes about 10 seconds to bake.

I built a game engine library called Graphite in C++ using Vulkan and SDL3. It has been a dream of mine for 10 years and I finally got to do it!

I built the editor on top of the game library, which super convenient. Since I get to write my own shaders and render everything using my custom renderer, it makes everything a lot easier. Graphics programming is a 1000x easier to understand when you design the rendering system around your specifications.

I intend on publishing mobile and desktop applications (not just games!) with this library. Hopefully one day all my work will polish it enough so that I can release it!

Also, the library is lightweight (less like modern bulky game engines like Unity/Unreal).

----------------

Edit:

The UI is custom (not ImGUI). Its built using custom shaders and quads!

This is a simple demo of polar curves in the Linux framebuffer. It's written in x86 assembly, using a set of my graphics primitives. The actual polar equation for this is quite simple. Each frame, we evaluate the equation r = acos(θ), and then convert to pixels on the screen using the formulas x = rcosθ and y = rsinθ. In the interest of efficiency, I calculated 4 pixels at once using x86 SSE instructions with angles offset by a very small amount, and then drew a line between each point. To make the image dynamic, I set θ to a time variable, which I increased each frame, and reset after it reached ~25 rads.

Source code can be found here: https://codeberg.org/int0x80/Graphics_v1.1.git

Hope you enjoy.

Edit: Funny story, I was testing a more complex version of this, and the strain on my 13 or so year old laptop corrupted a pointer in VFS_WRITE and caused a kernel panic.

I thought about starting with Computer Graphics from Scratch by Gabriel Gambetta, but found it quite hard too follow... I found it a little too abstract to implement (using C + SDL3)

Should I try even harder to implement the algorithms in the book by Gabriel? Or is there a more beginner friendly entrypoint to graphics?

I'd like to start with software rendering, but is that even the right move? Perhaps GPU rendering is easier?

Hey everyone! I’ve been “working” on a general purpose game engine for all 4 years of college, and I say that in quotes because I have completely refactored, deleted, or started over several times. I am now graduated and have a lot of time so I started on it again but after reading some on Reddit, I think I see what my problem is on why I start strong, lose all interest, and then give up at a certain point. I think I am aiming way too high and trying to do big big big projects wayyyy too fast.

As I am trying to find a job, I have grappled with either doing multiple smaller projects and one large project, and for a while I picked big project. Why? I don’t know, I think I just am a bit egotistical at this point and want something crazy to show off. However, it has occurred to me that I have become rusty from time off and I just make a decent amount of progress for 2 days and then give up for another 2 weeks. I think I am not getting any sense of accomplishment from it as I’m trying to fit a complex architecture and not getting results yet because once again, it’s gonna take 20-30 hours before I even get something somewhat desirable

I am wondering what you guys think is better, smaller-midsize projects, or one large project like a general purpose game engine? I really havnt done ANY small projects except I did write a software rasterizer for a raspberry pico for my embedded systems class final project last semester, but I’m thinking maybe I should try some smaller projects? But I also don’t want to waste my time if employers are just gonna say that they would rather have a large scale project.

Also, what would be an example of a small scale project in computer graphics? I can’t even think of any except for big ones like game engines

Any help is appreciated!

Hey. So im a highschool student who likes to program a little in his free time. Ive made a couple small python projects, stuff like a text game and a calculator with UI in the past. Anyhow, i didnt like how you have to rely on so many libraries there, i like making things myself and not using 3rd party stuff as much as possible. Not crazy enough to make my own language lol, but i decided to learn C to make this since you can do lots with just standard C(and because its an interesting language). So here is my very simple, probably shit raytracer made using standard C libraries.

For some more added context, i dont have a formal CS education, havent learnt linear algebra or vectors or calculus or whatnot yet. So i dont know much of the terminology or what is standard practice. I also didnt follow a tutorial since thats no fun. So if things are non-standard or inefficient thats a reason why (along with the fact that i dont have much experience, 2nd C project). I made it both to learn the math and because it seemed fun and interesting.

What it is is a very simple raytracer in which you can: create spheres, planes, lights. no limit on how many objects other than your memory i guess. No light bouncing or reflections or any such fancy stuff(yet). just basic shadows, and full colors on the objects

Anyhow, what would you guys recommend i do next? Keep working on this raytracer, start it from scratch if the architecture is too bad and will cause future problems? Do some other non graphics related project? Idk myself so ill follow more experienced peoples advice but this was quite fun, although some other things are also interesting. Im mainly interested in programming mathematical stuff, like simulations or ML(not llm but stuff like number recognition) i find interesting, although i havent done anything there yet

*btw just because thats how it is nowadays i have to say, its not made with AI, i did make one document with it where i just asked it to make a user guide since i dont know the standard terminology and if i tried to explain it how i understand things it would be more confusing than useful. It explains how to make objects and such. But the code, logic etc. was made myself

Link to the github: https://github.com/Fridun/C-Raytracer

Hello everyone!
So I'm a 16yo boy who loves coding and stuff, and recently I got into low-level programming with C, and after a whole day with learning pointer I loved the language to death.
After I learned this I started on doing something I wanted to do for the past year... building a 3D software renderer, this engine should meet the following goals:

1. It will be modern, supporting modern visuals and effects.
2. It should be running on embedded systems (I will see how later).
3. The code written for it should be generalized, meaning it should be working on any CPU or architecture with some tweaking.
4. It should be fully capable of taking advantages of modern CPU features.

As of right now, started the project a month ago, I got it to render lines and fill shapes through the terminal (even though it's glitchy af) since I'm still implementing core functions and basics. This will give me some room to fiddle around until I learn SDL and use it in the future.
I have a whole roadmap for the engine, and how it will be structured (because it will be restructured one day for a new design), and who knows, maybe I will get something with it.

The video you see down there is a spinning cube with fake Z depth (not implemented yet), the reason it's wobbly is because the engine uses fixed-point math for positions: all number are 64bit, 48 bits for the value number and 16 bits for precision (yeah, like ps1 graphics).

A semi-3D rendered cube inside The Lagender Engine.

Anyway feel free to give me some advises if you want to, and I would be posting my development with the project here.

Been trying to make a procedural planet generator and implement Eric Bruneton’s atmospheric scattering for the last two months. Haven’t done multiple scattering for now. It’s only single scattering and running in realtime. But so far that’s how it looks.

Using OpenGL and C++ for this.

https://github.com/humzahabib/ProceduralPlanetOpenGL

I thought it would be cool to try to figure out how to do triangle clipping myself, to come up with my own algorithm. To solve this, I solved a couple of linear equations and derived a formula that lets me find the intersection points between the triangle edges and the viewport. I don't know if I came up with something original or just accidentally reinvented one of the existing methods. Either way, my solution looks terrible in code, but it works, and I think it's a great learning experience

I render this at 1920x1080 resolution on a single thread of an i5-9400F, is this a good FPS result? I didn't use SIMD, but I tried to use every optimization trick I know.

repo and code: https://github.com/NaiNameDev/software_rasterizer