WebGPU: Sobol random number generator by TheBlek · Pull Request #761 · gkjohnson/three-gpu-pathtracer

TheBlek · 2026-04-29T08:56:48Z

This PR makes a lot of changes in order to support selecting random number generator in API:

Implements sobol numbers by porting webgl implementation in two version: with and without texture lookup; From my cursory performance testing it's not conclusive whether texture lookup makes sizable difference, curious to know how it work on your computer
Create and manage function nodes for random numbers in WebGPUPathtracer. That means passing them down to everything that needs them: PathtracerBVHComputeData, material and backend in general.
Current material is stored and handled inside WebGPUPathtracer now. This allows handling random numbers for a material by default and leaving setRandomFunctions on PathtracerBackend unspecified, so derivations don't have to call super before doing their stuff. Not sure about this decision, but it felt easier to think about the system with material handled here. Let me know what you think.
In order to make random number nodes hot-swappable I had to resort to a lot of proxyFn nodes which feels a little messy. Perhaps there could be one place that creates proxy nodes and then distributes them? Not sure how this should be handled

Here's some image comparisons between pcg and sobol random numbers. It looks like diffuse surfaces are not much by more uniform random numbers, unlike specular which has less noise (see clearcoat image).

PCG	Sobol

…in one place.

…functions, inline lambertBsdf to use correct random.

TheBlek · 2026-05-07T14:32:57Z

@gkjohnson Let me know if you want this PR divided or just want to take a different direction for implementing different random number generators.

gkjohnson · 2026-05-12T03:10:53Z

Here's a quick comparison of the random functions on the khronos-AnimatedCube w/ 100 samples. It's subtle but I just wanted to make sure there was a perceptible difference. I somewhat expected a bit more, though?

PCG	Sobol

From my cursory performance testing it's not conclusive whether texture lookup makes sizable difference, curious to know how it work on your computer

I'm not seeing any difference between the performance of PCG, SOBOL, or SOBOL_TEXTURE. I expect the performance won't be dominated all that much by the random function implementation.

I'm thinking we can just keep the non-texture version of the SOBOL randomness unless there's a good reason to do otherwise?

Create and manage function nodes for random numbers in WebGPUPathtracer. That means passing them down to everything that needs them: PathtracerBVHComputeData, material and backend in general.

In order to make random number nodes hot-swappable I had to resort to a lot of proxyFn nodes which feels a little messy. Perhaps there could be one place that creates proxy nodes and then distributes them? Not sure how this should be handled

I'll think through this, as well - I agree it's not ideal to have to string the randomness functions down through to every subfunction.

