Cycles; Camera ray nodes initial commit

This commit lays down an initial playground for the camera ray nodes.

The idea of this nodes is to be able to have a control over the rays
which are being casted from the camera in order to gain several use
case scenarios:

- Panorama cameras with custom mapping (kinda generalized way doing
  what Daniel Basso tried to address in T35428).

- Distortion rendering, to produce renders which matches the footage
  precisely, improving motrack work flow in general.

- Some possible artistic scenarios.

It's the very beginning and loads of stuff to be done, but it's
already possible to render a distorted images on CPU using the same
exact distortion model as used by the motion tracker.

Committing the stuff in order to be able to gather early feedback
about how exactly this nodes are expected to work from the artists
point of view, and hopefully someone will pick the work up and help
finishing it all up.

Some technical details:

- Camera nodes are using pynodes, so no changes to the blender itself
  is to be done. This leads some limitations and corners on the usage,
  but that's probably something to be addressed for pynodes in general.

  That said, current annoyance is:

  * Modifying node declaration in the cycles addon doesn't update the
    files, leading to wrong render results. Not sure how it's expected
    to be handled actually.

  * Some operators like Ctrl-X are not re-linking noodles correctly.

  * Muting is impossible.

  * Some major update issues, mainly in cycles viewport. This also
    involves dependency graph stupidness into here.

- Nodes are implemented using SVM, which is really easy to use and
  extend. Would also make it possible to have custom socket types, for
  example in SVM we can have socket type named "Ray" which would pass
  all the origin, direction length via a single noodle.

  In OSL it's not so trivial by the looks of it, so for now we stick
  to a stupid regular socket types.

- Supporting OSL could be a rather tricky business via pynodes and
  could involve quite some work in here. Also it'll stress OSL with
  something it wasn't really designed to do, but it might just work.

- Since inverting the distortion is an optimization problem which is
  rather tricky to implement on GPU, only CPU supports camera ray
  nodes at this moment.

- The above thing might be solved if we bake distortion into a grid
  and use as a lookup table from the kernel. Would also help performance
  by avoiding solving optimization problem for each single camera ray
  at each sample.

- Some stuff might be totally broken at this moment, use with care
  and don't forget to back your files up before doing experiments.

Real quick example: ftp://ftp.blender.org/sergey/camera_nodes.blend.png

0 files changed, 0 insertions, 0 deletions