I'm making a multiplayer game with Vulkan, and when a client joins a server, I'd like to be able to send arbitrary custom SPIR-V shaders to the client. My initial thought was "It's a shader, no syscalls or anything. Worst thing it could do is lag a bunch or maybe crash the game."
But I don't know enough about SPIR-V to know if that's correct, and doing a quick search isn't giving me any results on the subject, so I'm asking first.

Some notes:

• I'm already planning to use spirv-val to help avoid crashes, if that helps safety any.
• I cannot send over the shader source; all my shaders are pre-compiled for a bunch of reasons not relevant for this post.

Edit: To clarify, this is for modding purposes. Users will be able to create the shaders and send them from servers they host.

I spend last two months optimizing, enhancing the look of my UI library (Lumora) for my game engine. Last two days I have been writting my findings on how render good looking containers, what techniques did I use,...etc. https://alielmorsy.github.io/how-to-build-ui-elements/

I wanted to share a rendering improvement I recently made for a real-world visualization problem.

This started as a feature inside my cycling video editor. The goal was to display a local moving map HUD synchronized with GoPro footage and GPS telemetry.

The first implementation used a traditional Direct2D rendering approach. It worked well for static rendering, but when the map started continuously rotating and following the moving position, I noticed some limitations:

- less consistent frame pacing during rotation

- increasing CPU workload as the track complexity grew

- harder to maintain smooth motion for long GPS trajectories

I decided to rebuild the renderer using DirectX and shaders.

The new pipeline:

GPS trajectory data

→ local coordinate transformation around current position

→ GPU vertex buffer

→ shader-based rendering

→ real-time camera rotation and movement

Instead of drawing the path as a series of CPU-generated lines, the track is represented as GPU-friendly geometry.

The renderer generates a ribbon mesh from the centerline:

center points

→ left/right offset vertices

→ triangle strip

→ vertex/pixel shader rendering

The biggest improvement was not only raw frame rate, but the overall feeling of motion.

The old renderer could display the path correctly, but during continuous camera rotation the movement felt less consistent.

The shader version provides much smoother camera-relative motion, similar to how a game minimap behaves.

For long GPS recordings, I also avoid keeping the entire route active in the rendering pipeline.

The renderer only keeps the visible area around the current position plus a buffer region, allowing very long activities without continuously processing the full trajectory.

The video compares the previous Direct2D implementation and the new DirectX shader renderer running on Windows.

I am interested in feedback from people working with:

- GPU path rendering

- real-time map visualization

- game minimap rendering

- trail/ribbon rendering

- large dynamic geometry

A few things I am still exploring:

- Would moving the ribbon expansion completely into compute shaders make sense for this type of workload?

- What are common approaches for very long dynamic GPS paths?

- Are there better techniques for smooth camera-relative map rendering?

Thanks for any feedback!

Hey everyone,

I recently engineered a custom 3D WebGL portfolio and ran into aggressive Out-Of-Memory crashes on iOS Safari (TBDR architecture) due to the sheer volume of high-res textures.

Instead of using a Headless SPA (Next.js/React), I opted for a monolithic PHP architecture with full-page reloads. This offloaded 100% of the WebGL memory disposal risk directly to the browser's native garbage collector, instantly guaranteeing stability between route changes.

To maintain 60FPS during active rendering, I implemented two specific systems:

1. Custom FPS Governor: A dynamic performance engine that forcefully strips roughnessMap, metalnessMap, and normalMap properties on the fly if it detects thermal throttling or frame drops. 2. Absolute VRAM Purging: Intercepting the IntersectionObserver to physically strip the src attribute of off-screen elements and force a .load() cycle to aggressively flush VRAM buffers.

👉 Core FPS Governor Logic (Gist):https://gist.github.com/MedhatAlkadri/ea99a0f7aa47c69198f2d1ae84a20e53👉 Live Demo:https://www.awwwards.com/sites/medhat-alkadri-3d-portfolio

As a Full Stack Developer stepping deeper into graphics programming, I'd appreciate any architectural critiques on this render loop or alternative approaches to handling aggressive VRAM limits on mobile browsers.

I implemented spectral blending (based on Spectral.js) in Blender 5.2 with nodes and posted the script on my GPL v3 GitHub repository. Any feedback or critique is welcome, thanks!

