| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Self-explanatory. to find broken links run `sphinx-build -b linkcheck sphinx-in sphinx-out`
Reviewers: mont29
Tags: #bf_blender, #python, #infrastructure:_websites
Differential Revision: https://developer.blender.org/D2297
|
|
|
|
Patch by Ted Schundler (tschundler), thanks!
Differential Revision: https://developer.blender.org/D2163
|
|
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
|
|
|
|
|
|
|
|
handling).
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).
|
|
Since the color wheel can't handle negative colors usefully, use a basis value for the initial RGB.
|
|
It was no more possible to translate two images, put one on top of
another in order to do things like mapping VR views.
|
|
Regressions after 2.76, to be backported to 2.77.
|
|
|
|
Also use SWAP macro
|
|
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
|
|
Was easy to notice when alpha-overing smaller image with blur on
the bigger frame.
|
|
ALl 64 bit platforms supports SSE2, hence the flag is ignored
and warning was generated.
|
|
|
|
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?).
|
|
Use 0.0f instead of 0.f and so on.
|
|
Use the same default value for Z-depth in the compositor as everywhere else.
|
|
HDR colors.
|
|
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.
|
|
Avoid per-pixel camera intrincs object construction and synchronization.
Here on a bit synthetic file it gives about 40% speedup with a single node.
|
|
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
|
|
|
|
Also fix inconsistency for freestyle translation - we use IFACE_ everywhere
(TIP_ may be more suited, but let's be consistent first!).
|
|
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
|
|
|
|
It uses edge extrapolation code from Gimp's antialias plugin now,
which has advantage of giving symmetrical results, which makes it
possible to add two antialiased ID masks and have a constant 1.0
all over the frame. But has difference from the old implementation
because it uses 3x3 matrix only, which doesn't give so much smooth
looking edges. Perhaps it's not so bad, since if edges are really
need to be smooth one might use Blur node.
Another advantage is that the node is now nicely threaded.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Subscribers: ania
Differential Revision: https://developer.blender.org/D1617
|
|
Definitions could shadow local vars.
|
|
Better support of bicubic sampling of ID mask output.
The idea is to generate ID mask into a temporary buffer which is then being
interpolated using current sampling method.
This works fine for upscaling or rotating the ID mask but does not work for
scaling down. This is much-much bigger problem of the compositor design and
can't really be solved currently. Same will happen with other nodes like
blur for example.
Reviewers: campbellbarton
Subscribers: ania
Differential Revision: https://developer.blender.org/D1612
|
|
This appears to be really common workflow when you stabilize shot to make compo
easier (roto, some effects and so) and then re-introduce the motion back.
Surely it's doable with some magic nodes and manual network for transforming
but such workflow is too common in VFX to resist adding one small option in
single node for this.
|
|
|
|
|
|
|
|
|
|
|
