I think the main reason there isn't a clear flow of strictly typed data in Terragen is because of the early decision to do much of the work by chaining together shaders which can perform arbitrary modifications on a wide band of data. This is the general case with the shaders, which are the red coloured nodes.
Different shaders do different things and work in different ways. However, there are some basic rules.
Most shaders (the nodes coloured red) are designed to manipulate the current shading state. The shading state contains information about the current point being shaded, including (but not limited to) position (that includes displacement), undisplaced position, texture coordinates, various surface normals. Most shaders execute the shader that's connected to their main "input" input, then perform their own modification of the state. For this reason, in general there is no particular type of data that an input requires. You can therefore think of the main "input" input as being an entire description of a point on a surface or in a volume.
I designed the main flow of shaders to work this way so that each shader can do more than one thing to a surface, not just generate some value.
Other inputs may expect particular types of object, such as a camera, an object (in some cases a specific type of object e.g. a planet), a shader or function. I don't think we can represent all the types we would want to with just a few simple shapes, but I think a clear indication of the expected type would be very useful and is an unfortunate omission in the current system. There are some basic categorisations (e.g. shader/function, object) which we could represent, but they would be coarse categorisations.
The blue function nodes are designed a little differently. With these I wanted there to be a more conventional flow of data consisting of a single value (whether it has 1 or more components) and for each of the nodes to perform only one low level function that we could easily document, and for parameters to be implemented as connections wherever possible, rather than constant values in a parameter window. For these nodes, there are only 3 possible types of data. Scalar, Colour (3 scalars) and Vector (3 scalars). They are not strictly typed, and conversions between these types will happen automatically (according to specific rules we have documented) if a function expects a different type of data from what it is given. By convention, the type of data produced by a function should be the last word in its name, although there are a few exceptions where it was awkward to adhere strictly to this convention.
Oshyan, do we still have that page where Jo and I documented the automatic type conversions done by functions?
We would like to keep the blue function nodes as a haven of transparent behaviour and avoid most of the "black box" issues and confusion surrounding the rest of the shaders, even though for many users they can seem overwhelming. We need to make sure the documentation is finished and online.
Many of the red shader nodes expect functions or "colour shaders". Any shader that modified a surface's diffuse colour can be used as a colour shader, and will also convert automatically to a colour function when connected to a blue function node. Any function node will be converted to a colour shader when connected to a shader that requires a colour shader.
It tends to be the older shaders that are inconsistent about whether they label an input a "shader" or a "function". We should clean some of this up. Generally speaking, though, any shader could generate colour that might be useful as a function.
There are only a few shaders that generate displacement from a function (or colour shader), and if I recall correctly in every case these shaders have an input labeled "displacement function" which expects a scalar function. Colour data gets converted by taking the luminance, and vector data gets converted by taking the magnitude.
I know this only goes part way to answering your questions.
Matt
