Wilhem Barbier

Computing the exact bijection of the optimal transport (OT) problem between very large point sets is completely untractable…

In our SIGGRAPH Asia 2025 paper: “BSP-OT: Sparse transport plans between discrete measures in log-linear time” we get one with typically 1% of error in a few seconds on CPU!

Cyprien Plateau--Holleville in front of his title slide at the RING meeting

RING meeting in Nancy,
Cyprien Plateau--Holleville presented presented his awesome work on exact integration of the differential quantities involved in Partial Optimal Transport. And that's not all: It comes with a combined physsim - Optimal Transport - rendering on the GPU !

It was so good to be in Vancouver to present our work “Interactive Optimization of Scaffolded Procedural Patterns” at #Siggraph2025!

If you couldn’t make it, have a look at our project page!
💻 marzia-riso.github.io/iospp.html

Can’t wait for what’s next! 🎉

Sample image from the Lipschitz pruning released application

🚀The code for Lipschitz Pruning is now online thanks to @wbrbr.bsky.social🚀

🔗 github.com/wbrbr/Lipsch...

It's a simple Vulkan app useful for experiments. Also, the monument done by @elie-michel.bsky.social is released under a CC-BY license📄

(poke @mattkeeter.com I remember you asked!)

Presenting this paper tomorrow morning at 9:30am, during the Lightning Fast Geometry session⚡
Come check it out if you can!

I will be presenting the paper "Lipschitz Pruning: Hierarchical Simplification of Primitive-Based SDFs" at SIGGRAPH 2025 during the Best of Eurographics session! Come to my talk on Wednesday morning
wbrbr.org/publications...

📜 New SIGGRAPH 2025 paper 🎉

❔How to compute bounding volumes for procedural Signed Distance Fields (SDFs)? This is not so trivial!

💡We propose a simple method called Sphere Carving. It extracts (convex) bounding volumes around SDFs, requires very few evaluations, and is GPU compatible.

Thanks, I'm glad you liked it!

As a result, our method consistently reduces the build time although this comes at the cost of an increase in tracing time. We show that this tradeoff is worth it for real-time raytracing of complex dynamic scenes since rebuilds are particularly expensive. Check out the paper for more details!

In this paper we focus on maximizing build speed by removing this additional traversal. To do so we introduce a bottom-up collapsing algorithm, which we integrate into an existing high-performance BVH2 builder to obtain a fast wide BVH construction algorithm.

However most of the GPU BVH construction litterature focuses on binary hierarchies.
A notable exception is H-PLOC by Benthin et al which uses a binary builder and a separate top-down collapsing step to convert the binary BVH into a wide BVH.

The standard acceleration structure for ray-tracing is the wide BVH, and fast GPU construction of these hierarchies is a key challenge for realtime raytracing. This is especially important for complex dynamic scenes where BVH rebuilds are a major bottleneck. Example: Flooded Sponza by Intel.

I am glad to attend #HPG2025 where I just presented our paper "Fused Collapsing for Wide BVH Construction", co-authored with Mathias Paulin. We propose a fast build algorithm for wide BVHs that directly computes a wide hierarchy without additional collapsing pass. Webpage: wbrbr.org/publications...

How do you get AABBs for the skinned clusters without transforming all the geometry? As the AABB also needs to bound the finer LODs this doesn't seem trivial. And transforming the bounding box is not conservative as the cluster weights vary. Would love to have more details on your solution for this!

Back to fiddling with my Vulkan path tracer

Thanks! Glad you like it, your paper was a big inspiration for this project.

Implicit surfaces are great, but if you are not Inigo Quilez, it's really hard to control how they look...

That's why I'm really proud to annonce our Eurographics 2025 paper: "Implicit UVs: Real-time semi-global parameterization of implicit surfaces".

Oops small mistake, I mistyped @axelparis.bsky.social

These pruned trees enable efficient evaluation of the SDF for rendering or discretization, resulting in >100x speedups for complex scenes compared to brute-force evaluation. Come to my talk next week for more details, or read the paper here: wbrbr.org/publications...

Overview of our method. Left: a shape is described by a smooth CSG tree. Middle: the scene is divided into a grid, and we computed a pruned tree for every cell. Right: these pruned tree are much smaller than the input tree, and enable faster SDF evaluation for sphere tracing or SDF discretization.

Our algorithm takes as input an analytical SDF represented as a tree of smooth booleans and a 3D region of space, and computes a much smaller pruned tree equivalent within the region. This procedure is simple and efficient, using the Lipschitz prop. of the SDFs instead of costly interval arithmetic

Left: an input CSG tree and a much smaller pruned tree computed using our method. Right: a rendered scene showing the number of active nodes per cell. Our method reduces the active nodes to less than 20 from the initial 6023 nodes of the input tree.

I am proud to announce our Eurographics 2025 paper "Lipschitz Pruning: Hierarchical Simplification of Primitive-Based SDFs"! With Mathieu Sanchez (joint first author), @axelparis.bluesky.social, @elie-michel.bsky.social, Thibaud Lambert, @tamyboubekeur.bsky.social, Mathias Paulin and Théo Thonat.

Genuine question, why do you want to use Nanite if not for the performance ? With fully dynamic runtime procgen you can't escape the O(n) rendering cost which is the whole point of the Nanite LoD system IMO. Or is it the software rasterizer that you'd like to use with your geometry ?

Is this for CPU ray-tracing ? In my experience for GPU ray-tracing compressed wide BVHs do perform better (see CWBVH paper).

Are there any talks about their engine that you'd recommend (free or vaulted) ? I haven't heard much about it so I'm interested.

What are these characteristics ? Too axis-aligned ?

Love the color scheme! What's your setup ? (this doesn't look like a standard Windows+Visual Studio)

Is there a difference between an R-Tree and a BVH ? When (briefly) I looked into R-Trees they looked like the exact same thing, from a separate community

Better in what sense ? Better for innovation (no opaque acceleration structure) ? Better for the end users (no feature kept behind expensive HW) ? Or better for actual performance ?

That's interesting, as there is a (pretty old) dynamic scene benchmark which features an exploding Stanford dragon: gamma.cs.unc.edu/DYNAMICB/
I wonder if this usage clause was there at the time.

Just spent hours trying to understand why a traceRayEXT() GLSL call wasn't working (no validation message), turns out I had set maxPipelineRecursionDepth to 0 instead of 1 for the RT pipeline.... Vulkan debugging is quite painful when the validation layers aren't catching your stupid mistakes ^^