(From personal stash of bugs - since early 2.5 versions)
F-Curve colors get applied only on Graph Editor "refresh()". In some cases, undo
was reverting back to a state where the colors had not yet been set. In these
cases, there would be no refresh() after that undo (until expanding a channel or
some other similar action), resulting in "black F-Curves" appearing. So, now we
force such an update after undo to ensure that the curves never display black.
(Noticed while investigating another bug for Mango related to
CLIP_OT_constraint_to_fcurve not sending notifiers required when new F-Curves
are added)
* Elbeem exporter code now overrides user settings to No Slip in case the object is animated;
* UI of fluid obstacles now disables slip settings when export animated is enabled;
* Added in this later option's tooltip a mention that it enforces No Slip!
Replace pseudo-LRU approach of determining which buffer
to remove when running out of space allowed for cache
with approach which would remove the frame which is most
far away from newly added frame.
This is still a bit tricky because it's impossible to
distinguish which frame to delete in situation of:
CCCC...CC
^
it's either user wants to extend left segment of cached
frames and buffers from right segment should be removed
or he wants to join this two segments and in that case
buffers from right segment should be removed.
Would need a bit more investigation which situation
is more common in general usecase.
Until now, there was never any code for making drivers on materials get
recalculated when their dependencies were changed. However, since changing
material colors with drivers is something that is quite common, a workaround was
introduced to ensure that materials could still be driven (albeit with the
relevant drivers rooted at object level). This worked well enough so far with
traditional materials - though it was sometimes clunky and confusing for some
users - and would have been ok to tide us over until the depsgraph refactor.
The introduction of Cycles changed this, as it has in many other ways. Now that
people use Cycles to render, they'll need to drive the material colors through
the nested nodetree (and other things nested deeply within that). However, this
is much more difficult to generate hacks to create the relevant paths needed to
work around the problem.
== This Commit... ==
* Adds a recursive driver calculation step to the BKE_object_handle_update()
(which gets called whenever the depsgraph has finished tagging object datablocks
for updates), which goes through calculating the drivers attached to the object
(and the materials/nodetrees attached to that). This case gets handled everytime
the object is tagged as needing updates to its "data" (OB_RECALC_DATA)
* When building the depsgraph, every dependency that the drivers there have are
treated as if they were attached to object.data instead. This should trick the
depsgraph into tagging OB_RECALC_DATA to force recalculation of drivers, at the
expense perhaps of modifiers getting recalculated again.
== Todo ==
* The old workarounds noted are still in place (will be commented out in the
next commit). This fix renders at least the material case redundant, although
the textures case still needs a bit more work.
* Check on whether similar hacks can be done for other datablock combinations
* So far, only simple test cases have been tested. There is probably some
performance penalty for heavy setups still (due to need to traverse down all
parts of material/node hierarchy to find things that need updates). If there
really is a problem here, we could try introducing some tags to limit this
traversal (which get added at depsgraph build time). <--- USER TESTING
NEEDED!!!
This commit enables color management stuff when building on
Windows using MSVC 2008 compiler. This required some fixes
to both CMake and SCons configurations which were tested for
64bit target. Tests of 32bit target would be welcome.
Also solved compilation error caused by recently added anim
player. Not sure how to test this, but it shall at least
compile on Windows now.
Didn't test MinGW compilation at all yet, could still be buggy.
This applies to files when saving from image editor and when saving
render result.
Currently only works for images which has got float buffer and saving
happens to byte formats (such as PNG, JPEG). Also supports applying
color management for preview jpegs when main buffer is saving into
OpenEXR file.
As default transform when saving from image editor would be the same
settings as image editor uses itself.
Defaults for color correction of rendered images would be default
display name, no view transform and default values for gamma and
exposure.
- Move color management display settings into own structure like it's
done for view settings.
This is helpful from two sides:
* It is planned to support display calibration settings which
should be taken into account by color management stuff to
add needed transformations to OCIO processor.
* File saving should be able to make the same display
transformations as it's done by window when displaying the image.
Having own DNA and RNA structures for display device settings
helps avoiding having duplicated code.
- Small refactor of cacheing functions which are now accepts
cache-like versions of view and display settings. This structures
used for cache are quite the same as DNA structures but they contains
indices of view and display which avoids extra lookup for this
things.
This also helps having reasonable amount of variables passing
to cache functions.
Issue was caused by linking to grease pencil from direct_link* function
which lead to NULL GP data because it's being read a way later.
Link to GP data in lib_link* instead.
- Added some extra view transforms to play with. It's not absolutely
correct in terms this views were changed to use aces space as input.
This gives exactly the same result as if using stand-alone spi-vfx
and nuke-default configuration, but for real merge of this configs
it'll be needed to add extra input spaces and transformations between
them.
- Replaced hard-coded aces input color space with default ocio
linear space which makes it easier to play with different
configurations.
- Fixed SCons installation of color management configuration which
used to skip copying LUTs when there was "luts" folder in install
destination.
- Print whether OCIO was enabled when building with CMake.
Could be helpful due to OCIO is being automatically disabled
if needed libraries are missed.
