Help wanted to create a babylon adapter for three-gpu-pathtracer

There is a really cool project providing a path tracing renderer for threejs. It looks like it’s actively developed and seems to gain some steam in the last months (at least in my twitter bubble…): GitHub - gkjohnson/three-gpu-pathtracer: Path tracing renderer and utilities for three.js built on top of three-mesh-bvh.

The author has created an issue to provide an adapter to make this work with babylonjs: Provide adapter for Babylon JS · Issue #35 · gkjohnson/three-gpu-pathtracer · GitHub

I just wanted to spread the word here, in case someone is interested to move this forward. Maybe @erichlof since he has some experience in this field? No pressure though :wink:


Yes this is super cool to see!


Hello, thanks for posting! Yes I have been following Garrett’s BVH project, and now path tracer project, for several months now. I’ve got a lot of respect for him - he really knows his stuff, especially the lower level side of things (working at NASA JPL and all!).

It’s interesting, he and I took almost opposite paths to get path tracing working in the browser. I took the more performance, real-time approach, inspired by Jacco Bikker’s Brigade series (1, 2, and now 3.0) of real time Path Tracers. I started out path tracing the usual simple math shapes, then eventually gave in and made a BVH so I could start rendering triangle models.

Garrett, on the other hand, started with a BVH in place, then he began trying path tracing, ha. Also, whereas my style of project is first person fly/walk camera, his is the more traditional renderer, with an orbit camera, orbiting around the triangular model at the center of the scene. I have just a few surface materials, in order to keep 30 to 60 fps on any device, whole Garrett has implemented full support for loading PBR materials and their associated material maps.

If he is successful in his next step, which is to add support for light map and AO map baking and texture creation, I will recommend that everyone who wants that with three.js or Babylon.js (pre- light map baking through path tracing, that is) to use his renderer over mine, as he has successfully gotten full PBR materials and multi materials going already.

Thanks for mentioning his call to action to help make an adapter for BJS. I’ll take a look at his source, and see if maybe I can add something, or maybe point him toward my BJS path tracing renderer, because I’ve had some great help from the amazing BJS community here on this forum. I couldn’t have got it working without your help. But we’ll see what I can offer him, because he’s already got a lot going on! :smiley:


Is it appropriate to assume that WebGPU will accelerate the rendering time by a lot?

Hey guys!

Glad to hear people are excited about this. As a little more background I started working on three-mesh-bvh years ago as a fun educational project and over time it’s expanded quite a bit and become fairly finely tuned memory and performance-wise. I’ve been inspired by @erichlof’s pathtracer as well as others over the years and saw an opportunity to put the BVH lib to use in a shader, as well. My goal now is to build up a modular, reusable pathtracing library that can hopefully gain some traction the way three-mesh-bvh has.

In terms of a Babylon adapter the thinking is that it would be nice to converge the community effort and enable the library to be used more broadly if possible. Of course the underlying foundation here is dependent on three but I think at least a basic adapter for Babylon should be doable considering the requirements for pathtracing are more or less just a static scene. I’m less familiar with Babylon.js but I’m happy to help facilitate work and contributions to help move an adapter like this forward.

I’m not sure if such a utility already exists but I think the simplest approach (and probably performant-enough one) is to provide a utility to bake a Babylon.js scene into a single static three.js BufferGeometry with groups and associated array of materials. Then a BVH can be built (or more quickly refit if regenerating the same scene) and passed to the three pathtracer. We just need someone to help with that end of the work! I don’t think that shouldn’t necessarily require pathtracing knowledge but I certainly wouldn’t turn down any help on that end if @erichlof is interested :grin:


Is it appropriate to assume that WebGPU will accelerate the rendering time by a lot?

With compute shaders being available in WebGPU I expect it’s possible that that could help improve performance though I’m not sure how long it will take for WebGPU adoption to reach critical mass. But there’s still a lot of room for performance improvement both in terms of shader BVH functions and improved pathtracing convergence techniques in the current WebGL2 implementation.


Hey Garrett! Nice to see you here on the Babylon forums! That’s great that you are ready to add a Babylon adapter to your project. There are a lot of friendly, knowledgeable people here that are familiar with the Babylon system. I had a lot of help when asked to port my renderer over to Babylon. I couldn’t have got it up and running without everyone’s help here!

I don’t know if it will help, but here is the loading part from the Babylon.js version of my path tracer. The GLSL parts are largely the same as the three.js version, but hopefully you can see how the geometry is handled (as opposed to three):
gltf loading and processing code

But like you said, maybe someone here on the forums who is fluent in Babylon will be able to convert the Scene data (which could include gltf models as well as Babylon library-defined geometry primitives) into something that can be loaded easily by your three system that is already in place.

I expect that there will be benefits to be had with moving everything from WebGL 2 to WebGPU - but I agree with Garrett in that we might have to wait until there is more widespread browser support. Having said that, there is in fact someone who is working on porting my three.js path tracer over to a node system with WebGPU. I’m glad Levi Pesin has taken the helm on this, as WebGL’s GLSL to WebGPU’s WGSL is not a direct mapping or intuitive conversion. Here is a link to Levi’s project.
In the meantime, I am constantly looking for optimization opportunities for our generalized path tracing code that we do have working for the browser. Anything that benefits our current WebGL 2 projects (in terms of framerate or convergence speed), will also directly benefit the future WebGPU versions, when they come online.