anchor.diff:  ====
   
   
  -For more explanations and design decisions please refer to the +++<abbr title="specification">spec</abbr>+++ here 
  +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].
   
   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…
  
positive.code: ----
  
  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* +
  The size can be dynamic and driven by a material parameter. GLSL does not support non constant values for array declaration so this material parameter will be mapped to a define. +
  
negative.code: 
  == Motivations
  
  jME3 material system is entirely based on shaders. While it's pretty powerful, this system has some issues and limitations :
  
  *  Monolithic shaders have a serious lack of flexibility, and it can be daunting to get into the code for inexperienced users.
  *  Maintenance ease of such shaders is poor. (for example the whole lighting shaders represent around 500 lines of code, and it could be a lot worse with more features)
  