It seems that Triangle is not displayed because it does not correspond to the default material.
If material is not specified, default material should be used.
See: https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#default-material

This is Issue separated from #3 (comment)

The textures seem to be loaded using the following formats:

textures/brdfLUT.png  ->sRGB
models/DamagedHelmet/glTF/Default_emissive.jpg  ->sRGB
models/DamagedHelmet/glTF/Default_normal.jpg  ->RGBA
models/DamagedHelmet/glTF/Default_AO.jpg  ->RGBA
models/DamagedHelmet/glTF/Default_albedo.jpg  ->sRGB
models/DamagedHelmet/glTF/Default_metalRoughness.jpg  ->RGBA

the BRDF lookup table seems to be using the sRGB color space. Is this by design?

Implementation should rescale non-power-of-two textures before uploading them to GPU.
BoxTextured sample model contains texture of 211x211.

Just something to consider, in view of KhronosGroup/glTF#738

The current link redirects to the new release of Renderman instead of to the intended article.

Thank you all for this amazing project and the great documentation of each term. It has been very useful for me in learning how to implement PBR in my own engine.

Related pull request: #74

This appears in the live demo, on FireFox 52.1.2, Windows (32bit), GeForce 8800 GT.

Most likely an issue of outdated drivers or so (this is not my "real" PC), but maybe it can or should somehow be handled, I'm not sure how common this extension is.

Stack trace:

TypeError: gl.hasSRGBExt is null[Learn More]  scene.js:230:92
    initTextures http://github.khronos.org/glTF-WebGL-PBR/scene.js:230:92
    Mesh http://github.khronos.org/glTF-WebGL-PBR/scene.js:49:30
    Scene http://github.khronos.org/glTF-WebGL-PBR/scene.js:323:30
    updateModel/<.success http://github.khronos.org/glTF-WebGL-PBR/main.js:86:25
    jQuery.Callbacks/fire http://github.khronos.org/glTF-WebGL-PBR/jquery-3.1.1.js:3305:11
    jQuery.Callbacks/self.fireWith http://github.khronos.org/glTF-WebGL-PBR/jquery-3.1.1.js:3435:7

Does anyone have the bandwidth to clean up some of the core PBR components - and perhaps add some documentations to navigate the code - to help make this repo more friendly for devs?

Some feedback from SIGGRAPH:

It’s a good sample, but it’s a very dense and without much guidance for those who aren’t well versed in shader lighting parlance.

Lots of #ifdefs make for a confusing read and function names like “SmithG1_var2” are completely opaque to the average dev.

For developers who don’t want Image Based Lighting it’s hard to separate out just the analytical lighting bits

I'm trying to understand why pow(color, vec3(1.0 / 2.2)) is used to write final color in this line: https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/master/shaders/pbr-frag.glsl#L316

Is there any formula about this?

Thanks for clarification

Clearly they apply to metal, but no way to just view them on their own. Pretty important part of understanding pbr.

There's a visual artifact in this repo that I haven't seen in BabylonJS or ThreeJS implementations. When the normal vector of a surface points directly at the camera, a small white dot appears. Is this intentional? Is there a light source attached to the camera?

For example, here's a screenshot of BoomBox.gltf. The green arrow points to an expected specular highlight, where a known light source creates a hot spot on the smooth surface of the device. But what does the red arrow point to? It's a smaller hotspot that follows the camera around.

Here's the same effect, on the MetalRoughSpheres model. Note that even the "roughest" spheres create tight hot spots facing the camera at all times. These rough spheres are supposed to be mostly uniform in color, certainly with no tight specular highlights on them.

When I run the live demo from the main repository, the metallic and roughness parameters are always 0. I think that this issue may have come from the most recent pull request. By moving the initialization of the u_MetallicRoughnessValues uniform up, the values are deleted right after in following checks.

The model was added in #32.

The currently used LDR envmap is very overexposed and doesn't do the justice to show the power of the PBR workflow. Has there been consideration to implement full HDR Probes (Radiance) file format parsing or RGBM encoding?

In the vertex shader, the normal is multiplied with the model matrix:

vec3 normalW = normalize(vec3(u_ModelMatrix * vec4(a_Normal.xyz, 0.0)));

However, someone once explained to me that normal vectors should be transformed using the inverse transpose of that matrix (well only if the matrix has non-uniform scaling). See for example this GDC lecure, or this page

Now since glTW does not allow skewing, the inverse transpose matrix might be faster to compute.

