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>".
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.
* 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.
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.
Fixed bug #22634, sculpting/multires and wireframe display mode glitches
* Changed ccgdm edge drawing to always use face griddata rather than edge data, since edge data is not updated during sculpting.
the cu->ctime was never set if the frame wasnt changed, so adding a curve and parenting could be done without a frame change leaving the cu->ctime value at zero.
changing the frame or rendering after this would make the parent relationship jump.
Set the curve->ctime in object_handle_update(), this way its set on file load and when linking in new curves.
Another option is to do this when parenting but probably this would miss other cases where its needed.
--- fixes report by ronan ducluzeau
Scale default cube on X axis to -1.
Rotate it on X axis to 33°.
Parent cube to lamp.
Clear parent and keep offset.
Cube's scaling value on X axis pass from -1 to 1
Cube's rotation value on Z axis pass from 0° to 180°
Both stored the filename of the blend file, but G.sce stored the last opened file.
This will make blender act differently in some cases since a relative path to the last opened file will no longer resolve (which is correct IMHO since that file isnt open and the path might not even be valid anymore).
Tested linking with durian files and rendering to relative paths when no files is loaded however we may need to have some operators give an error if they are used on the default startup.blend.
the bug was in object_apply_mat4(), caused by applying a non-normalized matrix to the rotation.
Blender 2.4x also had this problem, surprising nobody noticed!.
- omit render code from this warning (cmake only), until render branch is merged.
- moved -Wunused-parameter warning to apply to all C code in blender (not just ./source/blender), (cmake only).
- mdisp_corners used to return incorrect number of verts in some cases
- fixed memory corruption when face changed vertex count in
edit mode (forgot displacement for such faces atm, could be changed
in the future)
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
This should help silence complaints from some about "dloc",etc. not being easily keyable.
It's also a nice way to have instances of animated objects located in different places, by animating either the standard transforms or the deltas, and then modifying by not animating the other version to keep the instances from going to a single point. This was a common newbie problem in 2.4x.
When editing an action used by a NLA strip and editing it 'in place' (controlled by pin icon on green 'tweaking' channel), the animation would only get played back in the action's original frame range while the keyframes were still displayed in the strip-altered positions.
