Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-19Compositor: Export operation results as debug optionManuel Castilla
When fixing issues, seeing operation results can be helpful for detecting which operation went wrong. This commit adds an option for exporting all operations results to image files. Exceptions are: - Output operations: They are already exported or can be seen in UI. - Constant operations: There are too many and is rarely useful. They are exported to "<temp session folder>/COM_operations/" with filenames "<operation class name>_<operation id>.png". Only works on full frame execution mode. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D11722
2021-07-06Compositor: Graphviz improvementsManuel Castilla
Graphs are usually large, needing a lot of horizontal scrolling and they can include more information for debugging. This patch makes graph more compact horizontally by splitting labels in lines and removing namespaces. Furthermore it adds following information: - Operation ID. - SetValueOperation float value. - Optionally, operation node name. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D11720
2021-07-06Compositor: Constant foldingManuel Castilla
Currently there is no clear way to know if an operation is constant (i.e. when all rendered pixels have same values). Operations may need to get constant input values before rendering to determine their resolution or areas of interest. This is the case of scale, rotate and translate operations. Only "set operations" are known as constant but many more are constant when all their inputs are so. Such cases can be optimized by only rendering one pixel. Current solution for tiled implementation is to get first pixel from input. This works for root execution groups, others need previous groups to be rendered. On full frame implementation this is not possible, because buffers are created on rendering to reduce peak memory and there is no per pixel calls. This patch evaluates all operations that are constant into primitive operations (Value/Vector/Color) before determining resolutions. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D11490
2021-06-01Compositor: Full-frame base systemManuel Castilla
This patch adds the base code needed to make the full-frame system work for both current tiled/per-pixel implementation of operations and full-frame. Two execution models: - Tiled: Current implementation. Renders execution groups in tiles from outputs to input. Not all operations are buffered. Runs the tiled/per-pixel implementation. - FullFrame: All operations are buffered. Fully renders operations from inputs to outputs. Runs full-frame implementation of operations if available otherwise the current tiled/per-pixel. Creates output buffers on first read and free them as soon as all its readers have finished, reducing peak memory usage of complex/long trees. Operations are multi-threaded but do not run in parallel as Tiled (will be done in another patch). This should allow us to convert operations to full-frame in small steps with the system already working and solve the problem of high memory usage. FullFrame breaking changes respect Tiled system, mainly: - Translate, Rotate, Scale, and Transform take effect immediately instead of next buffered operation. - Any sampling is always done over inputs instead of last buffered operation. Reviewed By: jbakker Differential Revision: https://developer.blender.org/D11113
2021-04-28Replace COM_DEBUG #define with constexpr. Fixes T87035Tyler
Reviewed By: jbakker Maniphest Tasks: T87035 Differential Revision: https://developer.blender.org/D11068
2021-03-30Fix: Compile Error COM_Debug.Jeroen Bakker
We should replace `ifdef COM_Debug` with a constexpr function.
2021-03-29Cleanup: Add namespace to compositor.Jeroen Bakker
2021-03-21Cleanup: spelling, doxygen comment formattingCampbell Barton
2020-08-07Code Style: use "#pragma once" in source directoryJacques Lucke
This replaces header include guards with `#pragma once`. A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`), because they are used in other places. This patch has been generated by P1561 followed by `make format`. Differential Revision: https://developer.blender.org/D8466
2019-04-17ClangFormat: apply to source, most of internCampbell Barton
Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-02-18Cleanup: conform headers to have license firstCampbell Barton
Also remove doxy comments for licenses and add missing GPL header.
2019-02-01Cleanup: remove redundant, invalid info from headersCampbell Barton
BF-admins agree to remove header information that isn't useful, to reduce noise. - BEGIN/END license blocks Developers should add non license comments as separate comment blocks. No need for separator text. - Contributors This is often invalid, outdated or misleading especially when splitting files. It's more useful to git-blame to find out who has developed the code. See P901 for script to perform these edits.
2018-11-14Cleanup: comment block tabsCampbell Barton
2018-08-08Cleanup: use conforming header guardCampbell Barton
2018-06-17Cleanup: trailing space for compositorCampbell Barton
2018-06-01Cleanup: trailing whitespace (comment blocks)Campbell Barton
Strip unindented comment blocks - mainly headers to avoid conflicts.
2014-04-15Structural cleanup and improvements for the compositor.Lukas Tönne
Many parts of the compositor are unnecessarily complicated. This patch aims at reducing the complexity of writing nodes and making the code more transparent. == Separating Nodes and Operations == Currently these are both mixed in the same graph, even though they have very different purposes and are used at distinct stages in the compositing process. The patch introduces dedicated graph classes for nodes and for operations. This removes the need for a lot of special case checks (isOperation etc.) and explicit type casts. It simplifies the code since it becomes clear at every stage what type of node we are dealing with. The compiler can use static typing to avoid common bugs from mixing up these types and fewer runtime sanity checks are needed. == Simplified Node Conversion == Converting nodes to operations was previously based on "relinking", i.e. nodes would start with by mirroring links in the Blender DNA node trees, then add operations and redirect these links to them. This was very hard to follow in many cases and required a lot of attention to avoid invalid states. Now there is a helper class called the NodeConverter, which is passed to nodes and implements a much simpler API for this process. Nodes can add operations and explicit connections as before, but defining "external" links to the inputs/outputs of the original node now uses mapping instead of directly modifying link data. Input data (node graph) and result (operations graph) are cleanly separated. == Removed Redundant Data Structures == A few redundant data structures have been removed, notably the SocketConnection. These are only needed temporarily during graph construction. For executing the compositor operations it is perfectly sufficient to store only the direct input link pointers. A common pointer indirection is avoided this way (which might also give a little performance improvement). == Avoid virtual recursive functions == Recursive virtual functions are evil. They are very hard to follow during debugging. At least in the parts this patch is concerned with these functions have been replaced by a non-virtual recursive core function (which might then call virtual non-recursive functions if needed). See for example NodeOperationBuilder::group_operations.
2013-09-13Cleanup and improvements of the compositor debug output.Lukas Toenne
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.