Or, instead of using normal vectors, one could use bivectors, these don't have the problems of normal vectors, but that is off topic and experimental I guess :)

Such that specific models can be bookmarked and shared.

The fragment shader has multiple implementations of different parts of the lighting equation.

If someone wants to switch between different implementations, the only way is to edit the fragment shader and reload the page.

It would be great if there was a mechanism for choosing different implementations at runtime, or even editing the math within an implementation and seeing updates immediately.

I can't seem to clone this repo and make a formal pull request, there's something funky with my machine. But, this is a simple fix.

in README.md:
Change "Frensel" to "Fresnel".
Change "youself" to "yourself".

I'd also do "we are able to pick out" to "we can pick out", but that's optional.

I'm sorry this might be off topic. I guess all shaders that render into screen should use gamma correction since most of designer design textures in sRGB color space.
However, the shader used in this repository is not using gamma correction like gl_FragColor = pow(color,vec3(1.0/2.2)).

Is that correct?

The scaling factors like

• https://github.com/KhronosGroup/glTF/tree/2.0/specification/2.0#normaltextureinfoscale
• https://github.com/KhronosGroup/glTF/tree/2.0/specification/2.0#occlusiontextureinfostrength
• (+possibly others)

do not seem to be taken into account. At least, for example the ao (which probably is the occlusion) seems to be read from the texture in https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/master/shaders/pbr-frag.glsl#L259 , and multiplied with the color, unmodified.

(I did not yet dive deeply into the details of the code, for various reasons, but from what I have seen so far, these factors are not supported. Maybe I overlooked them...?)

Load the Damaged Helmet model and rotate the light source around past the front of the helmet. The front visor on the helmet has a sharp edge in the normal map, where we lose the specular highlight for a bit as the light source rotates.

Metal/rough images still show metallic in the red channel instead of blue.

@emackey caught this while reviewing #53.

This implementation should read and correctly use baseColor.alpha, alphaMode, and alphaCutoff, as described in the spec.

Mentioned in #20 (comment)

LYS seems to be great (commercial) tool to generate specular environment maps.

However, it has a lot of properties to tweak.

Would anyone know what the correct settings are to generate glTF PBR specular environment maps?

https://docs.knaldtech.com/doku.php?id=specular_lys

Thanks!
Peter

Since this is a reference implementation, it should be tested against official samples.

Not sure where to ask questions like this... I think it'd get shut down on StackOverflow for being off-topic, and it's a bit too niche to ask generally.

