MiikaHweb - Blender Cycles_camera_nodes Branch MiikaHweb - Blender Cycles_camera_nodes Branch fi Fri, 14 Aug 20 21:07:06 +0000 MiikaHweb RSS contact at <![CDATA[[27b3ea6]: Merge remote-tracking branch 'origin/master' into cycles_camera_nodes...]]> 27b3ea6
Branches : cycles_camera_nodes
Author : Dalai Felinto (dfelinto)
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:


0 Paths Changed]]>
Thu, 24 Sep 2015 15:24:20 +0000 Felinto
<![CDATA[[372dff8]: Silence double promotion error/warnings]]> 372dff8
Branches : cycles_camera_nodes
Author : Dalai Felinto (dfelinto)
Silence double promotion error/warnings

1 Path Changed]]>
Mon, 21 Sep 2015 22:56:14 +0000 Felinto
<![CDATA[[91d64cb]: CMake build support]]> 91d64cb
Branches : cycles_camera_nodes
Author : Dalai Felinto (dfelinto)
CMake build support

1 Path Changed]]>
Wed, 16 Sep 2015 20:09:40 +0000 Felinto
<![CDATA[[0e1f34a]: Cycles; Camera ray nodes initial commit]]> 0e1f34a
Branches : cycles_camera_nodes
Author : Sergey Sharybin (sergey)
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:

29 Paths Changed]]>
Fri, 26 Sep 2014 12:23:18 +0000 Sharybin