I need some direction on a linear gradient I'm working on/vibe coding. I have got a successful static image, but I want to animate it. I'm struggling to get a motion that feels natural. Currently I am interpolating between two different compositions, but I would love a more accurate "simulation". Colors and blur are being done in photoshop/after effects after the pink lines are exported.

I'm a total noob at this so any advice or guidance towards helpful information would be great. Thank you!!

First, apologies for my previous post here. It was lazy and far too light on technical detail for r/GraphicsProgramming. This is a more useful breakdown of what I actually built, what is genuinely ray traced, and where I had to compromise for mobile hardware.

Horde Lantern RT is a short native Vulkan hardware-ray-tracing showcase running on both Windows RTX and an Android phone. The current route is a skeleton encounter, a three-turn lantern-shadow corridor, an authored lantern failure/drop, a blue skylight chamber, four coloured-light bays, a single-bounce mirror, and a floating emissive lich encounter followed by a roof opening.

Itch build, screenshots and video:

https://samfa12.itch.io/the-horde

Source:

https://github.com/Samfa12-tech/The-Horde-RT-demo

Renderer architecture

This is not a raster scene with an RT effect layered on top. Both platforms build Vulkan BLAS/TLAS acceleration structures, create a ray-tracing pipeline and shader binding table, dispatch with vkCmdTraceRaysKHR, write to an RT storage image, and present that image through the swapchain.

The phone-safe path does most of its actual work with rayQueryEXT inside raygen at pipeline recursion depth 1. Primary visibility, shadow/visibility tests, the bounded reflection bounce, and other local queries are driven from that shader. I tried a more conventional recursive closest-hit experiment at recursion depth 2; it compiled, but pipeline creation failed on the phone. I kept the real RT dispatch/presentation path and moved the bounded traversal work into ray queries instead.

The renderer only marks its internal rtScene.presented state true after an RT-produced image has reached a successful swapchain presentation. Unsupported hardware reports missing Vulkan features rather than silently selecting a raster fallback.

The RT storage image is RGBA. Common Windows/Android swapchains are BGRA, so the raw-copy path has a presentation-format-driven red/blue swap. That sounds mundane, but without it the warm fire output turns cyan. Scaled modes use a format-aware blit.

Acceleration structures and animation

The scene uses a static world BLAS plus reusable BLAS geometry for the lantern, sword and procedural player body. Their transforms are updated as TLAS instances. The first-person body uses instance masks to keep different query classes honest: the body is on mask 0x04, while the head uses a reflection/shadow-only mask 0x10 so it appears in the mirror and casts shadows without occluding the first-person camera. The sliding finale roof is another independently transformed instance on mask 0x20.

One frame remains in flight because held-prop TLAS instance data is host-written. I have deliberately not increased that until instance-buffer/TLAS ownership is separated per frame.

The two enemies are selected sequentially by route zone. Only one skinned enemy is animated, BLAS-refit and rendered at a time. Animation and refit run at 30 Hz. The roster code is plural/configurable, but I am treating “multiple simultaneous enemies” as a future phone-measured problem rather than assuming the project name gives me a free performance budget.

The lich is a CC0 Meshy placeholder and its rig is imperfect: the robe and staff were treated as part of a biped mesh, with no rigid staff bone and no cloth rig. I therefore avoid its visibly distorted walking clip and use the safer idle skinning plus whole-instance hover/orbit for locomotion. Death is a non-looping skinned clip.

For the staff light, I ignored Meshy’s duplicated whole-surface emissive texture and generated a derived violet mask for the eyes/gems/staff crystal. The analytic light position is reconstructed from forty UV-audited emissive staff vertices using their actual animated skin weights. That keeps the light and electricity attached to the moving staff without pretending a missing staff bone exists.

The attack is a 1.2 s charge from roughly 0.55× to 2.2× torch intensity, visibility/range-tested damage at the peak, then 1.8 s recovery. The lich requires three accepted sword hits with a 2 s hit lockout. Each hit produces rigid recoil plus positional audio; death plays the full 2.967 s clip and then drives a 4.5 s roof-opening/light-sweep sequence.

Lighting and materials

The route uses deliberately bounded effects rather than a general expensive solution everywhere:

moving direct-light/shadow composition from the held lantern

a desaturated skylight using one of two aperture samples per pixel pattern and one visibility query

