Blender Git Statistics -> Branches -> cycles_camera_nodes

"Cycles_camera_nodes" branch

Total commits : 4
Total committers : 2
First Commit : September 26, 2014
Latest Commit : September 24, 2015

Commits by Month

DateNumber of Commits
September, 20153
August, 20150
July, 20150
June, 20150
May, 20150
April, 20150
March, 20150
February, 20150
January, 20150
December, 20140
November, 20140
October, 20140
September, 20141


AuthorNumber of Commits
Dalai Felinto3
Sergey Sharybin1

Popular Files

FilenameTotal Edits

Latest commits Feed

September 24, 2015, 15:24 (GMT)
Merge remote-tracking branch 'origin/master' into cycles_camera_nodes

Note: the branch currently crashes in blender_camera_nodes.cpp:
BL::NodeTree b_ntree = b_data.node_groups[nodes_tree_name];

The crash was introduced in:

September 21, 2015, 22:56 (GMT)
Silence double promotion error/warnings
September 16, 2015, 20:09 (GMT)
CMake build support
September 26, 2014, 12:23 (GMT)
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:

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021