Basically, I'm trying to duplicate the example here in a proprietary but thin API... I've been over and over the settings and I can't see a difference yet in any of the logs, unless maybe it's in how I setup the mipmaps or something (haven't done that manually before)

I thought - maybe someone with a trained eye can see the comparison pictures and can already know where I went wrong.

Here's my image with front and back:

As you can see comparing to the reference page - there's like some missing specular hilight, too much reflection, and other little details. The geometry seems fine.

Any pointers are greatly appreciated!

I do not know what is going to be right, but the results seem to be different between Three.js sample and Khronos sample.

Three.js r86dev + glTF Loader + glTF/BarramundiFish.gltf Result:

Khronos PBR example + glTF/BarramundiFish.gltf Result:

At the moment we don't read or use any sampler settings.

Mentioned in #18.

The code is:

float NdotV = abs(dot(n, v)) + 0.001;

Thanks!

Once the draft extension is finalized, it might be worth including support for KHR_lights here.

Hello,
I tried to open the demo on an android mobile, the model displayed well but I can't navigate around the model.

Thank you

Pretty much anything that is an image (base color and also emissive) should be SRGB and the rest should be interpreted as linear (RGBA)

Also the shader should not be using SRGBtoLINEAR() for every single texture, only for the albedo and the emissive colors.

References:

• https://forum.allegorithmic.com/index.php?topic=8745.0
• http://polycount.com/discussion/193930/substance-designer-linear-vs-srgb-output

I've often thought that the full-roughness, full-metal spheres in the MetalRoughSpheres demo looks much darker than the other 3 extremes. At a SIGGRAPH 2017 course on Physically Based Shading, the last presenters in the group were Christopher Kulla and Alejandro Conty, presenting Revisiting Physically Based Shading at Imageworks [slides] [supplemental].

Pretty early in that slide deck, the authors dig into "Microfacet Energy Compensation" and talk about the problem of rough surfaces losing energy and ways to compensate.

Perhaps we can add some form of energy compensation to this reference shader?

Hi, I tried exporting a simple model with Blender using the glTF-Blender-Exporter add-on. I exported it to .gltf format (also tried exporting it to .glb which gets rendered correctly when loaded in https://gltf-viewer.donmccurdy.com for example). However when I try to load the OfficeChair/glTF/OfficeChair.gltf model within main.js it doesn't gets rendered. I think the model is being parsed because I don't get any error loading it, however it doesn't show up in the viewport. Is this the correct way to load one .gltf file or maybe the format is not correct? I attached the exported file in case you can try to reproduce

OfficeChair.zip

Thanks a lot for the great work!

Are there any plans or intentions to extend the support of other glTF features?

This mainly refers to skinning, which will influence the shaders - although fortunately, it should be possible to clearly separate this, meaning that it should only influence the vertex shader and not the fragment shader. (The fact that the vertex shader will depend on the number of joints would make it a bit tricky, though...)

(To a lesser extent, it could refer to other features, like animations or morph targets etc.)

If there are no such plans, this issue can probably be closed immediately, but maybe the goals and scope of the implementation (regarding these features) could then be pointed out in the README.

I don't want to offend anyone, and I admit that I may have a particularly picky and controversial attitude towards some coding practices. So I don't want to argue about the "style" of something like this....

// diffuse
vec3 disneyDiffuse(PBRInfo pbrInputs)
{
  float f90 = 2.*pbrInputs.LdotH*pbrInputs.LdotH*pbrInputs.roughness - 0.5;

  return (pbrInputs.baseColor/M_PI)*(1.0+f90*pow((1.0-pbrInputs.NdotL),5.0))*(1.0+f90*pow((1.0-pbrInputs.NdotV),5.0));
}
..

// G
float microfacetCookTorrance(PBRInfo pbrInputs)
{
  return min(min(2.*pbrInputs.NdotV*pbrInputs.NdotH/pbrInputs.VdotH, 2.*pbrInputs.NdotL*pbrInputs.NdotH/pbrInputs.VdotH),1.0);
}

But I, personally, think that for a "reference implementation", this should in any case at least include comments about what this code is doing, what its purpose is, and last but not least, information about where this code was copied from. (I'm pretty sure that this was not implemented from scratch based on a given set of formulas, but even then, information about the publications that contain the formulas should not be omitted)

The spec says about double sided lighting:

The doubleSided property specifies whether the material is double sided. When this value is false, back-face culling is enabled. When this value is true, back-face culling is disabled and double sided lighting is enabled. The back-face must have its normals reversed before the lighting equation is evaluated.

I believe the last part is missing and might be solved by something like this in the fragment shader:

v_Normal *= (2.0 * float(gl_FrontFacing) - 1.0);

(avoiding a branch because it wouldn't be cheap in this case I think).

It seems bad form to modify the WebGL context itself:

https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/d8c3e333a13d5abb2e3b52221f5ecd211fb1a003/main.js#L140-L142

Currently, when converting a pixel in the normal map to a tangent-space-normal, the following formula is used:

    vec3 n = texture2D(u_NormalSampler, v_UV).rgb;
    n = normalize(tbn * ((2.0 * n - 1.0) * vec3(u_NormalScale, u_NormalScale, 1.0)));

A unit tangent-space-normal (0,0,1) maps to the RGB value (128,128,255) and vice versa.

But instead (128,128,255) now maps to (128/255*2-1, 128/255*2-1, 255/255*2-1) = (0.004, 0.004, 1).

This slight deviation could be noticable when the reflection vector is used to lookup a pixel in the environment maps at the edges of mirrored triangles (where the tangent.w sign changes).

So instead some advice to multiply with 255.0/128.0 instead of 2.0. See also slide #14 of Crytek's presentation

Note that in most examples JPEG is used to store the normal maps. Due to compression, (128,128,255) is never exactly preserved, so the above theory doesn't fix lossy normal maps...

I guess the advice would be, when using JPEGs for normal maps, don't use mirrored geometry to avoid seams at the edges?

Hi,

It looks like the normals are not correctly calculated. So far I've only checked out the damaged helmet model, I've included some images below to showcase the issue.

On the left side the triangle outline is 'pushed in' the mesh:

On the right side the triangle outline is 'pushed out' the mesh:

Thanks!

https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/master/main.js#L160

Original issue: KhronosGroup/glTF#722

Spec's definition:

I tried the PBR model sample with several browsers.
Windows 10 + Intel HD Graphics 520 + Chrome 58
Windows 10 + Intel HD Graphics 520 + Firefox 53
Windows 10 + Intel HD Graphics 520 + Edge 14

Most models are displayed in Chrome, but some models are not displayed. AppleTree, FarmLandDiorama and Triangle.
Firefox and Edge can not display because EXT_sRGB WebGL extension is not supported.

Why UNPACK_FLIP_Y_WEBGL is false here?
https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/b8128dd1bc8cbd6e165631efbf5f629d3a5b2407/scene.js#L451

glTF 2.0 spec says that it should be true for WebGL:
https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#images

I think they should be the same

If you run the live demo, and you put the lightRotation to 0 and the lightPitch to 90, the calculated light direction is set to [0, 1, 0] because it is calculated as [Math.sin(rot) * Math.cos(pitch),
Math.sin(pitch),
Math.cos(rot) * Math.cos(pitch)].

This means a light shining upwards. However, if you look at the render, the light is actually shining downwards. This is because, in the calculation of the specular reflection, you forgot to invert the light direction (line 252 in pbr-frag.glsl):

    vec3 n = getNormal();                             // normal at surface point
    vec3 v = normalize(u_Camera - v_Position);        // Vector from surface point to camera
    vec3 l = normalize(u_LightDirection);             // Vector from surface point to light
    vec3 h = normalize(l+v);                          // Half vector between both l and v
    vec3 reflection = -normalize(reflect(v, n));

    float NdotL = clamp(dot(n, l), 0.001, 1.0);
    float NdotV = abs(dot(n, v)) + 0.001;
    float NdotH = clamp(dot(n, h), 0.0, 1.0);
    float LdotH = clamp(dot(l, h), 0.0, 1.0);
    float VdotH = clamp(dot(v, h), 0.0, 1.0);

The actual line should be:

vec3 l = normalize(-u_LightDirection); // Vector from surface point to light

Looking at the brdfLUT.png map (the original one, not the modified one in #18), @abwood and I experimented with contrast-enhancing the image to look for irregularities. All four borders of the image have 1-pixel-thick discontinuous irregularities. In a few cases, such as the lower-right and lower-left corners, these are visible to a trained naked eye. But with contrast adjustments, a 1-pixel border around the entire image becomes visible.

I will try to post some screenshots of these findings later today or tomorrow. In the meantime, I'm curious how this image was created, if it can be regenerated, or if the repo here could actually generate this image with a pre-render pass at runtime?

/cc @moneimne

I am not entirely sure, but think that the line https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/2c5c5f446ed3649315b4fdbf196131af7ffa543b/shaders/pbr-vert.glsl#L39 which currently is

v_Normal = normalize(vec3(u_ModelMatrix * a_Normal));

should in fact be

v_Normal = normalize(vec3(u_ModelMatrix * vec4(a_Normal.xyz, 0.0)));

Otherwise, the normals are translated when the model matrix contains a translation component.

This popped up when @emackey and I were reviewing #18. As it stands with a min roughness of 0.04, the bottom 10 pixels are ignored from the brdf_LUT.

From the shader, we lookup into the brdf_LUT using the following:
vec3 brdf = texture2D(u_brdfLUT, vec2(NdotV, 1.0 - roughness)).rgb;

With a min roughness of 0.04, the largest y value we can get is 0.96 (1.0 - 0.04). Note that in webgl the y value is inverted, meaning that a y of 1.0 will index into the bottom of the image. Since the brdf_LUT is 256x256, we're unable to access the bottom 10 pixels of the image.

I may need to create the similar ones with some new images. I notice that the IBL baker can only export dds format with HDR/MDR images. How do you convert the dds file into individual cube map image and convert the HDR/MDR to jpg format?

Thank you.

I just noticed that there's a footnote in the Epic paper regarding their brdfLUT. They suggest storing the computed LUT in R16G16 for the sake of maintaining precision. This would be useful to the community to generate this format and have available in this repo.

http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_notes_v2.pdf
Figure 3
We use an R16G16 format, since we found precision to be important.

The concept of PBR's spec/gloss is already here, and the conversion to it from metal/rough is hard-coded:

    vec3 f0 = vec3(0.04);
    vec3 diffuseColor = baseColor.rgb * (vec3(1.0) - f0);
    diffuseColor *= 1.0 - metallic;
    vec3 specularColor = mix(f0, baseColor.rgb, metallic);

To support the KHR_materials_pbrSpecularGlossiness, we just need a conditional around this, and the ability to parse that extension, loading its maps directly here without this transformation.

/cc CesiumGS/gltf-pipeline#331