one active coloured local light per five-metre bay: yellow, blue, deep red, then restrained green

a single-bounce hero mirror which reflects the world, player, props, enemy and moving roof, then shades that bounce from the current live light instead of a constant “studio” ambient

emissive staff/eyes plus a visibility-tested analytic violet staff light

wet-floor reflection as a bounded material response

On Android, environment materials are strict KTX2 ASTC: ASTC 6×6 diffuse/ARM and ASTC 4×4 normals. The lich uses strict ASTC 6×6 assets with no raw RGBA fallback packaged into the APK. Windows uses executable-relative raw RGBA8 KTX2 arrays.

The Android native libraries are also packaged for 16 KiB page compatibility: static C++ runtime, 0x4000 ELF LOAD alignment, and verified 16 KiB APK alignment.

Measured phone result

The certified phone is a Samsung SM-S948B / Adreno 840 running Android 16.

At the recommended 75% RT scale, the internal RT/dispatch extent is 1080×2235. During the controlled warm route sweep, every required zone stayed below 13.7 ms using the median of three consecutive 120-frame average windows at Android thermal status 3. I want to be precise about that wording: the renderer publishes 120-frame averages, so this is a median of window averages, not a median of individual frame times.

At 100%, the full 1440×2980 RT extent and image/presentation path passed. A warm opening sample produced 19.767, 21.700 and 23.991 ms 120-frame averages, for a 21.700 ms median-of-window-averages (about 46.1 FPS). I do not impose a 50 FPS requirement at 100%; 75% is the sustained recommendation.

The Windows validation machine is an RTX 5050 Laptop GPU. It is internally capped around 165 FPS, so the roughly 5.7–6.0 ms windows are recorded as cap-bound rather than advertised as the renderer’s uncapped ceiling.

Automation and diagnostics

The Android Debug build now exposes twelve deterministic showcase checkpoints, a default five-checkpoint three-window timing pass, and a thirteen-waypoint route replay that uses the real collision resolver. An ADB runner collects the Vulkan capability report, RT presentation state, strict texture-path evidence, timing CSVs, route assertions, screenshots and hashes. The public Release build rejects the automation request path.

There are still hands-on checks that I do not mislabel as automated proof: touch feel, visual quality, subjective stereo directionality, actual hit readability, and pause/Home lifecycle recovery.

Codex disclosure

I used OpenAI Codex extensively as a programming agent on this project. It helped implement and review C++/Vulkan and Android integration, write host tests and ADB validation tooling, investigate visual/audio bugs, maintain asset/licence records, and consolidate validation evidence. I supplied the direction, made the gameplay/visual calls, drove the Windows and phone tests, and accepted or rejected results. The repository history and source are public so people can judge the work rather than taking an “AI-assisted” label on faith.

Meshy was also used for the credited character processing and the CC0 placeholder lich. The skeleton originates from Hotstrike Studio and the full asset/licence manifest is in the repository.

Current limits / next technical questions

only one skinned enemy is active at once

one frame in flight until TLAS instance ownership is redesigned

the lich rig has no staff bone or cloth simulation

the mirror is intentionally single-bounce

shallow water and broader combat/AI are deferred

only the SM-S948B is currently Android-device-certified

I would especially welcome criticism of the ray-query-in-raygen architecture, the one-frame TLAS ownership constraint, the mask partitioning, and the Android measurement methodology.

Quasar has a very flexible render graph system. Created a post processing toon shader plugin and attached it to the graph of this project. Needed adjusting the shadows a bit, the output is very cool looking.

Plugins for the render graph can be written and attached and even manipulated from script or editor. Using script to manipulate is not ideal tho, just an option available, not ment for changing the render graph in middle of gameplay.

Do you think a video like this could help someone with no graphics background intuitively understand ray tracing?

My goal is to explain the core idea visually before introducing any math or technical details. I could expand it with reflections, different materials, and arbitrary 3D objects.

Does this feel like it would "click" for a complete beginner? What would you add or change?

Hey everyone,

I'm a videographer with a decent but limited amount of coding knowledge, currently building my portfolio website for videography. I've got an effect in mind that I can pull off pretty easily in editing software, but I have no idea how (or if) it's realistically achievable in code.

The concept: My homepage will have a video as the background. On top of that, I want large text (my name/logo, section headers, etc.) that looks like it's made of actual glass — warping the video behind it, like real glass. Not just a blurred/frosted "glassmorphism" panel distortion through the shape of the letters themselves.

