Use new interp_m4_m4m4 instead of blend_m4_m4m4.
Note that maybe we could replace other usages of blend_m... by interp_m...,
but this should be investigated on a case-by-case basis.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
* Ensure that when new constraints are created, the new settings have sensible
default values.
TODO: we need to version-patch old files
* Fix problem with variable shadowing (which wasn't causing problems AFAIK)
From the looks of things, this was a typo. The result was that if you had a bone
with the minimum volume restriction in place, the bone would not get any thinner
when it was stretched out.
Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added
kind of not-so-nice hack instead.
Note root of the issue comes from the special case we are doing here re 'Local'
space of parent-less objects. In that case, local space should be the same as
world one, but instead we apply the object rotation to it... This is inconsistent
with all other cases and could very well lead to other issues as T42447, but afraid
fixing that properly would be rather hairy - not to mention it would likely break
all existing riggings etc. :(
Should be safe for a 2.73a, shall we need it.
Constraint space conversion ignores object scale, which is OK in most cases. But here,
we are converting a normal from world to local space, and when later converting it
into target space to actually do the BVH raycast, we use TransformSpace which
does applies objects' scaling to normals, as expected.
Best solution here is to also take object's scale into account when converting
from local to world space.
Just do not use crazyspace correction with childof constraints in this case.
Note this is only a very partial fix (partial use of parent loc on some axes
is still broken in transform), a real fix would probably require a full rewrite
of constraints handling in transform code (a mere static correction matrix
just cannot work in all possible cases, we'd need a full dynamic correction system here).
Anyway, transform code as a whole is horrible. :/
Make sure the 1.0 value is not affected by smoothing, and min/max limits
never go above or below 1.0 respectively. This was a request by
animators since not modifying the mesh in its rest pose is regarded as
crucial.
Currently the volume variation feature in stretch constraints is
unlimited. This has to be compensated by riggers by adding scale limit
constraints, but these are unaware of the stretch orientation and can
lead to flipping. Also the stretch calculation itself is not working
properly and can lead to collapsing volume.
The patch fixes this with several modifications:
- Interpret the volume variation factor as exponent, which works better
with large values for artistic purposes.
- Add integrated limits to the volume "bulge" factor, so secondary
constraints for compensation become unnecessary
- Add a smoothness factor to make limits less visible.
Eventually a generic volume preservation constraint would be nicer,
because multiple constraints currently implement volume variation of
their own. This feature could actually work very nicely independent from
other constraint features.
Differential Revision: https://developer.blender.org/D826
Revert small part of own rB8714ae09f894, which changed scale setting from absolute to relative
(was good in absolute, but bad because it breaks existing rigs).
There is no good solution here, since RNA props can only have one type/unit.
Tried to find the less worse one - have different RNA props for same DNA value
(a bit like the angle/length for camera lens).
Also fixed two other issues with Transform conctraint:
* Angle were still in degrees (yes, another backward-compatibility breacking).
* Scale was absolute, unlike loc/rot.
Also cleaned up a bit the code, replaced some magic numbers by proper enums, ...
Issue was caused by inverting a degenerate matrix when
evaluating drivers.
Solved by using tweaked inverse code (same as used in Cycles).
Should have no affect on cases when matrix is not degenerate.
Issue was caused by undefined object update order and in some
cases NULL pointer will be de-referenced.
Added on-demand curve path calculation, just the same creepy call
of BKE_displist_make_curveTypes(). This violates DAG and might
end up in a difficult to troubleshoot race condition if there'll
be some issues with how dependencies are calculated in DAG, but
this is the easiest and safest way to solve the bug at this stage,
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
- ability to change the space the axis is projected in (so you can choose worldspace or -space, was always local-space before).
- support projecting on a negative axis, without this some very simple clamping is not possible if the direction happened not to be positive.
- add distance limit (same as modifier), without this single meshes surrounding an object would make the constraint impossible to use in some cases (it would snap to the wrong side).
note: this removes the ability to project on multiple axes at once but this option only added up directions and didnt project on multiple axes as you might expect.
