Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
This switches the internal color representation of the eye dropper from display space to linear. Any time a linear color is requested and the color is picked from a linear object, the result is now precise to the bit as the color gets patched through directly. Color space conversion now only happens when a color is picked from non-linear display space objects or when the color is requested to be returned in non-linear space.
In addition, this patch changes the DifferenceMatte node to interpret a tolerance of 0.0 to accept colors that are identical bit by bit, as apposed to simply refusing all colors.
The issue was caused by sometimes negative color returned by the filter node.
Seems to be caused by precision issues. Don't see any reason why we would want
negative colors in output. Those only causing issues later on.
Please never, ever use same DNA var for two different things. Even worse
if they do not have same type and ranges!
This is only ensuring issues (as described in report, but also if
animating both RNA props using same DNA var... yuck).
And we were not even saving any byte in DNA, could reuse some padding
there to store the two new needed vars (yes, two, since we cannot re-use
existing one if we want to keep backward *and* forward compatibility).
This is much more flexible solution which will allow doing some
more procedural features.
Reviewers: brecht, dfelinto, mont29
Reviewed By: mont29
Subscribers: Severin
Differential Revision: https://developer.blender.org/D2403
See this page for motivation and description of concepts:
https://github.com/Ichthyostega/blender/wiki
See this video for UI explanation and demonstration of usage
http://vimeo.com/blenderHack/stabilizerdemo
This proposal attempts to improve usability of Blender's image stabilization
feature for real-world footage esp. with moving and panning camera. It builds
upon the feature tracking to get a measurement of 2D image movement.
- Use a weighted average of movement contributions (instead of a median).
- Allow for rotation compensation and zoom (image scale) compensation.
- Allow to pick a different set of tracks for translation and for
rotation/zoom.
- Treat translation / rotation / zoom contributions systematically in a
similar way.
- Improve handling of partial tracking data with gaps and varying
start / end points.
- Have a user definable anchor frame and interpolate / extrapolate data to
avoid jumping back to "neutral" position when no tracking data is available.
- Support for travelling and panning shots by including an //intended//
position/rotation/zoom ("target position"). The idea is for these parameters
to be //animated// by the user, in order to supply an smooth, intended
camera movement. This way, we can keep the image content roughly in frame
even when moving completely away from the initial view.
A known shortcoming is that the pivot point for rotation compensation is set to
the translation compensated image center. This can produce spurious rotation on
travelling shots, which needs to be compensated manually (by animating the
target rotation parameter). There are several possible ways to address that
problem, yet all of them are considered beyond the scope of this improvement
proposal for now.
Own modifications:
- Restrict line length, it's really handy for split-view editing
- In motion tracking we prefer fully human-readable comments, meaning we
don't use doxygen with it's weird markup and comments are supposed to
start with capital and end with a full stop,
- Add explicit comparison of pointer to NULL.
Reviewers: sergey
Subscribers: kusi, kdawg, forest-house, mardy, Samoth, plasmasolutions, willolis, sebastian_k, hype, enetheru, sunboy, jta, leon_cheung
Maniphest Tasks: T49036
Differential Revision: https://developer.blender.org/D583
Make 'Laplace' filter an edge filter operation, since this what it is
typically used for, and such operation does not affect the input's alpha
channel.
Reviewers: sergey, campbellbarton
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D1817
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
Using SSE2 intrinsics when available for this kind of conversions.
It's not totally accurate, but accurate enough for the purposes where
we're using direct colorspace conversion by-passing OCIO.
Partially based on code from Cycles, partially based on other online
articles:
https://stackoverflow.com/questions/6475373/optimizations-for-pow-with-const-non-integer-exponent
Makes projection painting on hi-res float textures smoother.
This commit also enables global SSE2 in Blender. It shouldn't
bring any regressions in supported hardware (we require SSE2 since
2.64 now), but should keep an eye on because compilers might have
some bugs with that (unlikely, but possible).
Quite trivial idea -- just pass tread ID to the texture sampling function.
Implemented as a TLS to avoid passing huge amount of extra contexts around.
Should be working on all platforms, but compilation test is required.
Reviewers: juicyfruit, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1831
Avoid allocating the (tiny) array on the heap in the first place.
Reviewers: sergey, lukastoenne
Differential Revision: https://developer.blender.org/D1815
Based on an user feedback, previous implementation with providing
decoupled X and Y speeds didn't work in production at all: there
is no way to combine this speeds to an usable vector.
So now we're providing speed vector output instead, which provides
speed in an exactly the way Vector Blur node expects it to be:
first two components is a speed from the past, second two components
defines speed to the future.
Old behavior can be achieved by RGBA separating the speed output
and using first tow components.
Now this speed gives quite the same results as a speed pass, with
the only difference that track position speed uses "shutter" of
1 while pass uses shutter of 0.5 (and there's no way to affect on
that?).
Seems i was the only one who was really up to using it and
i do have gcc-5 finally backported and installed here so
such a fine-tune flags are no longer needed.
The issue was caused by some functions in compositor returning
garbage values. Partially the issue was caused by vc12_xp toolset
we're using, but even with regular vc120 toolset nodes like bokeh
image did not work correct.
This is a bit weird solution, which could indicate some sort
of compiler bug, but is also actually makes sense because we do
use SSE intrinsics in the compositor now. Maybe it all gets
interfered in some way.
In any case, if someone wants to find a real solution for the
issue please go ahead.
This shouldn't have affect on supported platform because we
already demand CPU to have SSE2 support.
Compositor tried to be too much smart and avoid unneeded re-calculations of
the distortion model, but the way it was implemented is by falling back to
the nearest interpolation first.
We can't really cheat here, better to just look into faster models estimation.
It is handy when doing some roto work and it's required to blur some
mask or overaly before alpha-overing it on top of the footage.
Quite straightforward option with the only limitation that variable
size blur is not supported.
Reviewers: campbellbarton
Subscribers: hype, sebastian_k
Differential Revision: https://developer.blender.org/D1663
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
velocity is measured in pixels per frame. It is basically a coordinate
difference of track coordinate at current frame and previous one (no future
prediction happens).
It's not really most intuitive place for such a things, but historically the
node was called this way..
Track velocity could be used to face effects like motion blur bu piping it
to the vector blur node.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Subscribers: hype, sebastian_k
Differential Revision: https://developer.blender.org/D1591