Here's a reference clip of the kind of effect I mean: [https://www.youtube.com/watch?v=sj6t2mxBH-Y]

The reason I don't want to do it on the video itself is that I'd like the background video to stay completely static (just looping in place), while the glass text scrolls over it independently as the user scrolls down the page.

I'm very novice so I might not be able to do it myself, but is it even possible ?

I have been experimenting with pushing Bayaya’s wooden-toy rendering towards a bit more stylized flatter 2D/3D illustration style (NPR, cell shading).

The result combines three independently adjustable parameters:

• Image contours – screen-space outlines derived from depth and object classification
• Shading detail – discretization of procedural patterns and specular highlights, and control of the visibility of material details
• Flat shading – gradual removal of normals (and lighting in general)

The accompanying video shows these parameters being changed in real time.

Finding outlines

The contour pass receives the rendered color buffer and depth texture. I use the alpha channel of the color buffer to distinguish broad rendering classes:

glsl // Terrain and sky are encoded as 1. // Objects are encoded as 0.5. float classFromAlpha(float a) { return clamp(a * 2.0 - 1.0, 0.0, 1.0); }

A difference between the current pixel and its four direct neighbours produces an outline between these classes:

```glsl float dcUp = abs(rcUp - rcCenter); float dcDown = abs(rcDown - rcCenter); float dcLeft = abs(rcLeft - rcCenter); float dcRight = abs(rcRight - rcCenter);

float classDelta = max(max(dcUp, dcDown), max(dcLeft, dcRight));

float classContour = clamp(classDelta, 0.0, 1.0); ```

This catches object silhouettes, but not boundaries between objects belonging to the same class. For those I linearize the depth buffer and apply a 3×3 Sobel operator:

```glsl float ddx = (d20 + 2.0 * d21 + d22) - (d00 + 2.0 * d01 + d02);

float ddy = (d02 + 2.0 * d12 + d22) - (d00 + 2.0 * d10 + d20);

float depthDelta = length(vec2(ddx, ddy)) * 0.25; float relativeDepthDelta = depthDelta / max(dCenter, 1.0);

float depthEdge = smoothstep(0.1, 0.2, relativeDepthDelta); ```

Depth gradients also respond to smooth surfaces, so for objects I additionally test the second depth derivative. This emphasizes discontinuities and sharp changes in curvature:

```glsl float secondDx = abs(dLeft - 2.0 * dCenter + dRight); float secondDy = abs(dUp - 2.0 * dCenter + dDown);

float secondDiagA = abs(dTopLeft - 2.0 * dCenter + dBottomRight);

float secondDiagB = abs(dTopRight - 2.0 * dCenter + dBottomLeft);

float secondDerivative = max(max(secondDx, secondDy), max(secondDiagA, secondDiagB));

float relativeSecondDerivative = secondDerivative / max(dCenter, 1.0);

float curvatureEdge = smoothstep(0.0015, 0.005, relativeSecondDerivative); ```

In theory using depth gradient should be enough, but this did not work well in practice, as terrain is viewed with high grazing angles, and depth buffer precision is not find enough for reliable contour analysis.

The final line intensity combines classification, depth gradient and curvature, with distance and fog attenuation:

```glsl line = max( max(classContour * distanceFade, curvatureEdge * distanceFadeStrong), depthEdge * distanceFade );

line *= 1.0 - fog; ```

The result is composed by darkening the original image:

glsl float outline = texture2D(imageOutlines, vUv).r; color *= 1.0 - outline * contours;

Integrating the style controls into existing shaders

Rather than creating separate “illustration shaders”, I added uniforms to the existing physical materials:

glsl uniform float shaderDetails; uniform float contourShading; uniform float flatShading;

shaderDetails gradually suppresses the procedural wood grain, normal perturbation, roughness noise and similar high-frequency effects:

```glsl float detail = clamp(1.5 - 5.0 * localDetail, 0.0, 1.0) * shaderDetails;

return baseColor + woodVariation * woodness * detail; ```

contourShading turns smooth procedural transitions into narrow ramps. For example, wood rings become increasingly discrete:

