Seems to be only related on linked nature of particles.
This is caused by some conflicting optimization done for viewport, which
does not do particles re-calculation if they do not depend on time
(which is crucial for big layout scene grass fields) and particle render
setting switch which was relying on fact that render pipeline will do
particle update via time dependency.
Now we extent an old workaround for invisible objects, which now also
deals with particles in the same way as old dependency graph was dealing
with this: tag object data for update if there is particle system.
There shouldn't be any speed difference between old and new depsgraph,
since tagging was already needed and was happening.
In Blender 2.8 such things should be easier to deal with since the whole
depsgraph is to be evaluated for render engine anyway.
In preparation of the removal of blender internal render we
moved the vectorblur code that was placed in the render package
(legacy) to the compositor. The compositor is only using this
code even the blender internal renderer did not use the code at
all.
- Metadata handling is now separate from `ImBuf *`, allowing it to be
used with a generic `IDProperty *`.
- Merged `IMB_metadata_add_field()` and `IMB_metadata_change_field()`
into a more robust `IMB_metadata_set_field()`. This new function
doesn't return any status (it now always succeeds, and the previously
existing return value was never checked anyway).
- Removed `IMB_metadata_del_field()` as it was never actually used
anywhere.
- Use `IMB_metadata_ensure()` instead of having
`IMB_metadata_set_field()` create the containing `IDProperty` for
you.
- Deduplicated function declarations, moved `intern/IMB_metadata.h` out
of `intern/`. Note that this does mean that we have some extra
`#include "IMB_metadata.h"` lines now, as the metadata functions are
no longer declared in `IMB_imbuf.h`.
- Deduplicated function declarations, all metadata-related declarations
are now in imbuf/IMB_metadata.h.
Part of: https://developer.blender.org/D2273
Reviewed by: @campbellbarton
- Use BLI_threadpool_ prefix for (deprecated)
thread/listbase API.
- Use BLI_thread as prefix for other functions.
See P614 to apply instead of manually resolving conflicts.
It seems to be useful still in cases where the particle are distributed in
a particular order or pattern, to colorize them along with that. This isn't
really well defined, but might as well avoid breaking backwards compatibility
for now.
The reason it appeared working was due to left-over debug code to force
time dependency.
Real fix seems to include force tagging objects used by duplication,
similar to what we do for some other modifiers already.
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
These and other non-RGB passes should always be stored as full float, the
precision loss is too unpredictable.
Related to T53381, but that one is about file output nodes where we don't
know the type of data being saved currently.
* Fix saving a multiview render from the image editor giving invalid files.
* Fix failure to load multiview images with a single view per part.
* Fix loss of multiview metadata when saving/loading a single view.
* Fix Z-Buffer writing option for single layer EXR not being respected.
Multiview EXRs are now always handled as multilayer internally, significantly
reducing the amount of code.
Reviewed By: dfelinto
Differential Revision: https://developer.blender.org/D2887
This makes code closer to id_override/assent-engine ones, which
introduce a new type of linked data, and hence reserve
ID_IS_LINKED_DATABLOCK to real linked datablocks.
