This commit clarifies the somewhat "murky" separation between "builtin" and "absolute" KeyingSets as a result of discussions with Cessen.
* "Builtin" Keying Sets are now just the Keying Sets which in the past have been known as PyKeyingSets or Relative KeyingSets. These are registered from Py Scripts at startup, and will use the context info to determine what data they should be keyframing. These are stored per Blender session, independent of files, since usually these will be coded specific to sets of rigs used at a studio.
* "Absolute" Keying Sets are the ones that you can create from the Scene buttons and/or KKEY or RMB over any property. They specify the exact set of properties which should always get keyframed together. These are stored in the scene.
In relation to this, I've made it possible to now set one of the builtin Keying Set types as the active Keying Set.
* For now, this can only be done via the box beside the insert/delete key operator buttons on the TimeLine header (now complete with an recycled icon - HINT TO ICON DESIGNERS, to make this a bit more obvious). Later on I'll commit an operator to set this via a hotkey.
* The "IKEY" menu will only show up when there is no active Keying Set. When there is one, keying will happen silently (with info notice at the top of the screen). Later on, I'll hook this menu up to a hotkey, so that that active Keying Set can be changed without inserting keyframes or clearing active Keying Set...
* By default, there isn't any default Keying Set enabled. IMO, this is probably a good default, though some might like to have LocRotScale instead.
* I'm not terribly impressed with the search menu for the items being SORTED (and of all things, alphabetically!) currently, since this does break muscle-memory with the menu (and jumbles up order of closely related vs not closely related).
* The Scene buttons for KeyingSets still need some changes to fully cope with users setting builtin KeyingSets as active sometimes. Controls which are useless or shouldn't be used when a builtin set is shown are being shown.
Builtin set registrations have been tweaked a bit:
* Renamed "bl_idname" to "bl_label" for consistency with rest of API. Note that this is the identifier used by Blender internally when searching for the KeyingSet, and is also what the user sees.
didnt commit this patch because curves are generally better to create a shape to lathe however now that curves can have modifiers applied to them I think its good to have this.
Added options to offset the lathe so it can work like the screw tool as well.
- optional object for axis which also controls the center point.
- screw offset so rather then just lathing this can work more like the screw tool.
- screw optionally using the object distance along the axis.
- iterations so the screw can be applied multiple times.
tested to work well with curves.
* Copy/Paste operators for F-Modifiers
Available in Graph and NLA Editors. Use the Copy/Paste buttons beside the 'Add Modifier' buttons.
Copy copies all the modifiers of the ACTIVE F-Curve or Strip depending on the editor.
Paste pastes modifiers from the buffer to all the selected F-Curves or Strips, adding the new modifiers to the ends of each list.
* 'Stepped Interpolation' F-Modifier
This modifier holds each interpolated value from the F-Curve for several frames without changing the timing.
This allows to preview motions 'on-twos' for example without altering the timing, or having to go through setting heaps of keyframes. In this case, Andy wanted to use this for CG <-> StopMo.
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
- Replaced hardcoded nurbcol array with theme colors
- Send notification in duplicate curve operator (this operator could
reset/change active nurb)
- Edge seam color added to the user preferences dialog
------------
Correct problems with edgetag_context_set(), edgetag_shortest_path(),
minmax_tface(); parameters were missing or of incorrect type.
Joseph: please review these changes.
* move own thread handling for thumbnails to WM_jobs
* cleanup of thumbnail creation code
* added function to kill the job, which actually allows thread to terminate gracefully
vc9 projectfiles:
* fixed some missing includes for release target!
unrelated changes that ended up being more trouble to commit separate...
- removed BLI_split_dirfile(), was nasty, occasionaly modifying the source string, it could create directories and used the $CWD in some cases. was only used in 2 places in filesel.c, if this gives problems can address without bringing back this function.
renamed BLI_split_dirfile_basic --> BLI_split_dirfile
- view3d_operator_needs_opengl was being called for offscreen render when it wasnt needed.
- new mode for projecting an image with the view matrix saved in the image id-properties rather then using the camera matrix.
- operator to screenshot the view and create a new image with the view matrix stored in the image.
these will be used for better re-project integration and are not immediately very useful.
Reports (i.e. 'info' or 'errors') are now shown in the info header in place of the scene statistics if the last executed operator had some, with this info disappearing again once another operator is run (to show scene statistics again).
For example, this means that info such as the the number of verts merged, or whether a Keying Set successfully inserted keyframes, etc. is now shown again somewhere, and that this is done in a non-blocking manner.
The current implementation is still a bit crude (i.e. lacking fancy polish), but is at least barebones functional. The todos...
* When more than 1 report message is generated by the last operator, there is currently a display of the number of reports. In future, it would be nice to be able to add a button beside this or make the label clickable with appropriate text indicating this (commented out atm) to show popup menu of all the reports...
* There could probably be some kind of coloured backdrop behind the text. Currently using standard box, but that has padding problems, and lacks visual interest.
* Timer based fade out/disappear?
Texture animation is now shown in the animation editors. Texture stacks are shown for each Material/Lamp/World block that uses them.
There is currently still a bit of a bug with this which means that unless the owner of the texture stack is animated too, the animation data for the textures won't show up. This will get rectified soon though.
Note, this is not like GE ffmpg, but Blender Image Texture
display for GLSL materials. Speed can be disappointing,
use smaller images for realtime edits.
This commit restores the 'Playback FPS' option which showed an indicator of the frame rate of animation playback in the 3D-View.
The info for this is now stored in a temp struct in scene data, with the status info being updated by the "animation step" operator instead of relying on globals as the old code did. This seems a lot more stable than in 2.49, but the accuracy is still questionable.
- 'Toggle' operators for channel settings now now act more like the select-all type of "toggle" operator. The old behaviour has now been moved to "invert".
- Channel settings are now flushed (like for visibility and when clicking) for muting and locking when using the operators
* Fixed problem where selecting an individual F-Curve would not set the selection correctly.
Group channels still needed a separate selection check before they get included in the filtered list. I had removed this in an earlier fixing commit today, but overlooked that expanded groups wouldn't get this check. Therefore, group channels would also be flushed on, turning all channels of group on.
* Removed the 'curvesonly' test from deciding whether the selection status + collapsed group fix, from the earlier commit, since this was making a few cases get overlooked (namely for setting visibility toggles, where selected F-Curves in closed and deselected groups still managed to get through)
* Added a debugging print API call for helping with debugging this sort of error in future. It just prints the types of channels being operated on, to easily see what's going on...
This commit introduces the Select More/Less Operators (Ctrl +/-) for keyframes. This works like the ones for curves, by only selecting/deselecting keyframes lying in the same F-Curve. Inter F-Curve selection is not done by this operator. That is the job for another one.
This is especially useful for F-Curves set in the 0-1-0 pattern (i.e. 3 keyframes forming localised peaks), where the peaks can be selected by clicking on them individually, and immediately surrounding '0' values are selected too using "Select More".
set the draw method to triple buffer or overlap depending on the
configuration. Ideally I could get all cases working well with triple
buffer but it's hard in practice. At the moment there are two cases
that use overlap instead:
* opensource ATI drives on linux
* windows software renderer
Also added a utility function to check GPU device/os/driver.
This commit introduces a few cleanups and tweaks to the way that timecodes (i.e. the timing indications used instead of frame numbers) get displayed.
1. Custom Spacing of TimeCodes/Gridlines
Made the minimum number of pixels between gridlines/timecode indications a user-preference, instead of being a hardcoded constant. This allows to set the spacing tighter/looser than the defaults, and is also used for the other changes.
2. Default timecode display style, (now named 'minimal') uses '+' as the delimeter for the sub-second frames. This hopefully makes it a bit clearer what those values represent, as opposed to the '!', which can sometimes look too much like a colon.
3. Added various timecode display styles as user-preference. - These include always displaying full SMPTE, to showing milliseconds instead of frams for sub-second times, and also an option to just show the times as seconds only.
- When changing the timecode style, the spacing setting is automatically modified so that the timecodes are spaced far apart enough so that they won't clash (under most circumstances). This automatic modification is only done if the spacing is too tight for the style being set.
4. Unified the code for generating timecode strings between the View2D scrollbar drawing and the current frame indicator drawing.
I've removed editmesh altogether (other then scanfill, which is
seperate code that happens to reuse the editmesh structures).
The compatibility layer I had written for old editmesh tools
was more trouble then it was worth, though it did help in the
early stages of this project.
There's a fair amount of breakage, and there's bunches of tools
(mostly minor ones) I need to port over still. Biggest ones are
join triangles and loop to region, and spin/screw.
This probably isn't really testable, I'll hopefully have more
work done on this soon, but might not be before next week.
* The Lift/Gamma/Gain formula previously was incorrect, fixed this and
removed conversions - now the RNA values are the same as what goes into
the formula.
* Because of this, added the ability for the Value slider to map to a wider range
than 0.0-1.0. The black/white gradient remains the same, in this case just
indicating darker/brighter rather than absolute colour values. Also added ability
for color wheels to be locked at full brightness (useful for this case, where the
color value itself is dark).
* Added an alternate formula - offset/power/slope (asc-cdl). This fits the standard
Color Decision List formula, here for compatibility with other systems, though
default Lift/Gamma/Gain is easier to use and gives nicer results.
