This was in fact really nasty bug, caused by multitex_nodes
function using global variable R (which is a copy of current
renderer). this variable is not initialized to anything
meaningful for until first rendering (preview or final)
happened.
Since multitex_nodes might be used outside of render pipeline,
made it so whether CM is on or off as an argument to functions
multitex_ext_safe and multitex_ext. Now multitex_nodes() is
only shall be used for stuff happening from render pipeline!
Also needed to make some changes to other places, so all the
usages of texture sampling knows for the fact whether CM is
on or off.
And one more change is related on behavior of dispalcement,
wave, warp, weightvg modifiers and smoke. They'll be always
using CM off since texture is used for influence, not for
color.
It's rather bigger patch, but it's mostly straightforward
changes, which we really need to be done.
Reviewed by Brecht, thanks!
Such mapping only worked foe compositor output node
(with some issues btw) and failed dramatically for
nodes like previews and viewers.
For now let's behave the same way as border+crop
worked in 2.66 for until proper feature support
is ready (which could take some time).
Fixes#35313: object and ID anti-aliased masks get messed up
when using border render + crop
Issue was caused by file output node actually,
The thing here is, compositor output does have fixed
resolution and we could predict how to map coordinates
for border and cropping in that case.
But viewers and file output nodes are currently totally
depending on an input resolution. Could not see how
border could be applied reliably in this cases.
Disabling border option for file output node, so
now it shall behave the same way as it was before.
Discovered issues when using cropping to render border,
namely there's an offset in viewer nodes and previews,
but this is separate issue i guess (file output seems
to work fine). Will revisit this issue in next days.
Issue was caused by too hight value used for size,
which came from infinite Z-buffer point.
Solved the crash by clamoing maximal gaussian table
radius to 30K, which seems to be reasonable.
Fix for 34494 Blender 2.65 regression test error - compo_map_uv_cubes.blend - stripe/artifact between cubes
Hue and saturation node has an early break when saturarion is 0. When this happened the input 1 color needed to be used. This behaviour was not merged.
When no FSAA is used in the ZCombine. a mask will be created, this mask will be antialiased and based on this mask the colors between the two images are blended. This was also behaviour that was not merged correctly. Now it is back making much better z-combines.
Hope nobody uses these gabs as a work around.
- At Mind -
Jeroen & Monique
This commit simply implements mapping from centered cropped canvas
to a full-frame coordinates, so operations like alpha-overing render
result on top of image will be properly aligned.
Make it so compositor output node wouldn't be calculated
when Render Result image is not visible on the screen.
This makes compositor tree editing more friendly and
faster.
Also, if there's no viewer image visible on the screen
viewer nodes wouldn't be handled.
Final rendering keeps unchanged for now.
This solves issues when for performance artists are
disconnecting compo output node before tweaking values
in compositor and forgets to attach compo output
node before sending file to the farm.
Pretty much straightforward change, made in the same way as
texture input node.
Shall not be any regressions or crashes when mixing usage
of 2.66 and current trunk.
PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements.
=== Dynamic node type registration ===
Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes.
Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2].
=== Node group improvements ===
Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3].
The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there.
[1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes
[2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender
[3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
This node and operations are not useful in background mode anyway,
but calculating them could be really time-consuming especially
when working on 4K frames.
Issue was caused by calling ensureDelta from initexecution, which will
read pixels from an input and it could read from non-initialized
operations.
Issue was originally introduced in svn rev54235 which added ensureDelta
to translate's initExecution, but since rev54349 this call seems to be
doing nothing.
Issue was caused by the fix for #33650 which changed way to check whether
operation resolution is set or not from checking dimensions are zero to
setResolution was ever called.
Such change lead to conflict with MixBase operation (used for Mix node) which
uses temporary zero resolution to check whether input socket resolution is
known. This leads to zero resolution setting to that branch of tree. After this
resolution will never set to it's actual value.
For now solved by changing logic how MixBase operation detects resolution.
Namely instead of using trick with temporary zero resolution and calling
determineResolution for all inputs, and then call base class's method to
determine resolution just once again, check whether input socket is connected
and if so use it's resolution.
Shall not be regressions for real-life trees, but keeping an eye on this and
doing more tests is for sure welcome.
Made Texture compositor input node single-threaded since
texture trees are not thread-safe.
Also fixed texture being flipped horizontally and vertically.
Why nobody noticed this for 3 releases already??
Calculate dependent area based on distortion model rather than
using 15% of image resolution for this.
Some assumptions here:
- We're assuming real-life camera calibration is used here
- Maximal undistortion delta would be achieved on frame boundary
- Distortion fully goes inside frame
This makes it possible to approximate margin for distortion by
checking undistortion delta across frame boundary and use it
for dependent area of interest.
We do not use any formula-based equation here because we're likely
support other distortion models and in that case it'll be stupid
to try detecting formula here.
* added area of interest based on a radius around the input tile.
If someone can implement a correct formula (based on K1, K2 and K3) and send it to me, I will be happy to apply it!
- At Mind -
is straight or not (premultiplied is default).
This is useful in cases when you want to check on output of such nodes
as keying which does have straight alpha output.
Also added missing do_version code to previous compo do_versions.
makes it possible to specify an offset relative to the render resolution (so 0.5
is half the image rather than giving the number of pixels). It's a bit late but
it's a trivial change and needed for 4k mango render.
