Some advise about model loader about three.js-pathtracing-renderer

[erichlof]

Hello @q750831855
I am back with some nice photos showing that the renderer can now load in a mesh with multiple parts or sub-meshes. This Tank model from the classic 1982 movie TRON has 5 parts, each its own mesh. I chose the least-violent looking color for this originally menacing tank: rose or pink, lol! But even with this harmless color, you can see that all the 5 meshes load in correctly to make the big tank mesh. Here it is with 3 different materials - clearcoat plastic, glass, and metal:

Even with the non-standard color choice, I must say it looks quite realistic in the outdoor environment!

I will go through and update all the model-loading BVH demos to be able to handle multiple mesh parts like this.

Thanks again for the suggestion and sorry that I didn't get your point when you first opened this issue! ;-)
-Erich

[RenderTool]

Hi！@erichlof
It’s all right.I will communicate with you when I find other problems

[erichlof]

@q750831855
Hello! Happy Lantern Festival to you as well! Thank you for the suggestion - when I have a chance I will see if I can add it in for support of multiple mesh parts. Honestly that part of my codebase (the reading in of geometry data and creating data textures from the Three.Mesh objects) is one of the weaker parts of my knowledge. I will try though! I'll let you know here if I find anything or get something working. :-)

[erichlof]

@q750831855
Upon further investigation, I do in fact have this in place, for instance these lines from the BVH_Animated_Model.js source file. https://github.com/erichlof/THREE.js-PathTracing-Renderer/blob/gh-pages/js/BVH_Animated_Model.js#L63-L105

However if you were to happen to look at any other demos that load in gltf models like Bi-Directional_Difficult_Lighting.js(UtahTeapot), BVH_Point_Light_Source.js(Bunny), BVH_Spot_Light_Source.js(Bunny), BVH_Terrain.js(Terrain), HDRI_Environment.js(Dragon), and BVH_Visualizer.js(Dragon), I don't really need this feature because all the models are self-contained single meshes, and so the 'geolist' code is not really doing anything. It was put in there a long time ago before I knew what model I was going to be using for all the various demos.

However, if you do have a mesh with multiple children meshes, the built-in three.js 'traverse' method should kick in and will automatically combine every single triangle into 1 large 'modelMesh' that ends up being passed into the GPU data texture as well as the BVH_Builder so that a hierarchy of bounding boxes can be placed around each and every triangle of the 'combined' mesh for ray tracing purposes.

Hope I have clarified the issue. Let me know if you have any other questions or concerns.
Thanks,
-Erich

[erichlof]

@q750831855
I must apologize - I misunderstood your initial post. I in fact did not have the loading of multiple mesh parts currently working as I thought I did. But the good news is that I have taken your suggestion and fixed the issue!
I re-opened your issue and soon I will be back to post a rendering correctly made with a mesh that has multiple parts. I will then update the other demos that load models, so that users can load any mesh they want instead of the default meshes (which are Stanford bunny, Stanford dragon, Utah teapot, etc.) .

I will return later tonight or tomorrow with the updated code and example rendering.
Thanks!

[Fluqz]

Hey @erichlof, first thanks for that awesome path-tracer! I really enjoy looking at your project.
I tried to use the GLTF Model Viewer to load a model of my own, its a meshgroup which I generated with THREEJS and export it with the THREE.GLTFExporter.
I noticed that each part (mesh) of the group is positioned to the center of the group, when importing to your GLTF Viewer.
So while writing this text, I though I might have to apply the transforms to the geometry, which worked!
I did this before exporting:

objGroup.traverse(o => {

      if(o instanceof THREE.Mesh && o['geometry']) {

        o.updateMatrix()
        o.geometry.applyMatrix(o.matrix)
        o.position.set(0, 0, 0)
        o.rotation.set(0, 0, 0)
        o.scale.set(1, 1, 1)
        o.updateMatrix()
      }
    })

But on some combinations I get an error:

This seems to be the causing line:
let modelMesh = new THREE.Mesh(THREE.BufferGeometryUtils.mergeBufferGeometries(geoList));

I tried to make a condition here, but did not work

let geoList = [];
    for (let i = 0; i < meshList.length; i++) {
        if(meshList[i] && meshList[i].geometry instanceof THREE.BufferGeometry) {
            console.log(meshList[i], meshList[i].geometry.isBufferGeometry) // is always true
            geoList.push(meshList[i].geometry);
        }
    }

Do you may have any clue?

[erichlof]

@Fluqz
Hello, thank you for the kind words! About the GLTF Viewer, unfortunately I did not create that project or its associated files. It was originally created by @n2k3 . Over the past year, as Three.js has changed a little here and there on every new monthly version, sometimes that Viewer gives me errors. When that happens, I have to go back and track down the cause and make small adjustments just to keep the viewer project working on my repo.

I have pinged n2k3 in the above paragraph - maybe he can shed some light on the model loading error as he was closer to his own source files than I was. If either he doesn't respond, or if he can't figure out the cause for error, I would suggest instead using my .js model-loading code for my various BVH demos. Chances are, I have updated them more frequently to reflect the various changes in Three.js library as well as its GLTFLoader() source.

Hopefully we'll know more soon. :-)

[n2k3]

Hey, sorry for my late reply. I'll be working on this again in about a month or so.

[Fluqz]

Hey long time no hear. Still excited to see it work, thanks :)

@erichlof I saw that, for quite a while already, on your To-Do list is the feature to import threejs scenes to the path tracer engine.
I also saw that you frequently update algorithms to increase quality and performance. If Im allowed to make that suggestion, I had in mind that having a working version where threejs scenes can be imported rather easily first, before working on quality and performance, would greatly help increase people getting interested in your project. Because its already very good and fast! And theyre gonna catch attention as soon as it works, because this is the only fast and reliable path tracer with quality that is out there. When people get interessted, feedback and contributes will call as well.
For sure I also know that this is your personal project and you're probably having more fun working on the engine instead of the threejs connection.
I probably just can't wait to use it :P

[erichlof]

@Fluqz

Hello! Yes loading the Three.js scene as it is right into the path tracer has been on my TODO list for a long time indeed. There a couple of reasons for the delay in getting this feature working.

The first is material conversion. There is not a direct 1:1 ratio between Three.js materials as they are saved on disk or server and the types of materials and parameters I need to be able to show the correct materials. The closest is Three's Physical material, but unless the scene was saved with exclusively that, I wouldn't be able to extract some of the necessary parameters for path tracing purposes. Then the question becomes: do we just guess? Or put a default material on the surfaces with missing info?

The next gray area is lights. How lights are sampled and the number of lights can greatly affect the distracting noise when path tracing. If the Three.js scene had 1 sunlight or a couple of indoor lights, that wouldn't be too much to worry about. But most users' indoor scenes have much more than that, and then we really need a separate acceleration structure for the lights themselves, which I don't have in place as of yet.

The final and most pressing issue would be how the scene geometry itself is treated when importing. Right now I can successfully load in a gltf model, place it in a simple scene, and render it. But if you tried it with an arbitrary number of objects/models, or a heavy amount of architectural geometry for instance, the shader compilation starts getting finicky and crashing. Again what would be needed is an acceleration structure over the objects that have their own acceleration structures! It gets kind of messy real quick.

That's not to say it can't be done, it's just that thoughtful planning needs to happen as well as implementing some more advanced acceleration structures, in order to have a seamless 1:1 transition from stored scene to path traced scene.