Weird clipping occurs when the camera is inside the bounding box of concave objects.

[n2k3]

Hey I've encountered some rendering problem with my own model: Above bounding bound of the model part:

Inside bounding bound of the model part:

Atleast, I think this is bounding box (and thus BVH) related?

You can see for your self here: https://n2k3.github.io/BVH_GLTF_Models_Example_v2_test.html

---

P.S. I have to praise you for making this path tracer, love playing around with it! It was especially interesting to read how much progress you've made in the last couple of months (written in issue #9). I plan to combine the best parts of your examples (speed optimized 'game engine' settings, glTF model loading, using the nice sky shader, etc) and also add other functionality myself to create a user friendly glTF model viewer. Other functionality I have in mind is proper glTF model loading with local drag & drop support (in my example I've added support for grouped meshes), with basic editor features.

P.P.S. Also the material colors are not correctly shown in the path tracer, at least for my model, if you download the model and use the glTF viewer you'll see that it has multiple materials that have different colors. But since I've written the part of loading my own glTF could you point me in the right direction on how to tackle this problem? Also what would be the best way to communicate for this type of communication, should I just create a new issue?

[erichlof]

Hi @n2k3 , Wow that's a cool project and model too! Thank you for including the .html demo files as well as the detailed pictures and .glb model to work with. Those items helped me a lot in determining what was going wrong. Well I have good news and bad news. The good news is that I located in the source code where it was failing, I then tweaked the BVH intersection code. See https://github.com/erichlof/THREE.js-PathTracing-Renderer/blob/gh-pages/Debug_BVH_Intersection.html#L204 And with just that little adjustment, everything renders perfectly: Fixed Demo

The bad news is that I'm not sure why the ray t is giving an error in seemingly random situations. It could be a precision thing, if you play around with that magic t + number and change it to say, 25.0, it will gradually error as the distance to the bounding box gets past that amount. I'm not sure what remedies to try.

The other bad news is that the "if rayT < t" thing was an early out for the BVH intersection algo, giving a higher frame rate. When I added my fix, although it works, it slowed the frame rate down because it can't (incorrectly) skip the checks of certain large bounding boxes and exit the loop earlier.

Now about the different colors not rendering properly, I think I know where to look for that. But let me do that tomorrow as it's late here. At least we somewhat resolved the big issue first.

Also, please note that I left your code untouched, except for making the pixel ratio 0.5 (my poor laptop can't handle 1.0, ha) and deleting the SceneIntersect function, then copy and pasting from my recently updated BVH demos (which have slightly cleaner BVH functions than in the past versions that you had been using). So, you might want to just copy and past from my repo the entire .html file and put it in your code editor and then go from there. Then you'll be starting with my latest updates.

Oh and just keep replying to this thread even if you have other issues - I know where to find it ;-)

Thanks, Talk to you soon (about the material colors), -Erich

[n2k3]

Thanks for your reply, and the 'weird' solution :) I can work on my project more over the weekend and I'll be able to take a more in-depth look to the changes you've made. I'll await your response about the material colors.

P.S. There has to be a better way to share code between the html files. I've seen in recent commits you're going through all html files to update them individually, this makes it hard to maintain and error prone. Would it be alright if I attempted restructuring the code into classes, create a pull request and go from there?

[erichlof]

@n2k3 Hi, sorry for the delay - I've been working at this color assigning stuff for pretty much the entire day, not only because it's a bug that you would like to resolve, but it goes deeper and affects future progress with loading in GLTF files. I have made slight progress, but the colors still are not matching their designated polygons: updated Demo It seems that somewhere between this line, https://github.com/erichlof/THREE.js-PathTracing-Renderer/blob/gh-pages/Debug_BVH_Intersection.html#L673 and this line, https://github.com/erichlof/THREE.js-PathTracing-Renderer/blob/gh-pages/Debug_BVH_Intersection.html#L994-L995

the numbers and simple math just aren't matching up. The / 3 and the * 16.0 can be changed, especially the '16.0' and the colors will shift to different sets of polygons, which is cool, but it never quite matches the gltf viewer. Am I correct to assume that your model has only triangles and that those triangles have only 3 vertices, and those vertices have only 3 coordinates, x, y, z as floating point numbers?
I'm not sure if I'm getting the stride correct on the initial array from three.js's side of things, namely the child.geometry.attributes.position.array.length variable.

Could you maybe try some different factors and see if you get any closer? I'll keep hacking away at it, but I feel like I've hit a wall because I don't quite understand the stride and layout of the buffer geometry triangles.

btw, let's hold off on the classes - I really want to get this important issue resolved.

Thanks! -Erich

[n2k3]

Hey @erichlof, no worries on the delay. It seems I've brought attention to a bug that goes deeper then we thought :)

You are correct in your assumption with respect to my original glTF files. My source files are multiple glTF/bin file pairs that make up a whole house. I had to load the ones that make up the first floor of the house in the Three.js editor and then export the scene as a single glTF, which I then converted again to glb. In the hope this was easier to work with (single file) and easier to distribute (smaller file size). But these conversions changed the mesh data and I don't know in what way exactly. Even though the model is valid and shows correctly in the glTF viewer.

I've uploaded the parts of the house as separate model glTF/bin file pairs. I've made an updated test here: https://n2k3.github.io/BVH_GLTF_Models_Example_v2.1_test.html (the model used in this test is the only one that works, the others error out when trying to load them, I'll have to take a look later). This is just a small part of the house model, it has 1 scene object and 5 mesh objects (as cubes) consisting of 40 vertices, 60 triangles total and are using 3 unique materials (the only thing unique about the materials are their names and their colors).

glTF binary data for one mesh object has 36 vertex indices representing 12 triangles (integers in pairs of 3, stored as 1 byte per integer) that define the triangles. And the 8 vertex positions (floating point numbers in pairs of 3, stored as 4 bytes per number). So one mesh object uses 36 bytes for indices, and 96 bytes for positions which totals to 132 bytes. How this relates to Three.js storing its byte arrays after importing the model, I unfortunately don't know.

I'll give it a go tomorrow myself, after some much needed sleep :) - I'll hold off on restructuring until all known glTF loading issues have been fixed.

[n2k3]

Success!

You were going in the right direction, but were slightly off. You convert indexed geometry to non-indexed, the information of what material belongs to what model was getting mixed up. So instead of getting the information from vertices, I've grabbed it from child.geometry.index.count, which are the triangle indices.

The fps seemed to tank even more while viewing (and thus rendering) the kitchen part...

I've made a pull request (#24) so that you can easily merge my code.

[erichlof]

@n2k3 That's great news! Sorry for the radio silence, I got the flu yesterday complete with chills and fever, so its hard to even look at my computer screen. I should be better by tomorrow, hopefully, but your good news makes me feel much better. :-)