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 area-of-interest calculation for that node didn't work reliably.
It tries to estimate the distorted rectangular area based on min/max
distortion and dispersion values, but this fails in some cases and
leaves uninitialized buffer chunks. So now simply use the full input
rect as the area, even though it may not be as efficient - at least it
works ...
Also cleaned up the code somewhat to make it understandable, using
separate functions for common stuff instead of cryptic walls of math.
Summary:
Issue was caused by the same tile being written twice to
the EXR file. This was happening because of partial update
of work-in-progress tiles was merging result to the final
render result in order to make color management pipeline
happy.
We need to avoid such a merges and keep memory usage as
low as possible when Save Buffers is enabled.
Now render pipeline will allocate special display buffer
in render layer which will contain combined pass in the
display space. This keeps memory usage as low as we can
do at this moment.
There's one weak thing which is changing color management
settings during rendering would lead to lossy conversion.
This is because render result's display buffer uses color
space from the time when rendering was invoked.
This is actually what was happening in previous release
already actually so not a big issue.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D162
It was only used by opengl render and in fact it needed just to
set DISPLAY_BUFFER_INVALID flag for the image buffer.
In theory it wouldn't make any change to opengl render speed
(because this change just moved rect_from_float from color
management code to image save code). And could not see any speed
changes on my laptop.
EWA sampling is designed for downsampling images, i.e. scaling down the size of
input image pixels, which happens regularly in compositing. While the standard
sampling methods (linear, cubic) work reasonably well for linear
transformations, they don't yield good results in non-linear cases like
perspective projection or arbitrary displacement. EWA sampling is comparable to
mipmapping, but avoids problems with discontinuities.
To work correctly the EWA algorithm needs partial derivatives of the mapping
functions which convert output pixel coordinates back into the input image
space (2x2 Jacobian matrix). With these derivatives the EWA algorithm
projects ellipses into the input space and accumulates colors over their
area. This calculation was not done correctly in the compositor, only the
derivatives du/dx and dv/dy were calculation, basically this means it only
worked for non-rotated input images.
The patch introduces full derivative calculations du/dx, du/dy, dv/dx, dv/dy for
the 3 nodes which use EWA sampling currently: PlaneTrackWarp, MapUV and
Displace. In addition the calculation of ellipsis area and axis-aligned
bounding boxes has been fixed.
For the MapUV and Displace nodes the derivatives have to be estimated by
evaluating the UV/displacement inputs with 1-pixel offsets, which can still have
problems on discontinuities and sub-pixel variations. These potential problems
can only be alleviated by more radical design changes in the compositor
functions, which are out of scope for now. Basically the values passed to the
UV/Displacement inputs would need to be associated with their 1st order
derivatives, which requires a general approach to derivatives in all nodes.
inputs.
http://wiki.blender.org/uploads/4/4c/Compo_image_interpolation_borders.png
Problem is that all image buffer reader nodes (RenderLayer, Image,
MovieClip) were clipping pixel coordinates to 0..N range (N being width
or height respectively). Bilinear interpolation works ok then on the
upper-right borders (x, N) and (N, y), since the last (N-1) pixel fades
out to N (background). But the lower-left (x, 0) and (0, y) borders are
not correctly interpolated because the nodes cut off the negative pixels
before the interpolation function can calculate their value.
To fix this, the interpolation functions are now entirely responsible
for handling "out of range" cases, i.e. setting (0,0,0,0) results for
invalid pixels, while also handling interpolation for borders.
Callers should not do pixel range checks themselves, which also makes
the code simpler. Should not have any real performance penalty,
the interpolation functions do this check anyway, so is probably even
slightly faster.
This patch changes most of the reamining degrees usage in internal code into radians.
I let a few which I know off asside, for reasons explained below - and I'm not sure to have found out all of them.
WARNING: this introduces forward incompatibility, which means files saved from this version won't open 100% correctly
in previous versions (a few angle properties would use radians values as degrees...).
Details:
- Data:
-- Lamp.spotsize: Game engine exposed this setting in degrees, to not break the API here I kept it as such
(using getter/setter functions), still using radians internally.
-- Mesh.smoothresh: Didn't touch to this one, as we will hopefully replace it completely by loop normals currently in dev.
- Modifiers:
-- EdgeSplitModifierData.split_angle, BevelModifierData.bevel_angle: Done.
- Postprocessing:
-- WipeVars.angle (sequencer's effect), NodeBokehImage.angle, NodeBoxMask.rotation, NodeEllipseMask.rotation: Done.
- BGE:
-- bConstraintActuator: Orientation type done (the minloc[0] & maxloc[0] cases). Did not touch to 'limit location' type,
it can also limit rotation, but it exposes through RNA the same limit_min/limit_max, which hence
can be either distance or angle values, depending on the mode. Will leave this to BGE team.
-- bSoundActuator.cone_outer_angle_3d, bSoundActuator.cone_inner_angle_3d: Done (note I kept degrees in BGE itself,
as it seems this is the expected value here...).
-- bRadarSensor.angle: Done.
Reviewers: brecht, campbellbarton, sergey, gaiaclary, dfelinto, moguri, jbakker, lukastoenne, howardt
Reviewed By: brecht, campbellbarton, sergey, gaiaclary, moguri, jbakker, lukastoenne, howardt
Thanks to all!
Differential Revision: http://developer.blender.org/D59
Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
Previous wrap implementation was based on inverse
bilinear mapping, which doesn't give perspective.
Now plane track wrap estimates perspective transform
matrix as a homography estimation between frame
coordinates and plane corners.
Uses Libmv's implementation for this, which means
plane track wouldn't work properly with Libmv
disabled. Not a deal for official builds at all,
just folks who keeps things disabled need to be
aware of this.
Distinguish the 3 different methods for acquiring pixel color values (executePixel, executePixelSampled, executePixelFiltered).
This makes it easier to keep track of the different sampling methods (and works nicer with IDEs that do code parsing).
Differential Revision: http://developer.blender.org/D7
generally speaking, if multilayer image fails to load for current
frame doesn't mean anything bad. It might be used to make it so
image sequence is being alpha-overed somewhere in the middle of
scene time.
Made it so if the whole file fails to load, image node will
deliver black transparent color, the same what happens for
regular (non-multilayer images).
Also needed to tweak code in load_multilayer_sequwnce to make
sure no cached frames are pointing to a freed memory.
The RenderLayers node would use the "combined" image result for all passes which don't have a valid render result yet. This causes problems when the buffer element size is not actually 4 floats (RGBA) as
with the 3 float normal passes. Also the result is rather meaningless then, so just keep the image buffer at NULL for unavailable passes, which will return plain (0,0,0) color.
After discussion with Brecht decided that automatically updating the sockets of the node based on externally modified data (removed EXR file passes) is not desirable behavior. But at least making sure
the correct passes are assigned to the output sockets of the Image node is possible. Now the passes are matched by name instead of using the faulty index stored in the socket data, which is more
reliable. Still may break if changing pass names externally, but an image reload is highly recommended anyway and will fix that.
This was own error in r60049 which fixed chunk number calculation. This was mixing int and unsigned int values from ExecutionGroup, which leads to huge chunk numbers which are then skipped.
Debug code for graphviz output moved to a dedicated file COM_Debug.h/cpp.
The DebugInfo class has only static functions, which are called from a number of places to keep track of what is happening in the compositor. If debugging is disabled these are just inline stubs, so we
don't need #ifdefs everywhere and don't get any overhead.
The graphviz output is much more useful now. DebugInfo keeps track of node names in a static string map for meaningful names. It uses a number of colors for various special operation classes.
ExecutionGroups are indicated in graphviz with clusters.
Currently the graphviz .dot files are stored in the BLI_temporary_dir() folder. A separate dot file is generated for each stage of the ExecutionGroup scheduling, this is intended to give some idea of the
compositor progress, but could still be improved.
The chunk indices for scheduling chunks based on a given area were calculated incorrectly. This caused chunks at the very border of the render (pixels 256..257) to be omitted, leading to incorrect values
in the Z buffer of the test file, which in turn caused wrong normalization range and the resulting almost-white image.
Also added a dedicated executePixel function for Z buffer to avoid any interpolation of Z values.
- add missing headers from cmake (own omission)
- quiet rna_test.c unused define warnings.
- minor style edits
- spelling corrections and ignore all uppercase words with spell checking script.
