Update jme3_shadernodes.adoc

Fixed improperly formatted bold emphasis when using with the Triple-plus passthrough.
Fixed broken new lines breaks.
Fixed punctuation errors.

src/docs/asciidoc/jme3/advanced/jme3_shadernodes.adoc

@@ -57,7 +57,7 @@ Please refer to this documentation for global structure of a j3md file
 
 All is included in a *ShaderNodeDefinitions* bloc. This block can have several nodes defined (it's recommended to define nodes that have strong dependencies with each other in the same j3sn file). +
 A ShaderNode is declared in a *ShaderNodeDefinition* block. +
-global structure should look like this : 
+The global structure should look like this : 
 
 [source,java]
 ----
@@ -114,13 +114,15 @@ All that is not between [] is mandatory.
 **  *GlslVarType* : a valid glsl variable type that will be used in the shader for this input. see link:http://www.opengl.org/wiki/GLSL_Type[http://www.opengl.org/wiki/GLSL_Type] and the “Declare an array chapter
 **  *VarName* : the name of the variable. Note that you can't have several outputs with the same name.
 
-
-* Note that if you use the same name for an input and an ouput, the generator will consider them as the SAME variable so they should be of the same glsl type.*
+[NOTE]
+====
+If you use the same name for an input and an ouput, the generator will consider them as the SAME variable so they should be of the same glsl type.
+====
 
 
 === Example
 
-Here is a typical shader node definition
+Here is a typical shader node definition.
 
 [source,java]
 ----
@@ -154,7 +156,7 @@ ShaderNodeDefinitions{
 
 To declare an array you have to specify its size between square brackets. +
 *Constant size* +
-The size can be an int constant +
+The size can be an int constant. +
 _Example_
 
 [source]
@@ -164,7 +166,7 @@ _Example_
 
 ----
 
-this will declare a float array with 10 elements.
+This will declare a float array with 10 elements.
 Any material parameter mapped with this array should be of FloatArray type and it's size will be assumed as 10 when the shader is generated. 
 
 *Material parameter driven size* +
@@ -190,7 +192,7 @@ If this value change the shader will have to be recompiled, due to the fact that
 == Shader Node code
 
 The shader code associated with a Shader node is similar to any shader code. +
-the code for a Vertex shader node should be in a .vert file and the code for a Fragment shader node should be in a .frag file.
+The code for a Vertex shader node should be in a .vert file and the code for a Fragment shader node should be in a .frag file.
 It has a declarative part containing variable declaration, function declaration and so on… And a main part that is embed in a “void main(){} block. +
 Input and output variables declared in the shader node definition can be used *without* being declared in the shader code. ( they shouldn't even or you'll have issues). +
 Here is a the code of the LightMap.frag shader. 
@@ -235,9 +237,9 @@ ShaderNode <ShaderNodeName>{
 ----
 
 *  +++<u>ShaderNode</u>+++ the shader node block
-**  *ShaderNodeName* the name of this shader node, can be anything, but has to be *unique* in the shader scope
+**  *ShaderNodeName* the name of this shader node, can be anything, but has to be *unique* in the shader scope.
 
-*  +++<u>Definition</u>+++ : a reference to the shader node definition
+*  +++<u>Definition</u>+++ : a reference to the shader node definition.
 **  *DefinitionName* : the name of the definition this Node use. this definition can be declared in the same j3md or in its own j3sn file.
 **  *DefinitionPath* : in case the definition is declared in it's own j3sn file, you have to set the path to this file here.
 
@@ -257,11 +259,11 @@ For example, let's say we have a Color and ColorMap material parameter, this con
 
 *  +++<u>InputMapping</u>+++ the wiring of the inputs of this node, coming from previous node's outputs or from built in glsl inputs.
 **  *InputVariableName* : the name of the variable to map as declared in the definition.
-**  *Swizzle* : Swizling for the preceding variable. More information on glsl swizzling on this page link:http://www.opengl.org/wiki/GLSL_Type[http://www.opengl.org/wiki/GLSL_Type]
+**  *Swizzle* : Swizling for the preceding variable. More information on glsl swizzling on this page link:http://www.opengl.org/wiki/GLSL_Type[http://www.opengl.org/wiki/GLSL_Type].
 **  *NameSpace* : The generator will use variable name space to avoid collision between variable names. Name space can be one of these values : 
-***  *MatParam* : the following variable is a Material Parameter declared in the MaterialParameters block of the materialDefinition
+***  *MatParam* : the following variable is a Material Parameter declared in the MaterialParameters block of the materialDefinition.
 ***  *WorldParam* : the following variable is a World Parameter declared in the WorldParameters block of the current technique block. World parameters can be one of those declared in this file : link:https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/shader/UniformBinding.java[https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/shader/UniformBinding.java]
-***  *Attr* : the following variable is a shader attribute. It can be one those declared in the Type enum of the VertexBuffer class link:https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/scene/VertexBuffer.java[https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/scene/VertexBuffer.java]
+***  *Attr* : the following variable is a shader attribute. It can be one those declared in the Type enum of the VertexBuffer class link:https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/scene/VertexBuffer.java[https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/scene/VertexBuffer.java].
 ***  *Global* : the variable is a global variable to the shader. Global variables will be assign at the end of the shader to glsl built in outputs : gl_Position for the vertex shader, or to one of the possible outputs of the fragment shader (for example  gl_FragColor). The global variable can have what ever name pleases you, it will assigned in the order they've been found in the declaration to the shader output. *Global variables can be inputs of a shader node. Global variables are forced to be vec4 and are defaulted to the value of the attribute inPosition in the vertex shader and vec4(1.0)(opaque white color) in the fragment shader*.
 ***  *The name of a previous shader node* : this must be followed by and output variable of a the named shader node. This is what allows one to plug outputs from a node to inputs of another.
 
@@ -270,7 +272,7 @@ For example, let's say we have a Color and ColorMap material parameter, this con
 
 *  +++<u>OutputMapping</u>+++ : This block is optional, as mapping of output will be done in input mapping block of following shaderNodes, ecept if you want to output a value to the Global output of the shader.
 **  *NameSpace* : the name space of the output to assign, this can only be “Global here.
-**  *VarName* : the name of a global output (can be anything, just be aware that 2 different names result in 2 different outputs)
+**  *VarName* : the name of a global output (can be anything, just be aware that 2 different names result in 2 different outputs).
 **  *OutputVariable* : Must be an output of the current node's definition.
 **  *MappingCondition* : Same as before.
 
@@ -375,7 +377,7 @@ ShaderNodesDefinitions {
 Note that texCoord1/2 and vertColor are declared both as input and output. The generator will use the same variables for them.
 ====
 
-Here is the shader Node code ( Common/MatDefs/ShaderNodes/Common/commonVert.vert)
+Here is the shader Node code ( Common/MatDefs/ShaderNodes/Common/commonVert.vert).
 
 [source,java]
 ----
@@ -388,8 +390,8 @@ void main(){
 
 As you can see all the inputs and outputs are not used. That's because most of them are attributes meant to be passed to the fragment shader as varyings. All the wiring will be handled by the generator only if those variables are used in an input or output mapping.
 
-+++<u>*CommonVert input mapping*</u>++++
-Here we have the most basic yet mandatory thing in a vertex shader, computing vertex position in projection space. for this we have 2 mappings :
+*+++<u>CommonVert input mapping</u>+++* +
+Here we have the most basic yet mandatory thing in a vertex shader, computing vertex position in projection space. For this we have 2 mappings :
 
 *  *worldViewProjectionMatrix = WorldParam.WorldViewProjectionMatrix* : the input parameter worldViewProjectionMatrix is assigned with the WorldViewProjectionMatrix World parameter declared in the WorlParameters block of the technique.
 *  *modelPosition = Global.position.xyz* : the modelPosition (understand the vertex position in the model coordinate space) is assigned with the Global position variable.
@@ -408,12 +410,12 @@ modelPosition = Attr.inPosition.xyz
 
 [TIP]
 ====
-Also note the swizzle of the Global.position variable. modelPosition is a vec3 and GlobalPosition is a vec4 so we just take the first 3 components.
+Also note the swizzle of the Global.position variable. ModelPosition is a vec3 and GlobalPosition is a vec4 so we just take the first 3 components.
 ====
 
-+++<u>*CommonVert output mapping*</u>++++
+*+++<u>CommonVert output mapping</u>+++* +
 
-*  *Global.position = projPosition* : The result of the multiplication of the worldViewProjectionMatrix  and the modelPosition is assigned to the Globale position
+*  *Global.position = projPosition* : The result of the multiplication of the worldViewProjectionMatrix and the modelPosition is assigned to the Globale position.
 
 
 [TIP]
@@ -421,9 +423,9 @@ Also note the swizzle of the Global.position variable. modelPosition is a vec3 a
 The Global.position variable will be assigned to the gl_Position glsl built in output at the end of the shader.
 ====
 
-+++<u>*ColorMult Definition*</u>++++
+*+++<u>ColorMult Definition</u>+++* +
 ColorMult is a very basic Shader Node that takes two colors as input and multiply them.
-here is the definition content (Common/MatDefs/ShaderNodes/Basic/ColorMult.j3sn) : 
+Here is the definition content (Common/MatDefs/ShaderNodes/Basic/ColorMult.j3sn) : 
 
 [source,java]
 ----
@@ -450,7 +452,7 @@ ShaderNodeDefinitions{
 
 ----
 
-Here is the shader Node code (Common/MatDefs/ShaderNodes/Basic/colorMult.frag)
+Here is the shader Node code (Common/MatDefs/ShaderNodes/Basic/colorMult.frag).
 
 [source,java]
 ----
@@ -461,10 +463,10 @@ void main(){
 
 ----
 
-+++<u>*ColorMult input mapping*</u>++++
+*+++<u>ColorMult input mapping</u>+++* +
 All inputs are mapped here :
 
-*  *color1 = MatParam.Color* : The first color is assigned to the Color Material parameter declared in the MaterialParameter block of the material definition  
+*  *color1 = MatParam.Color* : The first color is assigned to the Color Material parameter declared in the MaterialParameter block of the material definition.  
 *  *color2 = Global.color* : The second color is assigned with the Global color variable. this is defaulted to vec4(1.0) (opaque white).
 
 [NOTE]
@@ -472,7 +474,7 @@ All inputs are mapped here :
 In a very complex material def this variable could already have been assigned with a previous Shader Node output.
 ====
 
-+++<u>*ColorMult output mapping*</u>++++
+*+++<u>ColorMult output mapping</u>+++* +
 
 *  *Global.color = outColor* : the resulting color is assigned to the Global color variable.
 
@@ -485,15 +487,15 @@ Note that the Global.color variable will be assigned to gl_FragColor (glsl < 1.5
 
 [TIP]
 ====
-Also note that in case several Global variables are declared, the generator will assign them gl_FragData[i](glsl < 1.5) i being the order the variable has been found in the material def. For glsl >= 1.5 the veriable will just all be declared as shader output in the order they've been found in the declaration
+Also note that in case several Global variables are declared, the generator will assign them gl_FragData[i](glsl < 1.5) i being the order the variable has been found in the material def. For glsl >= 1.5 the veriable will just all be declared as shader output in the order they've been found in the declaration.
 ====
 
 
-+++<u>*Generated shader code*</u>++++
+*+++<u>Generated shader code</u>+++* 
 
 [IMPORTANT]
 ====
-Don't take this code as carved in stone, the generated code can change as optimization of the shader generator goes on
+Don't take this code as carved in stone, the generated code can change as optimization of the shader generator goes on.
 ====
 
 Vertex Shader (glsl 1.0)
@@ -525,10 +527,10 @@ void main(){
 
 ----
 
-All materials parameter, world parameters, attributes varying are declared first. then for each shader node, the declarative part is appended.+
-For the main function, for each shader node, the input mappings are declared and assigned, the output are declared.+
-Then the variable names are replaced in the sahder node code with there complete name (NameSpace_varName), material parameters are replaced in the shader code as is.+
-Then, the output are mapped.+
+All materials parameter, world parameters, attributes varying are declared first. then for each shader node, the declarative part is appended. +
+For the main function, for each shader node, the input mappings are declared and assigned, the output are declared. +
+Then the variable names are replaced in the sahder node code with there complete name (NameSpace_varName), material parameters are replaced in the shader code as is. +
+Then, the output are mapped.
 
 As you can see texCoord1/2 and vertColor are declared but never used. That's because the generator is not aware of that. By default it will declare all inputs in case they are used in the shaderNode code.
 Note that most glsl compiler will optimize this when compiling the shader on the GPU.
@@ -557,16 +559,16 @@ void main(){
 
 ----
 
-Same as for the Vertex shader. note that the color1 is not declared, because it's directly replaced by the material parameter.
+Same as for the Vertex shader. Note that the color1 is not declared, because it's directly replaced by the material parameter.
 
 
 [IMPORTANT]
 ====
-As a rule of thumb you should not assign a value to an input. input are likely to be material paramters or  outputs from other shaders and modifying them may cause unexpected behavior, even failure in your resulting shader.
+As a rule of thumb you should not assign a value to an input. Inputs are likely to be material paramters or outputs from other shaders and modifying them may cause unexpected behavior, even failure in your resulting shader.
 ====
 
 
 For more explanations and design decisions please refer to the +++<abbr title="specification">spec</abbr>+++ here 
-link:https://docs.google.com/document/d/1S6xO3d1TBz0xcKe_MPTqY9V-QI59AKdg1OGy3U-HeVY/edit?usp=sharing[https://docs.google.com/document/d/1S6xO3d1TBz0xcKe_MPTqY9V-QI59AKdg1OGy3U-HeVY/edit?usp=sharing]
+link:https://docs.google.com/document/d/1S6xO3d1TBz0xcKe_MPTqY9V-QI59AKdg1OGy3U-HeVY/edit?usp=sharing[https://docs.google.com/document/d/1S6xO3d1TBz0xcKe_MPTqY9V-QI59AKdg1OGy3U-HeVY/edit?usp=sharing].
 
-Thank you for the brave ones that came through all this reading. i'm not gonna offer you a prize in exchange of a password, because we ran out of JME thongs…
+Thank you for the brave ones that came through all this reading. I'm not gonna offer you a prize in exchange of a password, because we ran out of JME thongs…