erichlof / THREE.js-PathTracing-Renderer

Real-time PathTracing with global illumination and progressive rendering, all on top of the Three.js WebGL framework. Click here for Live Demo: https://erichlof.github.io/THREE.js-PathTracing-Renderer/Geometry_Showcase.html
Creative Commons Zero v1.0 Universal
1.88k stars 171 forks source link

GLTF viewer textures #70

Closed lucassel closed 1 year ago

lucassel commented 1 year ago

Hi, first of all: eternal thanks for creating +maintaining such a crazy project :)

I am trying to work with the GLTF viewer scene and having difficulties assigning materials. I did a quick debug and even though my .gltf file has textures and they are passed along to the path tracing material, none of them want to show up in the scene. There is code pointing to unique albedo textures, yet the example GLTF files do not own any albedo textures as far as I am aware?

Could you possibly point me in the right direction please? Thanks in advance <3

erichlof commented 1 year ago

@lucassel Hello and thank you for the kind words!

Regarding setting and using different albedo material textures, I'm afraid that this part of my path tracing system isn't quite functional yet. In fact, on the glTF model viewer demo that you've been working with, if you comment out all of the texture handling code in GLTF_Model_Viewer.js from around line 225 to 273, the demo still works perfectly, with the various green and red and white colors on the doors, walls, and window frames of the supplied glTF cutaway apartment model. This works because, although the 'plumbing' for multiple textures is sort of in place, it is not fully connected between the js file and the glsl shader file which does the actual path tracing (and albedo texture fetches).

The reason why the different colors for different parts of the apartment model show up at all on that demo is that the original author (not me, this is the only demo I didn't create from scratch, but I still maintain it) hand modeled it and stored different colors for some of the apartment pieces. He then successfully extracts the various apartment components' rgb color info and puts it into the 'pathTracingMaterialList' object array, in the 'color' member which itself has color.r, color.g, and color.b. So all this is to say that the current demo is not really loading any textures at all.

That said, if you take a look at my BVH_Animated_Model demo, it does in fact successfully load a single albedo texture for the popular 'Damaged Helmet' glTF model, as well as its emissiveMap, normalMap, and metallicRoughnessMap. Although you could consider this as 'loading multiple textures', it's not truly, because each texture covers the entire model and they all overlap perfectly. I wouldn't know how to change just part of a glTF model like that, say the glass part of the face mask, or the rubber hoses underneath the helmet, because it is a large all-encompassing single texture for each function (albedo, normal, metallicRoughness, emissive). So if you have a preset glTF with large single textures that are uv unwrapped and cover the entire model, you can use my code for that demo, and everything should work the same as my example.

In order to do multiple diffuse albedo, let alone multiple normal, multiple metallicRoughness, etc. maps, will require much more thoughtfulness and planning. You can sort of see the pieces in his glTF Model Viewer demo, but as it stands now, nothing gets actually sent over to the GPU, and the shader code has no functions yet to sample the different textures by their albedoTextureID. I kind of know how it might be implemented, but this is why there are teams of programmers behind path tracing engines that can arbitrarily load and edit models and materials on the fly (Blender Cycles or VRay come to mind). I'm sure one (or more) person's task is just getting model/material loading and editing working, ha.

From the very beginning of this project, I have been fascinated with the nuts and bolts of the actual Ray Tracing and global illumination side of things - hence all my references and demos that showcase historical breakthroughs (like Appel, Whitted, Kajiya, and Veach). But I realize that, to be useful to a wider user base, I will eventually have to get model and material loading working fully and correctly. It is mainly just me working on this large project, on stuff that I find interesting, but I'd be open for someone to come along and take over the glTF loading and material handling side of things. We all have weaknesses in our knowledge base, and that is mine. glTF loading and materials is necessary, but hasn't been as fascinating as something like Bi-Directional path tracing has been, for me anyway. But if someone who likes that side of things does a PR, I would gladly work with them and try to pull in the changes, so that we could all benefit. :-)

Sorry to disappoint you with the state of loading/editing multiple textures, but hopefully you now know why things are how they currently are. If you have any more questions, please let me know. Thanks!

-Erich

lucassel commented 1 year ago

Hi Erich,

Thanks for your detailed answer, I now better understand how the mesh colors are fed to the shader in that specific scene. I already had somewhat of a go at merging the GLTF viewer and BVH Animated scene, looks like I was on the right track.

To clarify: I am not at all dissapointed at the texture loading, just a little confused 😄

Will this project be the one that finally pushes me to learn GLSL? Looks like it 😉

Cheers!

erichlof commented 1 year ago

@lucassel Glad I could clarify the situation - yeah having the ability to change materials and have multiple textures would be great. It's definitely something I would like to have in the future. Either I'll have to wrestle with it myself, or someone will come along who is comfortable with loading, processing and organizing texture files to be rendered on the fly, and maybe will help steer us in the right direction.

About learning GLSL, I think it would be definitely worth the time. Over my 38 years of programming, I have spent varying amounts of time with many languages - BASIC, Pascal, C, C++, C#, JavaScript, and GLSL. Of all these, I actually enjoy working in GLSL the most. It hits all the right points of what a language should be: robust, but not too verbose, relatively few key words but at the same time powerful and expressive, not too much visual noise in the syntax(ahem, C++ I'm looking at you), compiled with strong variable types like float and int so you know exactly how much memory/resources you're using, and handy built in math/vector functions like mix(), dot(), cross(), and normalize(), etc. It has all the preprocessor stuff C has, and the ability to create functions, structures, arrays, etc. It also hides all of the pointer stuff which can get very visually noisy, like in C.

If I were to be tasked with designing a new programming language, I would probably start out with GLSL in mind - that's how good I think it is. Plus, if you know GLSL, you can easily pick up HLSL, if you ever have to work with DirectX-related code. Lastly, judging by how slowly the web graphics standards have changed (like WebGL and its GLSL), you'll be able to work with and read GLSL for many years (until WebGPU and its WGSL take over - but that will require agreement amongst all browser vendors, which will take years). ;-)

A good place to start learning is by watching some of the Art of Code channel on YouTube. Martin is an excellent instructor and he really knows his stuff about GLSL, way more than I ever will. He has some good intro videos from years back that are worth checking out if you wanted to start getting into it. Also I hear the Book of Shaders is a really good online resource, although I don't have any personal experience with that website.

Best of luck with your shader/rendering pursuits! -Erich