Now mask animation is offset to start of strip, instead of staying at frame 1!
Warning: this may break existing files, in case some would be using (hacking around!)
current bad behavior...
Added an utility function which performs vertex split based on the loop
normal so now backing API matches to what's happening in Cycles and BI
in terms of autosplit.
Reviewers: dfelinto, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1174
New 'strip' snapping was simply not computed in case of constrained transform, hence init
'0' value was used as frame offset in this case.
This commit reorganizes a bit that snapping, to keep it more 'confined' into `snapSequenceBounds()`
dedicated function. It still needs a minor hack (setting snapping mode to something else than
defualt `SCE_SNAP_MODE_INCREMENT`, to avoid this snapping to be called by contraint code).
Thanks to Antony for review and enhancements.
This fix should be backported to 2.74.
This patch is the root of the GHash rework, all other diff will be based on it:
Reduce average load from 3.0 to 0.75
----------------------------------
This is the big performance booster part, e.g. makes tracing a dyntopo stroke between 25% and 30% faster.
Not much to say about it, aside that it obviously increase memory footprint (about 25% - 30% too).
Add optional shrinking
----------------------------------
I.e. ghashes/gsets can now shrink their buckets array when you remove enough entries. This remains optional and OFF by default.
Add code to use masking instead of modulo
----------------------------------
Buckets indices are obtained from hashes by “reducing” the hash value into the valid bucket range. This can be done either by bit-masking, or using modulo operation.
The former is quicker, but requires real hashes, while the later is slower (average 10% impact on ghash operations) but can also be used as a 'fake' hashing on raw values, like e.g. indices.
In Blender currently not all ghash usages actually hash their keys, so we stick to modulo for now (masking is ifdef’ed out), we may however investigate the benefits of switching to masking with systematic very basic hashing later…
Add various missing API helpers
----------------------------------
I.e. a way to deep-copy a ghash/gset, and a way to (re-)reserve entries (i.e. manually grow or shrink the ghash after its creation).
Various code refactoring
----------------------------------
* Get rid of the 'hack' regarding ghash size when used as gset (it’s simpler and safer to have two structs defined here, and cast pointers as needed).
* Various re-shuffle and factorization in low-level internal code.
* Some work on hashing helpers, introducing some murmur2a-based hashing too.
Thanks a bunch to Campbell for the extensive review work. :)
Reviewers: sergey, campbellbarton
Subscribers: psy-fi, lukastoenne
Projects: #bf_blender
Maniphest Tasks: T43766
Differential Revision: https://developer.blender.org/D1178
A new checkbox "High quality" is provided in camera settings to enable
this. This creates a depth of field that is much closer to the rendered
result and even supports aperture blades in the effect, but it's more
expensive too. There are optimizations to do here since the technique is
very fill rate heavy.
People, be careful, this -can- lock up your screen if depth of field
blurring is too extreme.
Technical details:
This uses geometry shaders + instancing and is an adaptation of
techniques gathered from
http://bartwronski.com/2014/04/07/bokeh-depth-of-field-going-insane-http://advances.realtimerendering.com/s2011/SousaSchulzKazyan%20-
%20in%20Real-Time%20Rendering%20Course).ppt
TODOs:
* Support dithering to minimize banding.
* Optimize fill rate in geometry shader.
General idea is to avoid actual calculation from property update()
callback and tag things for update later instead.
That said, pose constraint flags are now tagged for update and
handled as a part of object update. In the new depsgraph it'll
be a nice dedicated operation node.
Also avoid updating disabled flags for all the modifiers. This
part of the path is not totally optimal since it'll still need
to iterate over bones in order to get pchan, but to optimize it
further would be nice to find a way to avoid pchan requirement
all together.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1191
It was actually an old issue with wrong conversion happening for muted
nodes, which wasn't visible before memory optimization commit.
This is to be backported to the final release.
D1147 by @julien, with fixes/improvements
Duplicate bones where needed, otherwise use existing.
Keeps parent relations intact, can operate on parts of an armature.
This adds back rgb_to_grayscale,
not all color is managed or depends on the current loaded blend file's CM options.
Noted in comments that this is only to be used outside the CM pipeline.
off.
GPUs need a full tree of mipmaps up to dimension 1xn to work. This will
make it so for all imbufs but cost is negligible and it's unlikely that
something could break due to that.
The way we were getting diff to apply to vcos from target object was just bad!
Also, fixed another related issue - negated scale would be clamped to nearly zero,
now only consider absolute version of size (we do not care about its sign here anyway).
This should be backported to 2.74 (with previous commit too).
Using bool when we're asking yes/no questions such as whether some GPU
feature is supported.
Consolidated these simple functions into gpu_extensions.c and grouped
them in the header.
Const-ified some args where the functions don't modify the pointed-to
data.
