-wir brauchen extrem simples operator framework fuer:
+procedural mesh generation (sphere fuer demo test)
+procedural texture generation (generally usefull)
+expressing rendering as operator graph (fbo, gpu based image processing etc. -> for ssao)
->requires support for multiple outputs (multirendertarget)
+gpu based particle system graph
+channel operator graph (required for best application of sync data from processing)
->requires lazy evaluation since we dont want to presample the channels

concept
-------
-base/gfx/Object.h
-base/gfx/Mesh.h (look at cinder, openframework, etc.)
-base/op/Op.h
->status execute()
->std::vector<OperatorPtr> m_inputs
->schreibt in std::vector<ObjectPtr> m_outputs;
-base/op/OpGroup.h //derives from op
->maintains list of all ops it contains
->status execute(  ) from operator
->->starts at finalOp and traverses the tree. fully evaluates all input ops
->input from parent group passed using GroupInputOp (similar to houdini's for each vop)
->has a finalOp which provides the result of the group
->status connect( src, dst ) // appends src to inputs of dst


DONE: stage1:
DONE: SphereOp to create a Mesh
DONE: Mesh::getGeometry() to turn it into a renderable
DONE: and render it

stage2:
RenderOp (group)
ClearOp
RenderMeshOp to display a mesh on screen














-sound:
portaudio
http://nothings.org/stb_vorbis/










TODO:




-figure out how to handle forward declaration. compiletime will increase if we dont do something here
-Attribute bind function uploads all data every time - should only be done when something has changed
-context render uploads the whole index buffer everytime geometry is rendered - should be done only when index buffer changes
-attribute bind as uniform, when being a sampler used uniformindex as texture unit to bind to - very bad - need textureunit management






serialisation
=============

soon we will need a way to serialise objects. For example after editing our clouds effect we want to save it and later load it with the saved settings.


use case: cloud effect
-the cloud effect is basically a shader
-
-edit clouds effect values using ui -> this changes class members and attributes(uniforms) which are passed to shader
-serialise the clouds effect the data is burried within the attributes (uniforms)


-ideally: no << or >> operator overloading and serialising to stream
-I like goggles protocoll buffers (map of key value pairs). because their approach allows smoother interoperability between different versions



clouds
------
node:
the clouds node is basically a wrapper around the cloudshader. it also contains a texture (clouds_parameters) and other things which are updated when inputs change.

inputs:
the glsl code has a lots of uniforms and attributes of which some of them are used internally (clouds_parameters texture) but others might be exposed.

outputs:
the wrapped glsl shader will be the output of the clouds effect.

notes:
update is implicitly carried out when shader is bound. at that time the render code iterates over the uniforms/attributes of the shader and updates them on the gpu.


render geometry
---------------

node:
this node just does a context->render( shader, geometry )

inputs:
base::Geometry
base::Shader

outputs:
execute function

note:
no update has to be carried out since the execute function passed will be used when needed by downstream nodes


ssao
----
node:
is basically a group node which contains a subgraph.

inputs:
pos/normal buffer texture
depth buffer texture

outputs:
color buffer texture



distilled ideas:
================

-nodes should be able to pass any of their members (data or methods) to other nodes
-if 2 references are connected a datacontainer is created inbetween the connection and given to both
	todo: how to handle traits?
	maybe outputsockets can have traits associated with them