Merged 'backend' changes from AnimSys2. Many of these changes are necessary for the Dopesheet and other changes I'm currently still stabilising. Those will come in due course.
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
* For constraint mesh-targets, the check for whether the target mesh was in EditMode didn't check to see if the target mesh was the mesh in EditMode.
Thanks jaguarandi for catching that!
* Bumped up size of buffer for grease-pencil drawing after seeing a program written in 1989 that had a 100 times larger buffer
Originally the only way to run scripts automatically was with scriptlinks, which could be disabled for loading untrusted blend files.
Since then PyDrivers and PyConstraints would run even when G.f&G_DOSCRIPTLINKS was disabled.
Gensher, Theeth and Ianwill agree its acceptable to reuse the flag for other areas python runs automatically.
PyNodes still have no way to be disabled, (todo before 2.46a)
Unfortunately, my previous fixes here to get gears working resulted in this problem. The flip side of that was that gears worked for quite a few cases.
Alas, it is not to be... The bug is now fixed, but gears no longer work any more. Sadly, there is not much I can do about this.
* Bugfix #8599d:
When using the ChildOf constraint on bones without parents, with cyclic-offset in action the effect of the cyclic-offset was applied twice. Added a bone option to make the effect of cyclic-offset not be applied to rootbones which have the option 'enabled'.
In the UI, this is presented in the opposite way. It is represented by the 'Offs' button beside the parent-bone selector in the Armature Bones panel when in EditMode.
* Head/Tail setting and Constraint Channels:
Added back in checks to see if the head/tail IPO-curves for Constraint Channels can get applied for the target constraint. I had removed these when applying the patch, but I'd overlooked the fact that users could add an IPO-curve for this from the IPO-editor, potentially mucking up the behaviour of some constraints.
Finishing off some unfinished business (from the multi-target constraints work), it is now possible to get/set target-space for constraints where this is relevant.
For this to be possible, target-space setting(s) are now always presented as a list of ints, with each int representing the target-space setting for the relevant target.
Constraints C-API note:
get_targets function now needs to return the number of targets the constraint can have
This time is was due to different accuracy of floating point computation,
now it uses does a comparison a bit different to avoid this.
Also changed the vectoquat function to be threadsafe.
This bug-report brought to light some problems with the transform constraint's handling of degrees+radians. Now, the input-range scaling is done in degrees (as the clamping factors ranges are in degrees) instead of having that done after this stage. The problems should now be fixed (and gears now seem to work ok), but I hope no other rigs have been broken.
* Optimised transform constraint a bit
* PyConstraints now show the script-selection menu correctly when a new constraint is added (i.e. it now displays the correct initial value).
Added a new constraint, "Limit Distance". This constraint defines a 'virtual sphere' around the target which the owner can be made to stay inside, outside, or on the surface of it.
This constraint is best used when applied using the Ctrl-Alt-C hotkey, as the radius is set correctly that way.
One usage, is to prevent the target of an IK-chain from straying away from the chain. Care should be taken to not use a member of the IK-chain as the target though.
Description of Variables:
* 'Dist' - Radius of virtual sphere
* 'R' - Click on this to recalculate the 'Dist' value (note: like the 'R' button in the StretchTo constraint, this is currently buggy)
' Mode' - This menu gives different options for how the limiting sphere should act. The mode names are self explanatory.
* 'Soft' and 'SoftDistance' - currently not functional (so settings are hidden). These are used to define a smaller radius around the sphere of influence where a non-linear relationship between input and resulting locations occurs to prevent the owner 'crashing' into the sphere.
Basically, this is based on the behaviour of the unique_constraint_name (or equivilant) functions, which have traditionally been duplicated everytime a new datatype needed this.
Currently, this is in use for the following things:
* Constraints
* Action/Bone Groups
* Local Action Markers / PoseLib poses
Usage Notes:
* The file in which this is to be used should include the standard header file <stddef.h>. This defines the offsetof() macro, which should be used to find the relative location of the "name" member of the structs
* This function is only designed for names of up to 128 chars in length (Most names are at most 32. TimeMarkers are 64). If a longer string needs to be handled, the function will need to be modified accordingly.
* defname is the default name that should be used in case one hasn't been specified already
I'm committing some work-in-progress code for "bone groups" now, as I there have been are some major bugs caused by the timeoffset stuff (some of my test files were not loading, and other files were showing all sorts of weird problems).
Anyway, in this commit, the following things for "bone groups" have been done:
* Bone groups are stored per armature (internally, this is per bPose block)
* Added controls for editing bone-groups per armature - "add", "remove", "rename". These can be found in the "Links and Materials" panel in PoseMode, beside the settings for PoseLib.
* Reorganised buttons for editing selected bones in PoseMode. I've replaced the "dist" and "weight" buttons (they existed in EditMode anyway) with a menu to choose the bone-group and the custom-shape-ob field. In the place of the old custom-shape-ob field, I've restored the "Hide" button. This might break muscle-memory a bit, but there isn't a lot of space to play with there.
Some stuff I'd been originally planning to do before committing:
* When adding keyframes for bones, an action-group with the same name as the bone's group will be added to the action, and the action-channel will be made a member of that.
* New action/bone groups have unique names (renaming/adding new should check if name exists before assigning it)
* There's a setting under Bone-Groups stuff which sets which custom-colour set is used to colour that group's bones. Currently, this is non-functional, as the necessary drawing code for armatures is not in place yet.
Proxy protected bones can now get local (per-file) constraints added to them, which will be preserved after a file load. This is necessary for adding constraints to proxy-protected bones for special purposes while animating (i.e. adding CopyLocs to IK-hand controls to pick up an object).
These must be added after any constraints from the proxy, as proxy constraints may come and go without warning. As such, the UI forbids this from happening by removing the relevant button.
I've also made UI-changes to show which constraints come from the proxy (the buttons to move the constraint up/down and delete it, are replace with two icons - a the proxy 'ghost' icon and a lock). Also, trying to change any settings of proxy-protected constraint will show an error.
Notes:
* Object constraints are still not playing nice with proxies yet. They didn't before this commit either...
- first work on getting area/screen handling back
- added structure for where to put stuff, is still under
review, wait a bit for docs?
Campbell is working on removing every bad level include from
sources, so we can safely rebuild the src/ directory.
IK-constraint "flush_targets" function was causing segfaults on debug builds from certain MSVC compilers.
The cause of this, is that ct is freed in the SINGLETARGET_FLUSH_TARS macro already, but ct is accessed in the following line to get the next target (ct= ct->next). Caused by brecht's commit for the pole-target stuff for IK-constraint.
Now the SINGLETARGET_FLUSH_TARS macro, and the SINGLETARGETNS_FLUSH_TARS macro will correctly advance the location that ct points to.
-> Constraint Influence Ipo now can be local, linked to constraint itself
You enable this in the IpoWindow header, with the Action icon to the left
of the Ipo Type menu. The button tooltips give the clue as well.
Tech note: the Ipo now can get directly linked to a constraint, and is
being called during regular pose constraint solving.
Actions (and drivers in actions) are being calculated *before* pose
constraint solving. Result of actions then is written in bones, which
then solves the entire pose.
This means you can have a driver on both the constraint, as on the action
channel for the constraint! Not that I'm going to debug that easily :)
Additional fix: Joshua added a copy/paste IpoCurve feature, but he broke
the functionality to be able to paste in an empty ipo channel. That now
works again
Patch by: Roland Hess (harkyman)
For example, a constraint can be sub-targeted at the 50% (or 31.2% or 85% etc.) point of its target bone, giving you enormous rigging flexibility and removing the need for complex contraptions to do such things as:
- A bone whose base slides only between to points on a rig (CopyLoc with a variable, animated subtarget point)
- Bones that attach to multiple points along another bone (CopyLocs, each with a different head/tail percentage)
- Bones that need to stretch to a point midway between specific spots on two other bones (old way: too crazy to mention; new way: stretch bone between points on end bones, then another stretch to the midpoint of the first stretch)
It is only used for the constraint types for which it is relevant: CopyLoc, TrackTo, StretchTo and MinMax, TrackTo, and Floor.
Notes:
- This is accessed by the Head/Tail number-slider.
- This value can be animated per constraint
- The old "Copy Bone Tail" option for the CopyLoc constraint has been automatically converted to 1.0 Head/Bone values for the affected constraints
- In the code, this value is in the bConstraint struct, so it is available for all constraints, even though only a few implement it.
Now the Copy Scale Constraint also has the Offset functionality that Copy Loc/Rot have.
== Copy Rotation Constraint ==
Also, fixed the tooltip for the CopyRot Offset button.
Note: when working with pose-bones, and using offset, setting both owner+target spaces to pose-space should cancel any unwanted rotations visible.
Copy Rotation constraint now has ability for the owner's rotation to be added on top of the copied rotation (i.e. an 'offset' like for the Copy Location constraint).
I've finally traced down the causes of several of the bugs which caused PyConstraints to work incorrectly (or not at all).
* Freeing is now done using BLI_freelistN inside the pycon_free function, instead of looping through the targets ourselves. This fixes all of those Memblock free: pointer not in list errors.
* BPY_pyconstraint_update now correctly creates/frees the constraint's targets as needed. Previously, it was creating/removing the wrong number of targets. Also, pyconstraints no longer get disabled when using armatures (not bones)
* The panel drawing was also not working right, as there were still some offset issues.
Once again, I've recoded the constraints system. This time, the goals were:
* To make it more future-proof by 'modernising' the coding style. The long functions filled with switch statements, have given way to function-pointers with smaller functions for specific purposes.
* To make it support constraints which use multiple targets more readily that it did. In the past, it was assumed that constraints could only have at most one target.
As a result, a lot of code has been shuffled around, and modified. Also, the subversion number has been bumped up.
Known issues:
* PyConstraints, which were the main motivation for supporting multiple-targets, are currently broken. There are some bimport() error that keeps causing problems. I've also temporarily removed the doDriver support, although it may return in another form soon.
* Constraints BPy-API is currently has a few features which currently don't work yet
* Outliner currently only displays the names of the constraints instead of the fancy subtarget/target/constraint-name display it used to do. What gets displayed here needs further investigation, as the old way was certainly not that great (and is not compatible with the new system too)
Object constraints with a driven influence ipo were not being evaluated
properly. The code for adding the depsgraph relation and updating without
time changes was simply missing.
Now there's an option for the owner to follow the path of the target cyclically. Previously, if the owner moved past the extents of the side of the bounding-box used for the calculations, the object was placed on the curve at the nearest extent.
This option is only really useful if the curve itself is cyclic, although you can still use it otherwise. To enable, just turn on the cyclic option.
* Grouped Up/Down buttons in constraint panel headers, and fixed their tooltips
* Removed unused variable from action editor code
* Minor formatting in constraint.c
I've added the ability for PyConstraints to define a function (doDriver) that is able to directly modify values of the owner/target, so that certain setups can be created reliably. Users should take note that this is against the basic concept of what a constraint does, and that under no circumstances may they set the values of any variables controlling the transforms. For more details, check out the information in the PyConstraint template script.
I've also updated PyConstraints to be aware of geometry targets. The script template has been updated with this information.
This commit features fixes/improvements for problems I didn't manage to fix in time for the commit yesterday.
* Now for Meshes, the normals of the vertices in the VertexGroup are averaged and used to find the 'rotation' that needs to be applied. Unfortunately, this does not work with Lattices as they do not have normals.
* Depsgraph should now play nicely with geometry targets. Before, the constrained object's location wasn't being updated after the target's geometry was modified.
It is now possible to use the geometry of Meshes and/or Lattices as the target of a constraint. All you need to do, is to create a new Vertex-Group and assign all the points that you wish to use as the target, then type that name into the VG: field for the relevant constraints.
One of the cases where this is beneficial is when you need to copy the location of a vertex. Now you don't need to make extra vertex-parents for that.
Additional Notes:
* The code takes the average of the locations of the nominated vertices, and puts that in world-space for constraint solving (and regular space-conversion stuff).
* Currently, rotation and scaling of points is not taken into account. The rotation/scaling used is from the object's matrix. Hopefully, this will only be a temporary problem (will be fixed soon)
