Is MeshStandardMaterial intended as a replacement for Phong and Lambert

I’m updating the materials docs, and reading through old pull requests, it seems like at least at one point
MeshStandardMaterial was intended as a replacement for Phong and Lambert materials.

Is this still the case? And if so should I add a note of this in the docs?

Apologies if this has been previously discussed elsewhere.

Author: Fantashit

7 thoughts on “Is MeshStandardMaterial intended as a replacement for Phong and Lambert

  1. With MeshLambertMaterial, the illumination model is Lambertian, and the shading model is Gouraud. That is, the illumination calculation is performed at each vertex, and the resulting color is interpolated across the face of the polygon. Some users like it because it is more performant, especially on slower devices.

    With MeshPhongMaterial, the illumination model is the Blinn-Phong model, and the shading model is Phong. That is, the vertex normals are interpolated across the surface of the polygon, and the illumination calculation is performed at each texel.

    MeshPhongMaterial is not physically-based. In fact, MeshToonMaterial, a classic non-physically-based (NPR) material, extends MeshPhongMaterial.

    MeshStandardMaterial also uses Phong per-pixel shading, but it uses a micro facet-based, and physically-based, illumination model. It is intended to be an easy-to-use PBR material.

    MeshPhysicalMaterial is a more-flexible version of MeshStandardMaterial. I fully expect MeshPhysicalMaterial to be further enhanced in the future — for example, adding anisotropy.

    Not all users want a computationally intensive PBR material, so I would not consider MeshStandardMaterial to be a replacement for anything at this point.

  2. Also, MeshStandardMaterial and MeshPhysicalMaterial work best when an environment map (envMap) is specified. This is so there is something to reflect. I would point this out in the docs, and always specify an environment map whenever these materials are used in either the examples or the documentation examples.

    At some point, we will add support (at least for the physically-based materials) for image-based lights, of which environment maps are a special case.

  3. Is this related to the WebGLRenderer.physicallyCorrectLights toggle?

    @looeee WebGLRenderer.physicallyCorrectLights was implemented by @bhouston to provide physical SI units to the intensity parameter of each light type. My understanding is it is a work-in-progress, but it is an excellent contribution, IMHO.

    Can you recommend papers, articles or books about physically based rendering?

    @Mugen87 There are so many… I think this is a fine compilation.

  4. @Mugen87 I found a couple of articles from the guys at that give a great non-technical overview of PBR and how to use it:

    @mrdoob, @WestLangley I’d like to link those two articles in the docs, do you think that would be OK?

    @WestLangley what I’ve gathered so far is that PBR is a concept rather than a specific implementation. Can you provide any details of how it’s implemented here? Not asking for any major technical details, just enough to give some explanation of how the material works in the docs. Especially:

    • does it use energy conservation?
    • is Fresnel reflection calculated automatically from the Reflectivity and Roughness?
    • is it similar to the approach used by Unity or Unreal?
  5. BTW PBR is generally monochromatic energy conserving. BlinnPhong energy conserving is discussed here: #9248

    Fresnel reflections are calculated correctly in this Physical material – or at least they are to my knowledge (there my be bugs.)

    The specific implementation that ThreeJS follows is very similar to the Physical material in UE4 in terms of its parameterization. Almost all PBR models are based on the Disney PBR paper by Burley:

    The physically correct lights I believe are also correct to the best of my knowledge (e.g., there may be bugs.)

    Physically correct lights work with both Standard (BlinnPhong model) as well as the Physical (GGX, Roughness/Metalic parameterization).

Comments are closed.