| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Basically just made constraints free function aware of possible do_id_users
argument, same as we've got for objects, object data and so on.
|
|
|
|
Context menu to toggle render, visibility & delete
D996 by @lichtwerk
|
|
|
|
* 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)
|
|
bones from shrinking below 1.0 scale
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.
|
|
|
|
|
|
projection case.
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.
|
|
space when only using parent's rotation and parent is rotated.
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.
|
|
Uses a arctan instead of sine function now, which has the advantage of
not overestimating the bulging.
|
|
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
|
|
|
|
|
|
|
|
Importantly, reversed mul_serie_m3 argument order (so it matches the m4 function)
|
|
NULL's)
|
|
|
|
from Parent instead!)
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).
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
single DNA one.
|
|
|
|
|
|
|
|
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,
|
|
|
|
|
|
|
|
to true/false in code using them).
|
|
Since recent DAG commit for set scenes in DAG_on_visible_update()
it seems there're no longer issues with missing curve_cache after
file load.
|
|
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.
|
|
checks weren't needed.
also remove redundant dot_v3v3 in shrinkwrap constraint.
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
|
|
correct some harmless but incorrect sizeof() use
|
|
indent.
also indent case's within the switch (we already did both of these almost everywhere)
|
|
if statements and redundant initialization vars.
|
|
offsets too (like for location)
This is useful in some cases when Copy Rotation constraints would otherwise be
used for this purpose but cannot be used for various reasons. Basically, this
works in practically the same way that the Copy Rotation offsets work, including
the same weirdness that you'll get when trying to manually rotate these in the
3D viewport using "global" space manipulations ("local/normal" spaces though
still seem to work really nicely).
WARNING: this may potentially break old files with transform constraint setups
involving rotation outputs. Please check whether this causes any problems on old
files, and report back if there are any issues.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
