Cycles - (Shader) Nodes - inputs outputs - What are the exact data types? I'm currently "hacking" Cycles to fully understand how it works (right down to the source_code), so I can fully maximize its awesome rendering potential for my own future blender projects. Here's how I am currently progressing and where I get stuck.



Fig 1 - Default Blender Scene, (1 cube, sunlight, camera and wood-texture (jpg-file) on the Cube via the Cycles Node Editor)

In Fig.1 - Here you can literally see a visualization of what the yellow type of "Color" (input/output) information.

In order to fully understand which type of (internal) Shader data streams Cycles uses I've have analyzed all existing Cycles Nodes, their inputs and outputs and their data-stream types or "Shader sockets".


Fig. 2 - Color (yellow) data Input/output streams.


Fig. 3 - Shader (green) data Input/output streams.


Fig. 4 - Vector ?? (purple) data Input/output streams.


Fig 5 - ?? (grey ) data Input/output streams.

Why do I do this?
- To understand which type-of-datastream/shader-socket is generated by any Cycles Node output.
- To understand which type-of-datastream/shader-socket can be accepted by a given Cycles Node input.
- What type of data a stream acutally holds (bits, bytes, floats, vectors, pixels, shader-data)

Where am I getting stuck and why?
So far the official
- Blender Wiki
- Blender online end-user manual
- Developer-level documentation over Cycles
all fail to mention the different type of data which is contained in/ carried the Cycles Shader sockets.

So I went a step further and downloaded the entire Blender (2.79a) Source code package and started looking for the exact definition of those Cycles Shader data types ... and found this information (os far):

Fig 6 - Blender Shader sockets information, located in various source code-files

So now my question is:
Where must I look (further) to find the exact documentation / definitions of the Shader sockets, when it is not documented in any official Blender (developer, manual) source and its own source-code-files?

Thanks in advance for your hints, tips, and tricks to get me closer to demistifying the Cycles Sockets data_types.
Light Green sockets represent Closures. They don't hold any particular value, and they serve to instruct the render how the rays should be treated. Closures can be added, and mixed (which is an Add operation where the closure colors are mixed). Closures are functions that determine the amount of reflected light from the surroundings to the incoming vector direction, and they are normally multiplied by a color. They can also be converted into strings using OSL.

Purple sockets represent Vectors. They have three components, for X, Y and Z. They can be used as vectors, points, normals, or any type of data that can be represented by 3 components (they can even represent colors).

Yellow sockets represent Colors. They are similar to Purple sockets, has they also have 3 components (Red, Green and Blue), but they are treated as colors and normally, conversions are done in color space. For example, when plugging a color into a value socket the color is transformed into greyscale, and used as a single value (val=R*0.2989 + G*0.5870 + B*0.1140); but this value will be different if instead of a color we plug a vector with the same values (val= (X + Y + Z)/3).

Light Grey sockets represent single values. Just like 0.0, 1.0, 0.5, -5.5, 3.1415, etc.

Dark Green sockets represent integers (-2, -1, 0, 1, 2,...) 

White (or dark grey in new versions) sockets, while not common, normally represent Strings. They are not common and can only be used with OSL.

Except for Closures, Integers and Strings, all other sockets components are Floating Point values (even integers are converted to floating point values, as the SVM only uses these).

Now, sockets represent inputs/ouputs of information. How one uses this information is far beyond what is possible to give in one simple answer, as each value can have a different meaning depending on the context they are used. For example, the value 0.8 can mean anything (a roughness value, an IOR value, an angle, etc). Is up to the user to give these values a context.

Another point is: Don't think that values are really passing from one socket to another.. The node tree is analyzed after any change, and the SVM compiles the working version behind the scenes. What you have in nodes is just an interface.