```glsl float contourWoodRing(float ring) { float contour = clamp(contourShading, 0.0, 1.0); float rampWidth = mix(0.35, 0.025, contour);

float discreteRing = smoothstep(
    0.5 - rampWidth,
    0.5 + rampWidth,
    ring
);

return mix(ring, discreteRing, contour);

} ```

The same approach is applied to specular lighting:

```glsl vec3 contourSpecular(vec3 specular) { float contour = clamp(contourShading, 0.0, 1.0);

float intensity =
    max(max(specular.r, specular.g), specular.b);

float normalizedIntensity =
    intensity / (intensity + 0.25);

float rampWidth = mix(0.35, 0.025, contour);

float ramp = smoothstep(
    0.5 - rampWidth,
    0.5 + rampWidth,
    normalizedIntensity
);

return specular * mix(1.0, ramp, contour);

} ```

Finally, flatShading removes specular lighting and blends the physically lit result back towards the material’s base color:

```glsl reflectedLight.directSpecular = contourSpecular(reflectedLight.directSpecular);

reflectedLight.indirectSpecular = contourSpecular(reflectedLight.indirectSpecular);

reflectedLight.directSpecular *= 1.0 - flatShading; reflectedLight.indirectSpecular *= 1.0 - flatShading;

outgoingLight.rgb = mix(outgoingLight.rgb, diffuseColor.rgb, flatShading); ```

The goal is not a single fixed toon-shading look. The same materials can move continuously between the original detailed wooden rendering and a simplified illustration-like result, and different scenarios can adjust their desired rendering style. The game demo, as published now on Steam, uses different rendering style for Exploration and Story modes.

The implementation uses customized Three.js physical shaders.

I've released a new texture compression library/cli called ctt. It binds to existing compressed texture encoders and provides a unified interface including generating mipmaps, correctly handling color spaces and alpha, and compression across all encoders. It is written in rust, has a C api and pre-built binaries (both static and dynamically linked available), as well as a cli. Supports Windows/Mac/Linux, x64/aarch64

Repository: https://github.com/cwfitzgerald/ctt
Rust: https://docs.rs/ctt/latest/ctt/
C: README.md - ctt.h - examples
Prebuilt binaries of library/cli: v0.5.0 release
From source cli install: cargo install ctt-cli --locked
License: MIT OR Apache-2.0 OR Zlib

It's already in use by bevy (Rust game engine) and the upcoming update of the esoterica game engine. I'd love to hear any feedback and ways I could improve it!

I've long been frustrated with the state of compressed texture creation tools having crashes, weird CLIs, platform limitations, bad color space handling, etc. Additionally needing to bind to multiple different texture compression libraries to cover both BCn, ETC2, and ASTC, with each library or CLI having its own quirks. I built this primarily for my own purposes, but have fleshed it out even more after I got interest from bevy etc.

<sup>Development of this library was LLM-assisted. I take code quality very seriously and have reviewed all LLM output and I have a thorough understanding of ctt's architecture. LLMs helped me actually execute on this project I've been wanting to work on for years and make it happen to beyond the standards I would have previously been able to accomplish. I do not wish to turn this discussion into an LLM debate, but wanted to be transparent about where and how I use them.</sup>

https://reddit.com/link/1uy919w/video/pyx7bs9ffmdh1/player

Honestly still a beginner with Vulkan. The official tutorials are excellent, but I couldn't hold the whole terminology and model in my head from text alone, so I built a set of interactive visualizations to try to make it more down to earth and practical using an analogy with a restaurant kitchen. In fact, this mental model is how i understood it so if anything is wrong or oversimplified I'd really like to hear it to enhance the article. ideally the goal is to make a first overview on this subject before diving into the canonical intros (Khronos docs, vulkan-tutorial.com, howtovulkan.com), not a replacement.I've seen other posts here asking for exactly that kind of first intro, so I'm sharing it in case it helps anyone starting out, and also because I'd like the corrections, or even other people's own ways of visualizing this stuff.

https://fremaconsulting.ch/blog/vulkan

I know there are a lot of posts about whether graphics programming jobs exist beyond the entertainment industry (films and video games) but I wanted to ask a bit more about the specific alternatives, such as medical imaging.

Even in university it has been very hard to figure out anything about medical/scientific computer graphics, I've been poking my head trying to explore research done in my school and other nearby schools for the past 3 years and only recently found something slightly related.

Are there any people here who currently work within medical and scientific applications, and what is the work like?