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.
Reported by Lluc Romaní Brasó
Some of my earlier changes to the modifier handling code accidently sent out new events for modifier keys when they where held down (repeat).
Also lay foundation for shift+numpad handling.
There was a slight discreptancy between the tail values calculated on the spline before the head was displaced for the "chain offset" option and after this operation. However, only the original version got set.
This small difference resulted in B-Bones thinking that the endpoints of the bones were in places that they were not in, hence causing the curly patterns observed in the report.
- armature_mat_pose_to_bone() was missing axis-angle check.
- added loc_axisangle_size_to_mat4() for completeness.
- use 'const' prefix where possible in math rotation functions.
reported on launchpad.
calling glClear(GL_COLOR_BUFFER_BIT); was crashing blender,
since this is only used to blank the window before its drawn, disable for opensource ATI drivers.
* This fix is really only a bandage, as the underlying issue is that sequencer preview render doesn't yet use the job system.
* The sequencer preview can start a full render of the scene, and this can collide with other preview/actual renders in many cases.
* Drawing the sequencer preview is now disabled when an other render is in progress, but the sequence preview rendering could have already been started before the other render, so this doesn't really fix anything.
* For now only OpenGL rendering can be used for the sequencer preview reliably until it's reimplemented using the job system.
* Using the job system in the future can handle the clashes between different renders properly and will give users a nice progress bar to indicate something is happening while the preview is recalculated.
After discussions with Campbell regarding #24336 and #24309, we've decided to make this property for curves to only get set when an F-Curve explicitly animates it.
As a consequence...
- ALL OLD FILES using follow-path constraints that depended on this changed behaviour will currently need manual patching to add an appropriate F-Curve
- Ctrl-P (Parenting to Curves -> Follow Path option) will now automatically create such F-Curves mimicking the old behaviour so that creating camera-following-path setups still works smoothly.
- Directly adding a Follow Path constraint bypasses this, so you'll need to manually add such F-Curves if you need them.
The main problem with the old approach was that there were many cases in which curve data could get added but the ctime would be incorrect until a frame change (i.e. on render) flushed this.
The problem is the opensource nvidia nouveau drivers are slow running glReadPixels(), was hanging on memcpy().
However for autodepth its not needed to update the entire 3D view depths, so added view3d_update_depths_rect() to get the depths for a smaller area.
Rather then have the modifier calculate ORIGINDEX weather its needed or not (incorrect if it wasn't the first modifier on the stack),
create ORIGINDEX layer initially if any of the modifiers use it.
This way hook also works after Mirror and Screw modifiers which have the ORIGINDEX layer copied implicitly with DM_copy_vert_data().
This wasn't possible to check for before because this flag was always enabled so it would be passed to DM_set_only_copy().
Now just add the flag whenever calling DM_set_only_copy().
committed r32598 to fix [#24309] Reloading file with incorrect path location.
Setting the curves ctime when updating the object data overrode the animated value.
For now just set the ctime on newly added curves with will work as the user expects in most cases.
This is weak design IMHO because the ctime value can be set to anything but is reset on changing frames even if its not keyed.
With curves created via python or linked in this can still result in a bad ctime value.
