| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds a new mode for the Propagate Pose tool. With this new option,
the Propagate Pose will copy the current pose over to all selected keyframes
after the current frame.
For reference, some of the other/existing options are: to copy it to each subsequent
keyframe with the same value (WHILE_HELD - the default), to the next keyframe,
or to the last keyframe.
|
|
|
|
|
|
|
|
branch
|
|
merge conflicts with master.
|
|
Conflicts:
source/blender/blenloader/intern/readfile.c
source/blender/editors/space_view3d/view3d_intern.h
source/blender/makesdna/DNA_modifier_types.h
source/blender/makesrna/intern/rna_modifier.c
source/blender/modifiers/MOD_modifiertypes.h
source/blender/modifiers/intern/MOD_util.c
|
|
This works by using the distance in the x axis only (usually artists want to influence nearby
keyframes based on timing, not value). Tweaking handles is the same as tweaking
the central handle. It's a bit ambiguous if proportional editing is really meaningful
for handles but will leave that for artists to decide.
|
|
|
|
libraries.
Having a cache archive output in each modifier is not really practical.
Now the cache library has at most 2 file paths. These are used based on
2 associated settings: source mode/path and display mode/path.
* The SOURCE mode determines whether the original scene data is used as
input or a cache archive. If the scene input is used the dupli group
objects will be evaluated as usual with Mesh data, modifiers, proxy
armatures, etc.. With cache input the data stored in a cache is used to
override the scene data instead.
* The DISPLAY mode is essentially a toggle for the whole cache modifier
stack. If it is set to 'source' the respective source data is used
without further modification. If set to 'result' the data from the
output cache archive is used, which can be generated using the bake
operator. During baking the data will be passed through the cache
modifiers to create a variation of the original source data.
|
|
This modifier can be used to correct bad deformations,
Original patch D1183 by @sazerac, with own modifications
|
|
Now the filtering is simply based on the data types that should go into
the cache, instead of selecting each object and component individually.
This is slightly more limited and may need to be revisited again later,
but for the time being it is much less confusing and clumsy. Filtering
by objects can be accomplished by creating groups accordingly. Making
groups specifically for caching is totally acceptable.
|
|
|
|
`cachelibrary.bake`.
|
|
To match other modifiers.
|
|
|
|
Cache baking means the cache modifier should read input caches over the
given frame range and produce the correct output for writing into the
output cache file.
Cache modifiers can optionally implement a 'bake' function. This is used
through a bake operator from the cache modifier panel. Baking is
executed in a job, which will help with cancelling bakes and displaying
status info.
|
|
Only" is enabled
The "Layered" option for auto keyframing will create a new NLA strip if playback
reaches the end of the frame range and jumps back again. The idea is that instead
of overwriting the keyframes you've already made, it will make a new animation
layer. However, this does not work with the "Insert Available Only" option
(which can either be set in the User Prefs, or in the active keyingset), as that
option needs some existing FCurves to tell what it can insert keyframes into.
The "fix" here is to simply not show the offending button in situations where it
cannot be used!
|
|
F11.
|
|
dupli cache.
This makes the cache modifier stack work more like actual modifiers:
Each will take the previous result and write it into its own output
file. The last output is the final result used for viewport display.
|
|
This system imitates the modifier stack for mesh objects. It will be
used to handle simulations and similar processing of cached data.
|
|
There are two per-editor settings now, the Per-Strip setting (default)
and the Project setting.
The per strip setting basically uses the previous, per-strip options for
storing the proxies.
The project setting though will use a specified directory for -all-
proxies, or the blend file directory if no directory is given.
|
|
|
|
This reverts commit ec03ab021f171bf529746bb440756fbc986b45e7.
Changing this since it looks like Mattieu does not really like the change.
Will be adding another way to tweak the directories
|
|
This is the default now. It should make workflow a lot more foolproof
and convenient, since having only one of these modes active at a time
very easily leads to broken renders and confusing situations.
The problem is mostly due to the complicated way the depsgraph layer
feature is used to handle duplicator visibility. The duplicator is
declared as a child of its group's objects (even though no real
dependency exists!), so that a visible duplicator triggers updates of
invisible group objects, making instances of hidden groups possible.
However, dupli caches have to disable this dependency in order to avoid
unnecessary costly updates in hidden layers which are overridden by
cached data anyway. At the point where these dependencies are created
the evaluation context is unknown though, which means we cannot
distinguish between render and realtime evaluation for the purpose of
cache reading ...
|
|
an enum toggle.
|
|
pointer instead.
This change makes it possible to have group duplicators using different
versions of a cache.
|
|
pointers.
Relationship between CacheLibrary, duplicator Objects and Groups is
difficult. There are a number of somewhat conflicting goals:
- CacheLibraries write out data for objects and dupli groups. Multiple
objects can be stored in the same cache: CL *->* GR
- Objects can override a dupli group with different caches: OB *->1 CL
- As before, each object can be the duplicator for one group: OB *->1 GR
To combine these requirements, the first relationship will be made
indirect. Only the Object -> Group/CacheLib relations are explicit
pointers in the DNA. For finding all objects contained in a cache
library the usual recursive DNA tagging system must then be used.
|
|
At this point the reading is toggled on the side of group duplicators.
|
|
The cache is now updated on frame changes automatically, the operator
should no longer be needed.
|
|
unnecessary dependencies.
This flag will replace the current "read" mode on cache libraries.
Beside enabling cache reading, it also disables the current "fake"
dependencies between duplicators and their group objects. This is
exploiting the layer visibility mechanism in depsgraph to ensure that
animated group objects get evaluated when used by a visible duplicator,
even when they are not themselves visible. These dependencies cause
group object updates even if the duplicator is using cached results.
To avoid this unnecessary overhead and make caching worthwhile we
rebuild depsgraph without these relations when using the cache instead.
|
|
This is a placeholder for proper depsgraph integration. Eventually frame
changes and some other updates should rebuild dupligroup caches
automatically using the depsgraph. Until then this operator is a quick
way to test the IO from caches and the further drawing and rendering
(TODO).
|
|
but disabled, in that case hide them as well.
|
|
This creates a string with information about all the objects and
properties contained within a (Alembic) archive, used by a cache
library.
The operator has 3 modes of presenting the info string:
- stdout, ie. printing to the terminal
- popup window (not very useful usually due to size limits and lack of
scrolling)
- clipboard copy
|
|
|
|
This designates a cache library to be used either for the viewport or
for renders. A "Render" cache library will evaluate modifiers with
render settings and a "Viewport" cache library will use viewport
(realtime) settings.
When reading the cache, the library will only be
used for the assigned purpose, i.e. a Render cache does not work for
viewport caching and vice-versa (although a cache can be baked for one
setting and then switched afterward).
Note that render results will never be visible in the realtime viewport
due to the way object evaluation is handled in Blender at this point
(render settings are only evaluated explicitly during renderer sync).
Conflicts:
source/blender/blenkernel/intern/particle_system.c
Conflicts:
source/blender/blenkernel/intern/particle_system.c
|
|
items.
|
|
python code to unify symbols.
This is necessary because the operator for adding new items (as opposed
to the enable/disable button) cannot be shown with the same checkbox
button. The UI template function can display a custom button for the
operator, so the look becomes less confusing.
|
|
In addition to the object name filtering, items in cache library groups
can now be filtered by type as well.
Existing items in the cache are always displayed, so as to not hide
important information (what gets stored in the cache). The filtering
is primarily a utility to simplify searching inside the group for things
that should be added to the cache.
|
|
cache library items.
This should ideally happen on the RNA side, but making the equivalent of
python generators in the RNA is really difficult.
|
|
|
|
This requires a better design and is not so easy to implement properly
within the limits of RNA definition. These collections don't physically
exist in the DNA, they are mainly utilities for looping over
//potential// items in a cache library. For now the python code has to
be adapted to only show valid items, until the RNA provides a good
solution.
|
|
This is a preliminary feature and implemented purely in python, to be
replaced later.
|
|
This is also used during the bake process to avoid confusion: The read
flag gets disabled for the baking cachelib, so that objects don't try
to read cache data that is supposed to be generated.
|
|
CacheLibrary datablock has a generic unlink function now, but currently
nothing actually links to cache libs themselves, so it's empty. Still
good to keep this in mind for the future.
|
|
Cycles render engine.
The "compat_engines" thingy really gets in the way here ...
|
|
cache library system.
The Cache modifier is now an optional "break point" of the modifier
stack:
- Without a cache modifier the stack works as before. Baking will write
the final stack result. After baking the cache replaces the whole
stack.
- With a cache modifier the stack result at the modifier's position is
stored. The cache is then applied as the output of that modifier,
skipping preceding modifiers. That way additional modifiers can be
applied on top of the cache.
- When using multiple cache modifiers, only the last (active) one will
be used, since all previous cache results would be discarded anyway.
|
|
|
|
|
|
Libraries.
|
