Adding documentation strings in argument data.
--help is auto generated (options not manually categorized end up in the "others" section at the bottom)
- fix implicit decloration of DAG_scene_sort()
- same fix for tiff as made in renderbranch
- rename 'combined peak' --> 'peak' for shorter messages while rendering.
* Keyboard Sensor entry keys (key, modifier 1 and 2) can actually be any key
- (you can use Shift as main key, and D as modifier if you want). It's
- strange in my opinion, but it's 2.49 way of doing it.
* Copy Game Property (operator found in SPACE menu)
- reorganized it so the properties appear as submenu items.
- a "little lot" of work for such a small eye-candie but well I hope more
- people like it as well :)
Matt, I had to recreate the dynamic_enum to make it work. I'm count on you
for a real fix for this ;)
- swapped meanting of -y/-Y to enable/disable automatic python execution (matches window border -w/-W).
- removed '-B', no reason to have this.
- renamed -fpe to --debug-fpe and added to --help
When enabled the context's 3D view will be used for rendering.
When disabled a camera view with solid draw mode will be used.
(Needed for batch rendering out animation previews without having to worry about an existing 3D view, its local layer locking and draw type)
Animators were having trouble selecting keyframes and their handles when zoomed in extremely. This commit seems to fix these issues, which appear to have resulted from some overflowing ints, which gave out-of-view handles priority quite often.
This works by tricking the depsgraph into giving us a smaller list of objects to evaluate, with all the necessary objects + their dependencies at the start of the list.
On any complicated setup where non-object parameters need to be referred to (i.e. by drivers) to affect an object's transform, these optimisations will fail and the old (slower) method is still the best way (modify the ifdef and comment out the optimise depsgraph call to do so). However, we'll assume that these aren't too common in real productions, so things should be fine with these fixes. If there really is a need for both, then global options to control these things could follow.
* Removed dynamic linking libTIFF code and change it to static linking
(built into the blender executable). Dynamic linking made things a
fair bit more complicated and wasn't working at all before on OS X -
the dylib didn't exist and wasn't being copied. Since TIFF is more heavily
depended upon now in Blender, it makes sense to make it less 'optional'
and more in line with other libraries.
I've updated both CMake and scons, and CMake on OS X/64bit works fine.
It's now up to other platform/build system maintainers to enable this for
their respective platforms (Campbell will check it for linux). For windows,
and non-64bit osx, we need static libtiff libraries in /lib.
I've added options WITH_TIFF for CMake and WITH_BF_TIFF for scons,
so if blender won't build because of this, you should be able to disable
these options until your build system has been updated.
* Bonus feature: while doing this, I added support for loading 16bit and 32bit
per channel TIFFs - they get converted to Blender's float buffers. Handy for
zbrush displacement maps!
- #22155: keyframe dots not shown on path for bone keyframes that aren't in a group with a matching name. Since this situation is going to become more common in 2.5, I've added an option which will alternatively just search the entire action to find all F-Curves associated with bones. The old option is still the default though for the general cases.
- When keyframe drawing is enabled, the current frame will also be indicated on the path now as a (bigger) green dot, as requested by William. This makes it easier to see the position on the path on the current frame.
This panel allows editing of the coordinates of the 'first selected keyframe' on the Active F-Curve. That is, if you've got keyframes A (5), B (7), and C (12), and B & C are both selected, then the 'active keyframe' will be B.
While I still think it's more efficient to use the cursor for batch-setting a bunch of keyframes, there are currently problems using that for sub-frame placement on the x-axis.
Notes:
- There is none of the averaging crap from before, where no accurate value could ever be set.
- Take care when setting the values of the handles, since getting correct F-Curve recalc flushing working via the RNA stuff is VERY TRICKY, and has been left out for now to get something workable. I recommend setting the values numerically, then grabbing these keyframes and immediately cancelling, to get these updates done.
note: Im not all that happy with where this feature is going in terms of readability, however preview renders are very distracting when physics meshes and bounding boxes are animating over the top of characters.
This was caused by the multi-user data appearing multiple times in the channel list. Now most editing functions filter out duplicates before doing anything to prevent these problems.
Hopefully the additional cost of filtering the entire list an extra time won't be too much of a speed/mem hit...
looks like a threading problem:
Easy to redo, 1024x436, FSA, 4 threads.
With 1 thread it runs ok, need to look into this further but no time now so reverting.
* adjusts on Layout:
- in order to avoid much changes when copying Logics, it's nice to have the logic s/c/a always displaying even though it's not valid (e.g. edit mesh used from a camera object).
Now a message shows in the s/c/a alerting to the problem.
* logic operators under OBJECT_OT - copy properties and logics
Matt, is it possible to have the object game properties listed as a submenu from "Copy Properties" ?
So from the "Copy Game Property" menu we would have three options:
"Copy a property" -> (submenu) prop1, prop2, prop3
"Replace all Properties"
"Merge all Properties"
For the current task list in Logic Editor:
http://www.pasteall.org/13245
