Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
rendering, to prevent any race condition problems
I've noticed some weird and random crashes recently while rendering,
which I suspect have been arising from having an Action Editor open
while rendering. Previously only the timeline was patched against
these problems, though the issues may be more widespread. Hence,
solving this problem at the root cause instead.
keyframe lines are wrapped up nicely by it
Ideally it could be made so that it only became wide when it is on a
frame with a keyframe, though that could end up causing performance
problems, so this will have to do (if a bit "chunky" looking at
times).
* Keyframe lines were being drawn too short when frame number box was
enabled. The code for drawing this was modifying the View2D view-space
to get it's stuff in the right place, but the timeline code was not
accounting for this.
* In order to make the time ticks more visible outside the frame
range, I've moved the start/end frame drawing stuff in timeline to
occur after the grid drawing, and to draw semi-transparent, just like
the preview range curtains in the other animation editors
Channels can now be used as "animation containers" to be filtered
further to obtain a set of subsidiary channels (i.e. F-Curves
associated with some summary channel).
The main use of this is that object and scene summary channels can now
be defined without defining the filtering logic in three different
places - once for channel filtering, once for drawing keyframes in
action editor, and once for editing these keyframes.
An indirect consequence of this, is that the "Only selected channels"
option in Timeline will now result in only the keyframes for a
selected bones getting shown (when enabled), instead of all keyframes
for the active object. This was requested by Lee during Durian, and is
something which has only become possible as a result of this commit.
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
Migrating "redraws" settings from TimeLine view data to per Screen.
The options are now still shown in the TimeLine "Playback" menu
though.
This means that whatever redraw settings you set in a TimeLine editor
will be used throughout a screen (i.e. editor layout) to determine
which editors will get updated during playback, instead of only
certain editors doing certain things at vague times.
---
Also, I moved some version patches pre 2.56 version bump into a
version-check for 2.56. These must've been missed when doing the
release...
* Argh my bad, sorry about this!
* Now only the actual data array is saved to avoid constant re-allocations, but no relations to active data are kept.
* Also reverted Ton's quick fix for the crash as it's not needed anymore.
* Timeline didn't listen to file read notifier, so the pointcache frames indicator didn't get updated.
* Also added listens to particle & modifier (cloth, sb & smoke) notifiers as changes that cleared a pointcache weren't shown directly in the timeline either.
* The timeline display was also always one frame behind the actual state, since the notifiers are handled before the actual dynamics are calculated.
** This is now fixed too, by creating the actual drawn data always at drawtime.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
Based on patch from Alexander Kuznetsov. Own changes:
- Keyframes in timelime depends on active object, so timelime better be
listeing to ND_OB_ACTIVE notifier rather than ND_OB_SELECT
- When scene is changing in this operator NC_WINDOW notifier would be send
and the whole interface would be redrawed, so no need in ND_OB_ACTIVE in
this case
* The existence of cached frames was checked each frame causing hundreds of disk operations per frame update.
* Pointcache now keeps an updated array of the cached frames for fast "frame exists in cache" queries.
* This fix also speeds up some other pointcache operations nicely.
This happened/was most noticeable when clicking on a bone of an armature in posemode but not active (i.e. some object other than the armature is active when trying to select the bone).
* Added ND_FRAME_RANGE to the header listener, changing frame range in Properties Window didn't update it in the timeline, reported by Hardworker in IRC. Thanks!
* Main Area Listener doesn't listen to all NC_SCENE Notifiers now, only selected ND Notifiers, like the header does. This is more efficient. If there is a reason to let it listen to all NC_SCENE notifiers, please tell me. :)
This started off doing pointcache debugging but it's also very useful for users too.
Previously it was very hard to see the state of the system when you're working caches
such as physics point cache - is it baked? which frames are cached? is it out of date?
Now, for better feedback, cached frames are drawn for the active object at the bottom
of the timeline - a semitransparent area shows the entire cache extents, and more
solid blocks on top show the frames that are cached. Darker versions indicate it's
using a disk cache.
It can be disabled in general in the timeline View -> Caches menu, or by each individual
system that can be shown.
There's still a bit to do on this, behaviour needs to be clarified still eg. deciding what
shows when it's out of date, or when it's been played back but not cached, etc. etc.
Part of this is due to a lack of definition in the point cache system itself, so we should
try and clean up/clarify this behaviour and what it means to users, at the same time.
Also would be interested in extending this to other caches such as fluid cache,
sequencer memory cache etc. in the future, too.