gkjohnson · 2026-05-12T03:05:18Z

 		for ( var i = 0; i < INTEGRATION_SAMPLES; i++ ) {

-			let wh = ggxDirection( wo, vec2( alpha ), pcgRand2() );
+			let wh = ${ ggxDirectionFunc }( wo, vec2( alpha ), ${ pcgFunctions.vec2f }() );


It looks like this is always using "pcg" randomness. Is this intended?

Yes, kind of. I think it does not really matter which random function we use here since there are many samples taken.

gkjohnson · 2026-05-12T03:07:55Z

-				enqueueRaysKernel.seed ++;
+				enqueueRaysKernel.seed = this.seed;


Can you explain the need for this change? We should still need to store a different seed per ray because they may each be at a different point in the path.

You're right, if we're being proper, seed should be different for each ray. Fixed that.

gkjohnson · 2026-05-12T03:12:16Z

+// Alpha test should be the last index as it is summed with triangle index
+export const RNG_INDEX_RAY_JITTER = 0;
+export const RNG_INDEX_ENVIRONMENT_SAMPLE = 1;
+export const RNG_INDEX_SCATTER_TYPE = 2;
+export const RNG_INDEX_SCATTER_DIRECTION = 3;
+export const RNG_INDEX_ALPHA_TEST = 4;


I'm not fully understanding what this is for?

Those are unique numbers for each sample of random numbers that are used for sobol number generation. They appear in webgl pathtracer as plain numbers:

state.isShadowRay = scatterRec.specularPdf < rand( 4 );

For better structure and to ensure there are no duplicates, I decided to define those constants here.

gkjohnson · 2026-05-12T03:12:42Z

 				rayQueue[ index ].pixel = indexUV;
 				rayQueue[ index ].throughputColor = vec3f( 1.0 );
 				rayQueue[ index ].currentBounce = 0;
-				rayQueue[ index ].pcgStateS0 = ${ getPcgSeed }();


Can you explain how this is working, now? Is this replaced by RNG_INDEX_RAY_JITTER?

Not really, it just initializes each time without carrying it over. Will add a little fix to use current bounce in initialization. Although, if we are to keep only one random number generation algorithm, it should not matter as sobol numbers' state can be properly initialized on each stage properly.

gkjohnson · 2026-05-19T02:55:59Z

Create and manage function nodes for random numbers in WebGPUPathtracer. That means passing them down to everything that needs them: PathtracerBVHComputeData, material and backend in general.

In order to make random number nodes hot-swappable I had to resort to a lot of proxyFn nodes which feels a little messy. Perhaps there could be one place that creates proxy nodes and then distributes them? Not sure how this should be handled

I'll think through this, as well - I agree it's not ideal to have to string the randomness functions down through to every subfunction.

Having thought through this a bit more - I'm thinking we don't really need a user-settable randomness function (at least for now). We can keep the PCG functions around but if we're seeing that Sobol is better than we should just export and use that everywhere. Then for dev we can change the randomness functions around in that source file if we have to. I don't think the toggle features is worth the implementation complexity atm.

…nctions.

TheBlek · 2026-05-30T11:28:17Z

Then for dev we can change the randomness functions around in that source file if we have to.

I understand not exposing the toggle to the users, but even implementing new random numbers and changing them in every place is tedious and make comparisons harder.

I simplified the implementation a bit by extracting proxyFn nodes into a single object that is passed around. Let me know if complexity is still an issue.

TheBlek added 10 commits April 28, 2026 20:05

Implement sobol random number generation

bc7051a

Use sobol numbers in megakernel

bf56f17

Use sobol random numbers in wavefront pathtracer

e0662cc

Refactor random number usage across the board to support changing it …

adf2b31

…in one place.

Add configuration option to choose PCG random numbers. Remove unused …

2ced6b9

…functions, inline lambertBsdf to use correct random.

Implement sobol random functions with cached sobol points in a texture.

29fdab5

Fix bvhData not updating random functions correctly.

0b832c6

Add configuration option for webgpu prng in viewerTest

6ba1ab6

Remove unused function

cadfe4c

Merge branch 'webgpu-pathtracer' into webgpu-sobol

6e6baa9

gkjohnson reviewed May 12, 2026

View reviewed changes

TheBlek added 2 commits May 30, 2026 17:45

Extract proxyFns into a separate object and pass it instead of raw fu…

c8ba7c7

…nctions.

pcg fixes

4ec322e

Fix seed for rays.

62d1e7f

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

WebGPU: Sobol random number generator#761

WebGPU: Sobol random number generator#761
TheBlek wants to merge 13 commits into
gkjohnson:webgpu-pathtracerfrom
TheBlek:webgpu-sobol

TheBlek commented Apr 29, 2026

Uh oh!

TheBlek commented May 7, 2026

Uh oh!

gkjohnson commented May 12, 2026

Uh oh!

gkjohnson May 12, 2026

Uh oh!

TheBlek May 30, 2026

Uh oh!

gkjohnson May 12, 2026

Uh oh!

TheBlek May 30, 2026

Uh oh!

gkjohnson May 12, 2026

Uh oh!

TheBlek May 30, 2026

Uh oh!

gkjohnson May 12, 2026

Uh oh!

TheBlek May 30, 2026

Uh oh!

gkjohnson commented May 19, 2026

Uh oh!

TheBlek commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		enqueueRaysKernel.seed ++;
		enqueueRaysKernel.seed = this.seed;

Uh oh!

Conversation

TheBlek commented Apr 29, 2026

Uh oh!

TheBlek commented May 7, 2026

Uh oh!

gkjohnson commented May 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkjohnson commented May 19, 2026

Uh oh!

TheBlek commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants