This is needed in cases when using blender camera with different
resolution than original footage. Behaves in the same way as
background picture framing.
- Re-arrange functions in headers and implementation file to make them
more grouped by entity they're operating with. Also order of functions
in implementation file should match order of functions in header for
easier navigation.
- Rename some functions to match conventions of naming public functions.
- Some code de-duplication, still some room for improvements tho.
- Split main 2D tracking functions into smaller steps to make it more clear.
Accidentally OpenMP was disabled in some of previous commits, re-enable it.
AFAIK, it is impossible to determine exactly which axes may have negative
scaling values from a 4x4 matrix (which is the underlying cause of this bug).
However, we can figure out if there is some negative scaling going on in that
matrix (i.e. one of the axes has negative scale). So, the fix here is to
negatively scale everything if we detect this happening.
WARNING: do not rely on being able to accurately detecting positive/negative
values for more than a single axis per bone controller. Weird results may occur.
You have been warned.
Now it's indicates at which scene frame number movie clip starts playing back.
This this setting is still belongs to clip datavlock and used by all users of
clip such as movie compositor nodes, constraints and so.
After long discussion and thoughts about this it was decided that this would
match image's current behavior (which initially seen a bit crappy), but that's
actually allows:
- Keep semantics of start frame in image and clip datablocks in sync
- Allows to support features like support of loading image sequences
with crappy numbers in suffix which doesn't fit long int.
- Allows to eliminate extra boolean checkbox to control such kind of offset.
Hopefully from pipeline POV it wouldn't hurt because idea of having this things
implemented in original way was working only if sequence before processing
started naming form 001.
* ID-blocks referenced by Constraints but not being used as the target objects
(such as Actions in the Action Constraint, or Text Blocks in PyConstraints) now
get usercounts for being referenced in this way. This should fix ancient bugs
such as [#19205] and [#8593]. More tests still needed to verify that this
does now play nicely with proxies.
* Changing actions used by NLA strips should now update the usercounts
accordingly
--debug
--debug-ffmpeg
--debug-python
--debug-events
--debug-wm
This makes debug output easier to read - event debug prints would flood output too much before.
For convenience:
--debug-all turns all debug flags on (works as --debug did before).
also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
Issue was caused by object moved really far away (not just actually issue,
it's just about long mouse gesture and X-axis orientation which projects
position to quite large X-axis value) and for this location start offset
from curve length was calculating iteratively which takes plenty of time for
short curves.
Replace iterative search of offset with formula which seems to be working
in the same way and should be a bit more accurate.
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
Now constraints' space conversion code also uses generic armature_mat_(pose_to_bone/bone_to_pose). Previous own function (constraint_pchan_diff_mat) was somewhat inconsistent too with Hinge/NoScale/LocalLocation options...
As with previous similar changes, this might break some old rigs, in very specific cases (when constraint-evaluating an hinge/noscale/local_location bone in local space).
In the same part of code, removed unnecessary matrices copying, mult_m4_m4m4 can take the same matrix as input and output, nowadays...
Also found a bug-generator weakness in those armature_mat_ functions (if both input and output mat where the same, result was wrong, now systematically copying input mat, as done in LIB's matrix funcs).
Finally, factorized offset bone matrix generation into its own small function too, as it is used in two different places in armature.c (pchan_to_pose_mat itself, and restpose's where_is_armature_bone).
Note: I think all parts of blender's code related to that topic have now been tackled, but yet have to check BGE, it’s probably using that stuff too, one way or the other...
It was incorrect behavior of contarget_get_mesh_mat in cases when
object's Y axis is co-linear to average vertex group normal.
Use object's X axis for plane definition in such cases.
