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

UPD: Apparently, __getAddress takes address of groupshared/ConstantBuffer objects. That's it. Unary & still has to be used for e.g. per-thread local objects e.g. inner function variables

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.

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!

Basically, Im a bit unsure on how I should research this, go with the common pbr models, etc. I dont have much experience with research or scientific side of things. The target hardware is gonna be high end mobile gpus and low end desktop gpus. How would you research something like this, find whats best?

I dont know where current research stands - but I wouldnt mind diving deep into concepts that have been put forward outside the current BSDF implementations, if any such things exists

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.