Spelling and spacing fixes (#2184)

This changelist implements spelling and spacing fixes across the MaterialX repository, leveraging the `codespell` project and manual inspection.

GOVERNANCE.md

@@ -10,12 +10,12 @@ TSC responsibilities include, but are not limited to:
 
 - Discussions, seeking consensus, and where necessary, voting on technical
   matters relating to MaterialX that affect multiple projects.
-- Maintainance and administration of the MaterialX GitHub repository.
+- Maintenance and administration of the MaterialX GitHub repository.
 - Coordinating technical direction of the project.
-- Coordinatng marketing, events, and communications regarding MaterialX.
+- Coordinating marketing, events, and communications regarding MaterialX.
 
 Within the TSC there are two key subgroups: **Voting Members**, who take on
-formal responsibiities for maintaining the MaterialX project and vote when
+formal responsibilities for maintaining the MaterialX project and vote when
 decisions are required; and **Stakeholders**, who represent specific teams and
 companies in the industry and speak on their behalf in MaterialX discussions.
 

documents/DeveloperGuide/GraphEditor.md

@@ -1,4 +1,4 @@
-# MaterialX Graph Editor 
+# MaterialX Graph Editor
 
 The MaterialX Graph Editor is an example application for visualizing, creating, and editing MaterialX graphs.  It utilizes the ImGui framework as well as additional ImGui extensions such as the Node Editor.
 
@@ -14,7 +14,7 @@ Select the `MATERIALX_BUILD_GRAPH_EDITOR` option in CMake to build the MaterialX
 ## Summary of Graph Editor Features
 
 1. **`Load Material`**: Load a material document in the MTLX format.
-2. **`Save Material`**: Save out a graph as a mterial document in MTLX format.
+2. **`Save Material`**: Save out a graph as a material document in MTLX format.
 3. **`New Material`**: Clear all information to set up for the creation of a new material
 4. **`Node Property Editor`**: View or edit properties of the selected node.
 5. **`Render View`**: View the rendered material.
@@ -23,35 +23,35 @@ Select the `MATERIALX_BUILD_GRAPH_EDITOR` option in CMake to build the MaterialX
 
 To display a new material and graph, click the `Load Material` button and and navigate to the [Materials/Examples](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Materials/Examples) folder, which contains a selection of materials in the MTLX format, and select a document to load.  The Graph Editor will display the graph hierarchy of the selected document for visualization and editing.
 
-To save out changes to the graphs as MTLX files click the `Save Material` button.  This will save the position of the nodes in the graph for future use as well. 
+To save out changes to the graphs as MTLX files click the `Save Material` button.  This will save the position of the nodes in the graph for future use as well.
 
 ## Editor Window
 
-The MaterialX document is displayed as nodes in the Editor window.  When a file is intially loaded the material node, surface shader node, and any enclosing nodegraphs will be displayed.  Double-clicking on a nodegraph, or any node defined as a subgraph, will display the contents of that graph.
+The MaterialX document is displayed as nodes in the Editor window.  When a file is initially loaded the material node, surface shader node, and any enclosing nodegraphs will be displayed.  Double-clicking on a nodegraph, or any node defined as a subgraph, will display the contents of that graph.
 
 The current graph hierarchy is displayed above the editor.  To back up and out of a subgraph click the `<` button to the left of the graph names.
 
-Each node and nodegraph displays its name and pins for all of its inputs and outputs.  Nodes can be connected by clicking on the output pin of one node and connecting it to the input pin of another node, thus creating a link.  Links can only be created if the input and output pins have the same type, as designated by the color of the pin.  When a new link is created the material in the render view will automatically be updated. 
+Each node and nodegraph displays its name and pins for all of its inputs and outputs.  Nodes can be connected by clicking on the output pin of one node and connecting it to the input pin of another node, thus creating a link.  Links can only be created if the input and output pins have the same type, as designated by the color of the pin.  When a new link is created the material in the render view will automatically be updated.
 
-Using the tab key on the editor allows the user to add a certain node by bringing up the `Add Node` pop-up.  The nodes are organized in the pop-up window based on their node group but a specfic node can also be searched for by name.  To create a nodegraph select `Node Graph` in the `Add Node` popup and dive into the node in order to add nodes inside of it and populate it. 
+Using the tab key on the editor allows the user to add a certain node by bringing up the `Add Node` pop-up.  The nodes are organized in the pop-up window based on their node group but a specific node can also be searched for by name.  To create a nodegraph select `Node Graph` in the `Add Node` popup and dive into the node in order to add nodes inside of it and populate it.
 
-In order to connect to the nodegraph to a shader add output nodes inside the nodegraph then travel back up outside the nodegraph and connect the corresponding output pin to the surface shader.  By default, the nodegraph does not contain any output nodes or pins. 
+In order to connect to the nodegraph to a shader add output nodes inside the nodegraph then travel back up outside the nodegraph and connect the corresponding output pin to the surface shader.  By default, the nodegraph does not contain any output nodes or pins.
 
 Another type of node present in the `Add Node` pop-up is the group, or background node.  This background node can be used to group specific nodes and label by them by dragging them on to the background node.
 
-To search the editor window for a specific node use `CTRL` + `F` to bring up the search bar. 
+To search the editor window for a specific node use `CTRL` + `F` to bring up the search bar.
 
 ## Node Property Editor
 When a node is selected in the graph, its information is displayed on the left-hand column in the `Node Property Editor`.  This editor displays the name of the node, its category, its inputs, the input name, types and values.  Inputs that are connected to other nodes will not display a value.
 
 This is where a node's properties such as its name and input values can be adjusted.  When an input value is changed the material is automatically updated to reflect that change.  The node info button displays the `doc` string for the selected node and its inputs if they exist. This `doc` string is currently read only.
 
-The show All Inputs checkbox displays all possible inputs for a node. With the box unchecked only inputs that have a connection or have had a value set will be shown. Only these inputs will be saved out when the graph is saved. 
+The show All Inputs checkbox displays all possible inputs for a node. With the box unchecked only inputs that have a connection or have had a value set will be shown. Only these inputs will be saved out when the graph is saved.
 
 ## Render View
 Above the `Node Property Editor`, the `Render View` displays the current material on the Arnold Shader Ball.  If inside a subgraph it will display the material associated with that subgraph; otherwise it will display the output of the selected node.  It automatically updates when any changes are made to the graph.
 
-To adjust the relative sizes of the Node Property Editor and Render View windows, drag the separator between these windows in the application. The render view window camera can be changed using the left or right mouse buttons to manipulate the shader ball. 
+To adjust the relative sizes of the Node Property Editor and Render View windows, drag the separator between these windows in the application. The render view window camera can be changed using the left or right mouse buttons to manipulate the shader ball.
 
 ## Keyboard Shortcuts
 

documents/DeveloperGuide/ShaderGeneration.md

@@ -210,7 +210,7 @@ ShaderPtr ShaderGenerator::generate(const string& name,
 The shader generation process can be divided into initialization and code generation. The initialization consists of a number of steps:
 1. Create an optimized version of the graph as a tree with the given input element as root, and with only the used dependencies connected upstream. This involves removing unused paths in the graph, converting constant nodes to constant values, and adding in any default nodes for ports that are unconnected but have default connections specified. Removal of unused paths typically involves constant folding and pruning of conditional branches that will never be taken. Since the resulting shader in the end will be compiled by a shading language compiler, and receive a lot of additional optimizations, we don’t need to do too much work in this optimization step. However, a few graph level optimizations can make the resulting shader a lot smaller and save time and memory during shader compilation. It will also produce more readable source code which is good for debugging purposes. This optimization step is also a good place to do other custom optimizations needed by a particular target. For example simplification of the graph, which could involve substituting expensive nodes with approximate nodes, identification of common subgraphs that can be merged, etc.
 2. The nodes are sorted in topological order. Since a node can be referenced by many other nodes in the graph we need an ordering of the nodes so that nodes that have a dependency on other nodes come after all dependent nodes. This step also makes sure there are no cyclic dependencies in the graph.
-3. The stages for the shader are created. For a HW shader this is normally a vertex stage and a pixel stage, but other stages can be added as needed. At the minumum a single pixel stage is required, so even shaders that has no concept of multiple stages, like OSL, needs to have a single pixel stage created.
+3. The stages for the shader are created. For a HW shader this is normally a vertex stage and a pixel stage, but other stages can be added as needed. At the minimum a single pixel stage is required, so even shaders that has no concept of multiple stages, like OSL, needs to have a single pixel stage created.
 4. The shader stages interface of uniforms and varyings are established. This consists of the graph interface ports that are in use, as well as internal ports that have been published to the interface (an example of the latter is for a hardware shader generator where image texture filenames get converted to texture samplers which needs to be published in order to be bound by the target application). Each node in the graph is also called for a chance to create any uniforms or varyings needed by its implementation.
 5. Information about scope is tracked for each node. This information is needed to handle branching by conditional nodes. For example, if a node is used only by a particular branch on a varying conditional we want to calculate this node only inside that scope, when that corresponding branch is taken. A node can be used in global scope, in a single conditional scope or by multiple conditional scopes.
 
@@ -230,7 +230,7 @@ Note that if a single monolithic shader for the whole graph is not appropriate f
 
 ## 1.5 Shader Stages
 
-Creation of multiple shader stages is supported. This is needed in order to generate separate code for multiple stages on hardware render targets. A `pixel` stage must always be created by all targets, even for shading languages like OSL that natively doensn't have a concept of stages. The stage is where the generated shader code is stored as well as all uniforms, inputs and outputs for the shader. This is handled by the `ShaderStage` class, and the data can be retrieved from it when generation is completed.
+Creation of multiple shader stages is supported. This is needed in order to generate separate code for multiple stages on hardware render targets. A `pixel` stage must always be created by all targets, even for shading languages like OSL that natively doesn't have a concept of stages. The stage is where the generated shader code is stored as well as all uniforms, inputs and outputs for the shader. This is handled by the `ShaderStage` class, and the data can be retrieved from it when generation is completed.
 
 One or more `ShaderStage` instances are created and stored on the `Shader` class. In addition to the `pixel` stage, hardware generators always specify a `vertex` stage. If additional stages are needed they can be added as well. When creating shader input variables you specify which stage the variable should be used in, see 1.7 for more information on shader variable creation.
 

documents/DeveloperGuide/Viewer.md

@@ -65,7 +65,7 @@ Shadow maps from the primary directional light may be enabled with the `Shadow M
 
 ## Images
 
-By default, the MaterialX viewer loads and saves image files using `stb_image`, which supports commmon 8-bit formats such as JPEG, PNG, TGA, and BMP, as well as the HDR format for high-dynamic-range images.  If you need access to additional image formats such as EXR and TIFF, then the MaterialX viewer can be built with support for `OpenImageIO`.  To build MaterialX with OpenImageIO, check the `MATERIALX_BUILD_OIIO` option in CMake, and specify the location of your OpenImageIO installation with the `MATERIALX_OIIO_DIR` option.
+By default, the MaterialX viewer loads and saves image files using `stb_image`, which supports common 8-bit formats such as JPEG, PNG, TGA, and BMP, as well as the HDR format for high-dynamic-range images.  If you need access to additional image formats such as EXR and TIFF, then the MaterialX viewer can be built with support for `OpenImageIO`.  To build MaterialX with OpenImageIO, check the `MATERIALX_BUILD_OIIO` option in CMake, and specify the location of your OpenImageIO installation with the `MATERIALX_OIIO_DIR` option.
 
 ## Keyboard Shortcuts
 

documents/Specification/MaterialX.GeomExts.md

@@ -196,9 +196,9 @@ Either a `geom` or a `collection` may be specified, but not both.
 
 ### GeomProp Elements
 
-The core MaterialX Specification defines a Geometric Property, or "geomprop", as an intrinsic or user-defined surface coordinate property of geometries referenced in a specific space and/or index, and provides several nodes to retrive the values of these properties within a shading network nodegraph, as well as a <geompropdef> element used to define the name and output type of custom geometric properties beyond the standard ones: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`.
+The core MaterialX Specification defines a Geometric Property, or "geomprop", as an intrinsic or user-defined surface coordinate property of geometries referenced in a specific space and/or index, and provides several nodes to retrieve the values of these properties within a shading network nodegraph, as well as a <geompropdef> element used to define the name and output type of custom geometric properties beyond the standard ones: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`.
 
-MaterialX Geometry Extensions expands upons this by allowing the use of <geomprop> elements to define specific uniform values of a geometric property with specific geometries, as opposed to relying on those values being defined externally.  This could include application-specific metadata, attributes passed from a lighting package to a renderer, or other geometry-specific data.  A geomprop may also specify a `unittype` and `unit` if appropriate to indicate that the geometric property's value is in that unit; see the [**Units** section of the main MaterialX Specification](./MaterialX.Specification.md#units), although typically the <geompropdef> would define the `unittype` and `unit`, and a geomprop would only provide an overriding `unit` if the unit for its value differed from the geompropdef's defined default unit.
+MaterialX Geometry Extensions expands upon this by allowing the use of <geomprop> elements to define specific uniform values of a geometric property with specific geometries, as opposed to relying on those values being defined externally.  This could include application-specific metadata, attributes passed from a lighting package to a renderer, or other geometry-specific data.  A geomprop may also specify a `unittype` and `unit` if appropriate to indicate that the geometric property's value is in that unit; see the [**Units** section of the main MaterialX Specification](./MaterialX.Specification.md#units), although typically the <geompropdef> would define the `unittype` and `unit`, and a geomprop would only provide an overriding `unit` if the unit for its value differed from the geompropdef's defined default unit.
 
 ```xml
     <geomprop name="propname" type="proptype" value="value"/>

documents/Specification/MaterialX.PBRSpec.md

@@ -407,7 +407,7 @@ Note that the standard library includes definitions for [**`displacement`**](./M
 
 <a id="node-chiang-hair-absorption-from-color"> </a>
 
-* **`chiang_hair_absorption_from_color`** : Coverts the hair scattering color to absorption coefficient using the mapping method described in [^Chiang2016]. Output type `vector3`.
+* **`chiang_hair_absorption_from_color`** : Converts the hair scattering color to absorption coefficient using the mapping method described in [^Chiang2016]. Output type `vector3`.
     * `color` (color3): Scattering color. Defaults to (1.0, 1.0, 1.0).
     * `azimuthal_roughness` (float): Azimuthal roughness, range [0.0, 1.0]. Defaults to 0.2.
 

documents/Specification/MaterialX.Specification.md

@@ -1544,7 +1544,7 @@ Adjustment nodes have one input named "in", and apply a specified function to va
     * `gain` (float): Multiplier increases lighter color values, leaving black values unchanged; default is 1.
     * `contrast` (float): Linearly increase or decrease the color contrast; default is 1.
     * `contrastpivot` (float): Pivot value around which contrast applies. This value will not change as contrast is adjusted; default is 0.5.
-    * `exposure` (float): Multplier which increases or decreases color brightness by 2^value; default is 0.
+    * `exposure` (float): Multiplier which increases or decreases color brightness by 2^value; default is 0.