object_apply_mat4 was incorrectly negating the matrix values,
This worked in most cases but even when it worked would end up with negative scales too often.
now when no negative scale is used they will all stay positive and from my tests it works in all cases now.
- open operator was incorrectly checking if the font path was set.
- rna ID editable check was also incorrect, checking the ID name rather then the filename.
- use define FO_BUILTIN_NAME rather then "<builtin>".
- rotation and bone scaling with Durian feature 'Local Location' would fail to correctly translate the bone
because a different matrix is needed for translation and rotation.
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.
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.
