movie clip caches resulting in some unchecked NULL pointers.
Probably it'll be better to separate memory limitors for cache and
clips or double-check priority functions are fine to deal with
such cases.
(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!!!
The previous stroke creation procedure was trying to clean stroke topology
by removing overlapping stroke vertices in the same 2D location. The idea
was to avoid having to address this kind of singularity during subsequent
stroke shading. In-depth analyses revealed, however, that this was a wrong
way to ensure clean stroke topology, since just deleting overlapping vertices
may break the continuity of the underlying series of FEdges on top of which
the stroke has been built. Such a break of linked FEdges was a major cause
of frequent failure in CurvePoint::getFEdge().
The present commit aims to address the singularity issue by adding small
offsets to the 2D location of overlapping vertices and making them
non-overlapping to each other. Since the offsets only result in sub-pixel
differences, the impact on visual outcomes is expected to be negligible.
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.
Notes:
* This is a somewhat reworked version of what is currently in bf-translation's trunk/po/tools, not yet fully functionnal (well, 95% is ;) ) nor fully tested. ultimately, it will replace it (being "svn-linked" in bf-translation).
* Added feature: more complete/strict tests (yet some work to be done here).
* Added spell checking (huge spellcheck commit incomming...).
* Trying to get rid of xgettext itself (should e.g. allow us to use #defines as contexts, among other things...). But currently captures less strings, work needed here too.
Please note this includes libfribidi.dll, as it is hard to find it for windows (unixes should have no problems here).
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.
