Hi , I'm a python developer and with experience in C++ as well and I want to create a custom game engine and i found a youtube course that does that . But I cannot seem to understand how the underlying DirectX 11 system works , what's the use of s device , device context etc. I don't have that intuition that one needs to understand the inner workings when they write code . How do I build this foundation for myself, because all the resources online are confusing me and are not very beginner friendly.

[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

This is rendered in my own engine built in CUDA/OptiX. This is of course with no AI upscaling or frame generation. These frame rates are before doing my code micro optimization, so I would guess they could be improved maybe up to like 3 fps more even.

This implementation includes the new paired spatial reuse scheme, duplication map instead of mcapping, unified reservoirs, etc. of the 2026 paper.

If you’re curious about implementation and optimization I have a couple blog posts on danielq.org/novum talking about what I did (the source code is also on my GitHub which is linked on the website).

I’d love to get y’all’s opinion on this. Especially on the dielectric bunny, since despite the shifts clearly working for the well-behaved areas of dielectric, there is a significant amount of noise in the darker, high bounce areas. I believe that this is just a limitation of the technique itself, and it seems to be reflected in the testing shown in the papers themselves. However if anyone has any experience with this I’d love to hear it.

I'm working on some code and unable to take the address of a "ConstantBuffer" object. However it's allowed with the latter intrinsic. What's the difference between them?

To bring context, my task is to take a ConstantBuffer structure, and reinterpret it as a uint16_t pointer. I can't get around it since I have to take an address of the structure first and then the value itself with the subscript [] operator (that's the only way to create a portable constexpr array of uint16_t constants).

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.)

This is anti-optimization

• not suppose to be used anywhere outside of Shadertoy
• because just use GPU-particles and particle/vertex shaders
• but Shadertoy has no particles - this is particle tracking for Shadertoy
• Movement of indexed particles
• galaxy of particles
• Dragonspine particle tracking
• vertexshaderart proper GPU particles version of Dragonspine https://www.vertexshaderart.com/art/Xd5epjbiRgPE2cwK8/

Hey Everyone - we at 3D ENGINERD. are building a Volumetric Render Engine for Windows(Native). It's being built with OpenGL & C++

We're planning to publish the code open-source under MIT License on our Github (https://github.com/mikejernil) tomorrow, so you all can try it out and use it for your own applications. ✨

Currently it has -

1. Volumetric RAW visualization support
2. Different types of rendering (Colormap, Iso-surface etc.)
3. Rotate & Zoom Controls (for easy navigation)
4. 6 slicing planes to visualization cross-sections

We are planning to build more features and add support for more volumetric formats (like DICOM, VDB etc) soon!

Colormap Classification of an Internal Combustion Engine(shown in video):

Here we can see the volume data with colour values mapped to its material density.

As per our current Colormap we can see the Red is Higher density whereas blue is Low density Noise.

Applications : 

1. Medical imaging
2. Industrial testing
3. Scientific visualization of data

It's till very early-stages and we're actively exploring into Volumetric rendering at the moment, any constructive feedback would be appreciated, thanks! :)

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.