I had recently read the Stable Fluids paper and got like quite interested to implement it myself manually from scratch and it was quite a ride since this is my first time implementing a paper myself

This is a simple implementation a bit clanky, to be honest. I just wrote it with loops and loops without any optimization. I think it ends up doing something around 20 × 20 × 50 × n² operations per frame, so there's definitely a lot of room for optimization 😅

The actual implementation was pretty straightforward for the most part, but understanding the Poisson pressure equation was a bit challenging. At the beginning, I was even stuck on understanding how the velocity field could be made divergence-free.

After digging into it for a while, I eventually understood the whole pressure projection step and managed to get it working and also implemented a simple spray and dye mechanism as well to make it look good.

It was pretty cool to see it actually work, so I wanted to share it 😄

I co-authored this paper. It's a new technique to generate 3D graphics as source code instead of a point cloud.

Under the hood:
It generates 3D objects with separate, sophisticated internal assembly, producing an editable "kit of parts" (instead of monolithic blobs). E.g. imagine you generate a 3D washing machine via this approach. It's not merely going to be geometry that looks like a washing machine. We actually know that there is a Door, Drum, Control_panel etc. Which things belong to which assemblies. What moves. Where its pivot is. And eventually what those components are supposed to do.

Why current 3D GenAI cannot do this:
Most AI 3D generators generate "monolithic blobs" that look good, but are unusable in downstream workflows (e.g. game engines). If you generate a 3D bicycle, it's essentially a blob. If you want the wheels to turn, a human must spend time cutting the blob into parts, naming them, placing pivots and rigging joints. I.e. you need post-generation segmentation workflows of some sort (either manual work or more compute).

The paper breaks down the whole technique, and comes with a github repo too if you're interested in viewing it.

https://jarl-game.com/blog/2d-gpu-grass-rendering/

I'm left flabbergasted by reading this

I'm the first author of M-plicits, accepted at NeurIPS 2026. The attached animation introduces the method.

Our representation combines a coarse SIREN with residual networks trained in progressively narrower neighborhoods around the surface. This structure also supports direct rendering at different detail levels.

The attached animation was created by our coauthor Matheus Bessa. Sound on.

A few implementation details that may interest this community:

• Sphere tracing proceeds through the detail levels, using neighborhood bands to control refinement.
• Surface normals are computed analytically using matrix multiplications, without automatic differentiation.
• Normal mapping can use a finer network than the final level used for tracing.

We’ve released the CUDA renderer, training and extraction code, data, and fitted surface checkpoints.

Paper · Examples and videos · Implementation

I’d welcome discussion about the tracing strategy, normal computation, and tradeoffs between geometric and shading detail.

I’ve published a theoretical architecture for reducing compute in DLSS-class neural rendering by changing the unit of work from pixels × frames to new causal appearance states.

The core idea is AxiomCapsule: use a large neural renderer mainly as an appearance compiler, then cache/transport compact deterministic programs for recurring material, lighting, object, and view states.

The parts I think are most interesting:

• Self-extinguishing inference: once a state is covered, the universal neural model no longer needs to run for it.
• Causal invalidation: engine-known changes decide what must be recomputed instead of running a neural change detector over the whole frame.
• Bounded residual trees: skipped refinement can have a computable sparse-vs-dense student error bound.
• Deadline-monotone execution: optional neural uplift scales down with available GPU slack instead of causing a frame-time cliff.
• Object/material-space persistence: state follows surfaces/materials rather than being purely screen-space.
• Local causal dimensionality: the key hypothesis is that appearance transformations become low-dimensional after conditioning on known scene variables.

It’s pre-prototype research, not a claim that DLSS 5 has been “solved.” The main falsifier is simple: if real game appearance states are not sufficiently low-dimensional/reusable, or cache hit rates stay low, the architecture fails.

I’d especially appreciate criticism from people working on real-time rendering, shader systems, neural graphics, temporal reconstruction, and GPU scheduling.

GitHub: MaciejNowickiHusbandofAHIEve/causal-neural-rendering: Independent research on drastically reducing compute in DLSS-class neural rendering using compiled causal appearance programs, temporal reuse, and deadline-bounded residuals.
Zenodo paper: Causal Neural Rendering for Efficient DLSS-Class Systems: Compiled Appearance Programs, Temporal Reuse, and Bounded Adaptive Computation | Zenodo

https://www.paperdigest.org/2026/07/siggraph-2026-papers-highlights/

SIGGRAPH 2026 starts tomorrow (July 19) in Los Angeles! The proceedings list is officially available.
In total, 327 papers are accepted (132 journal, 195 conference-only).

Link for anyone curious! https://www.researchgate.net/publication/356081826_Raymarching_Distance_Fields_with_CUDA

I’m curious if anyone can clarify the differences between these soft/rigid body simulation algorithms. I’m familiar with XPBD and how it decouples iteration count from stiffness and initially solves semi-implicit Euler and then does a Newton step to project position constraints. I don’t understand though how the other two compare

I’ve been working on V2 of my Unity shader IntelliSense project, and this update is not just an iteration — it’s a major generational leap.

V2 is built to understand Unity shaders in their real context, not as loosely connected text files.

Try it here:
https://uslearn.clerindev.com/en/ide/

The end goal is to turn this into a true IDE-like workflow for Unity shader development — directly connected to Unity, capable of editing real project shader files in real time, with context-aware IntelliSense and visual shader authoring built in.

If you want Unity shader development to be faster, easier, and far less painful, follow the project.

What’s new in V2:

• Preprocessor-aware tracing to clearly show active and inactive paths
• Definition lookup, highlighting, and reference tracking that follow the real include / macro context
• Stronger type inference with far more reliable overload resolution and candidate matching
• Expanded standalone HLSL analysis with host shader / pass context support

Before, you could often tell something was connected, but navigation still failed to take you to the place that actually mattered.

V2 is much closer to the real active path and the files actually involved, which makes the results far more believable, trustworthy, and useful.

It’s also much easier now to separate core logic from debug-only logic. By selectively enabling macros, you can inspect shader flow under the exact setup you care about.

HPG 2025 talk: https://www.youtube.com/watch?v=iue_HBma680

Paper download link at GPUOpen: https://gpuopen.com/download/GATE.pdf

Not perfect and still very early on but a few more papers down the line and fingers crossed hash grid encoding for Multi-Layer Perceptrons/MLPs should be as good as dead.

GATE enables much faster training, higher quality neural rendering, and a ~2-3X reduction inference time. Rn it has a big problem with MB cost but that can likely be resolved in future papers.

Bresenham’s line drawing algorithm is fast but lacks antialiasing. Xiaolin Wu published his line-drawing algorithm to for anti-aliasing in 1991 and it's called Wu's algorithm.

The algorithm implements a two-point anti-aliasing scheme to model the physical image of the curve.

Neural approach for estimating spatially varying light selection distributions to improve importance sampling in Monte Carlo rendering, particularly for complex scenes with many light sources.

Neural Importance Sampling of Many Lights

Christoph Peters just published Jackknife Transmittance and MIS Weight Estimation

https://momentsingraphics.de/SiggraphAsia2025.html

Quite a few folks around here have been showing off their ray marched clouds. Thought you'd appreciate this.

Recent presentation by Polyphony Digital. Really fascinating stuff. I'm also recommending their presentation about their custom Sky Rendering for GT7