Fix typos

Author: virtualzavie

approximation.md.html

@@ -6,11 +6,11 @@
 Approximations for constrained implementations
 ==============================================
 
-This specification describes a model which includes a number of features that can be computationnally expensive and therefore impractical to support in certain contexts, like real-time applications or mobile devices.
+This specification describes a model which includes a number of features that can be computationally expensive and therefore impractical to support in certain contexts, like real-time applications or mobile devices.
 
-The Historical background and objectives section explains how the goal of this specification is to provide an ideal, reference appearance. The implementer is, however, free to make decisions and approximations to satisfy their practical constraints. We cannot dictate what those approximations should be, as this depends on the use case. We can, however, propose some possible approximations and offer guidelines to help the implementer make those decisions.
+The Historical background and objectives section explains how the goal of this specification is to provide an ideal, reference appearance. The implementer is, however, free to make decisions and approximations to satisfy their practical constraints. We cannot dictate what those approximations should be, as this depends on the use case. We can, however, propose some possible ones and offer guidelines to help the implementer make those decisions.
 
-As a general rule of thumb, we invite the implementer to think of those approximations in the same way one would think of different levels of detail (LOD) variants of an asset. Just like such an asset would become more coarse with distance while retaining as much detail as necessary to remain faithful to the original, an implementation of OpenPBR may decide to make simplifications, as long as the result remains reasonably faithful to the intent given the practical constraints. In the most extreme hypothetical case, the model might even get reduced to as little as a single Lambert BRDF.
+As a general rule of thumb, we invite the implementer to think of those approximations in the same way one would think of different levels of detail (LOD) variants of an asset. Just like such an asset would become coarser with distance while retaining as much detail as necessary to remain faithful to the original, an implementation of OpenPBR may decide to make simplifications, as long as the result remains reasonably faithful to the intent given the practical constraints. In the most extreme hypothetical case, the model might even get reduced to as little as a single Lambert BRDF.
 
 This means the implementer must carefully consider what to do with parameters they do not plan to fully support. A parameter that drastically modifies the appearance of a material should not be discarded just because the corresponding effect is not supported. As an example, in a renderer that doesn't have subsurface scattering, the subsurface color might be used as the albedo of a diffuse BRDF.
 
@@ -20,7 +20,7 @@
 Layering and mixing
 -------------------------------------
 
-As mentioned in the Reduction to a mixture of lobes section, the mix and layer operations can approximated as a weighted sum of BSDF lobes.
+As mentioned in the Reduction to a mixture of lobes section, the mix and layer operations can be approximated as a weighted sum of BSDF lobes.
 
 
 Specular lobes