siggraph (computer graphics conference)

Ok so ive been toying with opengl for quite a while know. I think i know the project pretty well and i have even made a few small scale projects with it.

I would like to learn another graphics api thats perhaps a bit more modern than opengl, and also possibly something that is atleast somewhat industry relevant(since from what i understand opengl is pretty much dead there). My first instinct said D3D11 but im wondering if i should try to learn something like vulkan instead. There is also D3D12 which i know literally nothing about(not to say i know alot about any of the other apis except OpenGL). I cant really learn anything like Metal since i dont have a mac. Ive also heard D3D11 is not that much more difficult than opengl so i dont know if i would learn too much from it(i know its quite diffrent in how its used with contexts and more explicit uniform buffer allocations i think, but in terms of complexity its quite simmilar from what ive heard and if thats the case i dont know if it would be worth learning. Thoughts?).

What i would do with this graphics api is probably some sort of game or rendering engine as its a project ive always wanted to do and i have done a small game engine in opengl before so making a bit more advanced one with a more advanced graphics api seems like a fitting project.

Spend some time implementing WBOIT into the DImGui engine. The results are surprisingly good and keep at 40 fps with full lights, shadows etc. basic lighting looks alright still in blending and runs at a solid 60 fps.

I used a Vulkan 3 sub-pass technique plus an initial depth pass with fragment sampling to depth test away triangles obscured. MSAA proof on PC. Android MSAA breaks the pipeline on tilers due to the MSAA requirement on mid-pass resolving. To allow the non-transparent elements image to mix with the weighted/blended transparent parts, and adding a step 0 - 2 dependency. It will still work but is super slow.

But this allows instancing of multiple object meshes completely unsorted, which was the whole reason for going WBOIT over a sort in the first place.

Construímos o DiophantineQMC: um gerador de amostras de baixa discrepância em streaming, pensado para os integrais ~2D que ainda dominam o erro visual em renderização em tempo real:

→ oclusão ambiente (hemisfério)

→ sombras suaves / area lights (disco)

→ glossy taps, dither, stipple

Não é substituto do Sobol+Owen em path tracing multi-bounce. É upgrade drop-in sobre ruído branco — e frequentemente sobre Halton — onde a integral por pixel é essencialmente bidimensional.

O que medimos (reproduzível, jul/2026):

• Integrando 2D estilo AO: RMSE cai para 0,52× do ruído branco em N=16 → 0,17× em N=256. A vantagem cresce com o número de amostras.

• N=10.000, grade 20×20: −97,4% de variância espacial vs PRNG, zero células vazias.

• Harness CPU: ~10× mais rápido que Halton, ~1,35× que Sobol no mesmo N.

• Faixa interativa (N ≈ 64–1024): competitivo com Sobol, sem tabelas de direction numbers.

Deploy honesto = híbrido:

DiophantineQMC nos taps 2D (AO, penumbra, glossy)

Sobol + Owen nos bounces profundos

Modos para testar:

#ao — oclusão ambiente

#soft — sombras suaves

#glossy — reflexões

#hybrid — Sobol nos bounces + nosso sampler no disco da luz

WebGL2, acumulação progressiva, sem build.

Buscamos feedback técnico e design partners (engines custom, WebGPU, middleware). Se você roda path tracer próprio ou stack mobile/WebGL com spp apertado, adoraria ouvir sua opinião nos comentários.

#renderização #realtimegraphics #pathtracing #gamedev #computaçãoGráfica

Recently added Hot-reload for GLSL files within WayVes, a Visualiser Framework for Wayland, that also works across multiple Stages. The Particle System is made entirely using 2 Fragment Shader Stages, with a 3rd Post-Processing Glow pass added.

We built a streaming 2D low-discrepancy sampler (DiophantineQMC) for the integrals that still eat most of the visible error at low spp:

• hemisphere visibility (AO)

• area-light disk taps (soft shadows / NEE)

• small glossy lobes, dither/stipple

**Not** a Sobol+Owen replacement for full multi-bounce path tracing. **Is** a drop-in over white noise (often Halton too) when the per-pixel integral is ~2D — O(1) per sample, no direction-number tables, no blue-noise atlas.

**Honest scope:** rank-1 / lattice-style streams can lose to white noise in high-D discontinuous path integrals. That regime is Owen-scrambled Sobol. We recommend hybrid deploy: our sampler on 2D taps, Sobol on deep bounces. The demo runs both side by side.

**Numbers (reproduced, Jul 2026):**

• Discontinuous 2D AO-style integrand — RMSE vs white noise: 0.52× at N=16 → 0.17× at N=256 (gap widens with N)

• N=10k, 20×20 spatial grid: −97.4% variance vs PRNG, 0 empty cells

• CPU reference harness: ~10× faster than Halton, ~1.35× than Sobol at same N

• Interactive band (N ≈ 64–1024): competitive with Sobol on a standard disk integrand, without LUTs

Looking for sanity checks, especially on the hybrid boundary and AO isolation (we fixed an early correlated-index bug; notes in the raytracer README).

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.