This was suggested by Christopher Barrett (terrachild). Corner pin is a common feature in compositing.
The corners for the plane warping can be defined by using vector node inputs to allow using perspective plane transformations without having to go via the MovieClip editor tracking data.
Uses the same math as the PlaneTrack node, but without the link to MovieClip and Object.
{F78199}
The code for PlaneTrack operations has been restructured a bit to share it with the CornerPin node.
* PlaneDistortCommonOperation.h/.cpp: Shared generic code for warping images based on 4 plane corners and a perspective matrix generated from these. Contains operation base classes for both the WarpImage and Mask operations.
* PlaneTrackOperation.h/.cpp: Current plane track node operations, based on the common code above. These add pointers to MovieClip and Object which define the track data from wich to read the corners.
* PlaneCornerPinOperation.h/.cpp: New corner pin variant, using explicit input sockets for the plane corners.
One downside of the current compositor design is that there is no concept of invariables (constants) that don't vary over the image space. This has already been an issue for Blur nodes (size input is usually constant except when "variable size" is enabled) and a few others. For the corner pin node it is necessary that the corner input sockets are also invariant. They have to be evaluated for each tile now, otherwise the data is not available. This in turn makes it necessary to make the operation "complex" and request full input buffers, which adds unnecessary overhead.
Implements a more flexible internal connect function for standard nodes
(compositor, shader, texture). Allow feasible datatype connections by
priority.
The priorities for common datatypes in compositor, shader and texture
nodes are encoded in a simple function. Certain impossible connections
(e.g. color -> cycles shader) are excluded by giving them -1 priority.
Priority overrides link status: If a higher priority input can be found,
this will be used regardless of link status. Link status only comes into
play for inputs with same priority.
Reviewers: brecht
CC: sebastian_k
Differential Revision: https://developer.blender.org/D356
It would include/exclude shadow depending on the pass being disabled/enabled,
but that should have no influence on the combined render result. Now it always
includes shadow.
Blender Internal shader nodes.
All nodes now use the `nodestack_get_vec` function to convert whatever
input values are connected to the desired type, instead of using the
stack values directly regardless of what they contain.
Note that this might break old node setups that have been adapted to the
faulty behavior, but as discussed in the bug report the 2.70 version is
the right time to fix this.
BI.
The shaderfrom setting in the node editor only makes sense for "new"
shading nodes (cycles), otherwise it should be ignored and default to
SNODE_SHADER_OBJECT.
As discussed in T38340 the solution is to use the current scene from
context whenever feasible.
Composite does not use node->id at all now, the scene which owns the
compositing node tree is retrieved from context instead.
Defocus node->id is made editable by the user. By default it is not set,
which also will make it use the contextual scene and camera info.
The node->id pointer in Defocus is **not** cleared in older blend files.
This is done for backward compatibility: the node will then behave as
before in untouched scenes.
File Output nodes also don't store scene in node->id. This is only needed
when creating a new node for initializing the file format.
Reviewers: brecht, jbakker, mdewanchand
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D290
The sanity check for copying socket default value was using the socket
idname for type compatibility checks, which is too strict. Subtypes
would not be recognized as copyable, but since only the plain data type
is needed below this is all that needs to be checked.
That alone would not cause crash (just missing default value copy),
but the tree view template was messing with the default_value DNA
directly by freeing it in advance, which is not necessary and should
be left to blenkernel when freeing the node. Otherwise this would
leave the node invalid without a default_value if the copy function
bails out.
* Henyey-Greenstein scattering closure implementation.
* Rename transparent to absorption node and isotropic to scatter node.
* Volume density is folded into the closure weights.
* OSL support for volume closures and nodes.
* This commit has no user visible changes, there is no volume render code yet.
This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
moved the hide preview logic to a method on bNodeTreeType. This way the node.c keeps clean, but logic could still be shared.
Implementing this per node, can lead to future errors.
For now this provides the following outputs:
- Color
- Light Vector
- Distance
- Shadow
- Visibility Factor
Note: Color output is multiplied by the lamp energy. Multiplication of
color*max(dot(light_vector,normal_vector),0)*shadow*visibility_factor
produces the exact same result as the Lambert shader.
Many thanks to Brecht for code review and discussion!
Revert 0c7d2de382. The "Camera Data" node actually gives the location
of the point in camera coordinate system. To obtain actual camera data,
we can use "Geometry" node instead.
Also modify the "Geometry" node, to produce correct view vector output
in orthographic GLSL preview.
For materials using AO pass, this makes the material preview and the GLSL
preview more accurate, but shouldn't affect final rendering in most cases
because we usually enable AO when using the AO pass in node tree.
Thanks to Brecht for code review.
* Add a "Normal" Input to the Fresnel node.
* Fix for the Fresnel GLSL code (normalize the Incoming vector).
Patch #37384 by Philipp Oeser (lichtwerk) , thanks!
mimics the previous behavior when settings were shared by both modes (but not equivalent).
NOTE: Due to the use of additional sRGB conversion in the LGG mode the result is not entirely accurate, this should perhaps be fixed.
Settings for each mode are kept in their own color values nevertheless, this avoids potential problems with float precision.
become invalid because the render database is not immediately freed after the job finishes. To avoid access to dangling node pointers, store the function callback in the exec data itself. The node
pointer must not be accessed in the free function (wasn't used before either), these functions are purely for the execution data.
Scene/Render "spaces" are actually absolute values, they do not use the input X/Y scale factors, hide them in this case.
Thanks to Lukas for review and improvement!
* Keep the Mapping node default type as Point for now, instead of Texture. The
latter is a better default, but this is breaking API compatibility and it's
too close to release to expect addons to be fixed in time.
* Vector Transform and Mapping nodes had properties with name "type" to set the
type of vector, but this conflicts with the node type property, so renamed to
vector_type now.
scale and rotation in mapping node, there would be shearing, and the only way
to avoid that was to add 2 mapping nodes. This is because to transform the
texture, the inverse transform needs to be done on the texture coordinate
Now the mapping node has Texture/Point/Vector/Normal types to transform the
vector for a particular purpose. Point is the existing behavior, Texture is
the new default that behaves more like you might expect.
