| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3438
|
|
No idea why that was working this morning, now we do not get CoW tag
anymore (which kind of makes sense since it's set *after* copying
happens...), so just resorting to using the NO_MAIN flag instead.
|
|
broken-used-as-feature one from 2.7.
Locked bones of proxies should not be editable, at all. But lack of
update from linked rest pose in 2.7 allows to pose and animate locked
bones (not to pose them without animation though, or you'd lose your
pose on next file save & reload).
this is used by artists to always lock all their bones in a rig, so that
proxies fully update when lib rig is modified...
For now, restore that broken behavior in 2.8 by not updating proxies
against lib armature in CoW context (makes sense anyway, we are
currently doing a lot of useless thing when copying data for depsgraph
evaluation!).
|
|
|
|
The mesh parameter of armature_deform_verts() is now const, to indicate
that it's safe to pass ob->data to it directly.
|
|
While the feature is interesting, it's not much from what we can tell.
Retargeting is an important feature but needs
to fit in better with typical animation work-flows.
See: T52809
|
|
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
|
|
- Undo that changes modes currently asserts,
since undo is now screen data.
Most likely we will change how object mode and workspaces work
since it's not practical/maintainable at the moment.
- Removed view_layer from particle settings
(wasn't needed and complicated undo).
|
|
|
|
This was dangerous to do such calculations, and now it is solvable by making
dependency graph more granular in this case. Removing the workaround also saves
us a hassle of passing lots of extra arguments down the evaluation routines.
In theory, we can also remove EvaluationCOntext from constraints evaluation as
well now. But probably better to wait with such removal for now.
This commit effectively reverts 1130c53. Will do a proper fix in dependency
graph itself.
|
|
|
|
This fix enables the usage of bbones easing parameters for edit and pose mode seperately. This allows animators to take advantage of the functionality and may eliminate confusion as the parameters now behave similar to other bbone parameters.
Note that splitting the parameters between the modes effectively creates a new parameter set. Blend files of previous versions do not contain this information and will have the values set to 0 on load. As it broke backwards compatibility for pose mode values anyway, I also took the liberty to rename the easing parameters in some places for consistency (which breaks edit mode values).
Reviewers: aligorith
Subscribers: aligorith
Tags: #animation
Differential Revision: https://developer.blender.org/D2796
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
|
|
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
|
|
|
|
|
|
Not sure how this happens, but in some cases we can evaluate
deformations of an armature which pose is not valid, at least put a
warning here to help identifying the issue quickly.
|
|
|
|
# Conflicts:
# source/blender/blenloader/intern/writefile.c
|
|
This avoids calling linear lookup 100s of time when dealing with
real-life character.
Still some tweaks possible.
|
|
|
|
stepsize = 0
A big thanks to Steffen Mortensen (stifan) for finding the root cause of this bug!
|
|
This reverts commit 9b5a32cbfb8a8565202bdccd232c53f98b62eeec.
Apparently it is possible to have other thread mocking around with the hash.
Needs deeper investigation, for the time being reverting to prevent crashes.
|
|
Culprit here was once more proxies. Think what was happening here was:
1) Both proxy and proxified armatures' PoseChannels were cleared
(needed after remapping due to Bone pointers being stored in pchans).
2) Proxy PoseChannels got rebuilt in `BKE_pose_rebuild_ex()`, which ends,
in proxy cases, by actually replacing rebuilt pchans by those from
the proxified object... which has not yet been rebuilt.
Fixed the issue by merely adding bone pointer to data copied from
original pchan into new 'from proxy' one... Sounds much, much safer and
sanier anyway, that way we can be sure bone pointer is actually pointing
to a bone of the object's armature (this is supposed to be the same
Armature datablock between proxy and proxified objects, but that may not
be always true especially during makelocal process).
|
|
This makes bone lookup much faster (by avoiding liner string lookup)
and speeds up depsgraph construction time on file open.
|
|
We don't need to sort bone channels, it's all taken care about
by the depsgraph itself.
Gives up to 30% initial rig construction time speedup.
|
|
BKE_id_copy_ensure_local function.
|
|
Those bone pointers in object's pose bite again - turns out they can be accessed
before pose actually gets rebuilt in some cases (e.g. from undo writefile), so
we need to clear the pointers immediately.
|
|
Turns out most BKE_foo_make_local datablock-specific functions are actually doing
exactly the same thing, only two currently need special additional operations
(object and brush ones). So added a BKE_id_make_local_generic instead
of copying same code over and over.
Also, changed a bit how make_local works in case we are localizing a whole library.
We need to do the 'remap' step (from old linked ID to new local one) in the second loop,
otherwise we miss some dependencies. This fixes main part of T48907.
|
|
used locally.
Will be used by link/append code.
|
|
Idea looked good, but we have too much custom situations here (some half-fake-sub-ID
being copied with their 'owner', animdata, etc.), let's let datablock copy functions
handle that themselves.
Also allows to safely call BKE_id_expand_local from all copy functions now (only when
copying linked data).
|
|
This one is already called by matching copy functions, no need to call it twice!
|
|
functions of obdata
(armature, mesh, curve, mball, lattice, lamp, camera, and speaker).
This greatly simplifies said code, once again no change expected from user PoV.
|
|
Now using modern features from libquery/libremap areas.
Provides same kind of fixes/improvements as for BKE_object_make_local() (see rBd1a4ae3f395a6).
|
|
Also allows us to get rid of a few _copy_ex() versions...
|
|
Idea is to replace hard-to-track (id->lib != NULL) 'is linked datablock' check everywhere in Blender
by a macro doing the same thing. This will allow to easily spot those checks in future, and more importantly,
to easily change it (see work done in asset-engine branch).
Note: did not touch to readfile.c, since there most of the time 'id->lib' check actually concerns the pointer,
and not a check whether ID is linked or not. Will have a closer look at it later.
Reviewers: campbellbarton, brecht, sergey
Differential Revision: https://developer.blender.org/D2082
|
|
So the error seems to be in cubic_tangent_factor_circle_v3(),
which was introduced with D2001.
I've tweaked the most obvious culprit here - the epsilon factor.
It used to be 10^-7, but I've reduced it down to 10^-5 now,
and it's looking a lot more stable now :)
---------
BTW, about the derivation of the magic 0.390464 factor I briefly subbed back
as a workaround for this bug, see:
http://www.whizkidtech.redprince.net/bezier/circle/
|
|
custom handle bones
It's probably some numeric precision issue, but until we figure out exactly what's
going wrong here, let's just revert back to the hardcoded value that was used here
successfully for years without issues.
|
|
handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
|
|
This changes the bezier handles b-bones to fit to a circle more closely.
|
|
This commit/patch/branch brings a bunch of powerful new options for B-Bones and
for working with B-Bones, making it easier for animators to create their own
rigs, using fewer bones (which also means hopefully lighter + faster rigs ;)
This functionality was first demoed by Daniel at BConf15
Some highlights from this patch include:
* You can now directly control the shape of B-Bones using a series of properties
instead of being restricted to trying to indirectly control them through the
neighbouring bones. See the "Bendy Bones" panel...
* B-Bones can be shaped in EditMode to define a "curved rest pose" for the bone.
This is useful for things like eyebrows and mouths/eyelids
* You can now make B-Bones use custom bones as their reference bone handles,
instead of only using the parent/child bones. To do so, enable the
"Use Custom Reference Handles" toggle. If none are specified, then the BBone will
only use the Bendy Bone properties.
* Constraints Head/Tail option can now slide along the B-Bone shape, instead of
just linearly interpolating between the endpoints of the bone.
For more details, see:
* http://aligorith.blogspot.co.nz/2016/05/bendy-bones-dev-update.html
* http://aligorith.blogspot.co.nz/2016/05/an-in-depth-look-at-how-b-bones-work.html
-- Credits --
Original Idea: Daniel M Lara (pepeland)
Original Patch/Research: Jose Molina
Additional Development + Polish: Joshua Leung (aligorith)
Testing/Feedback: Daniel M Lara (pepeland), Juan Pablo Bouza (jpbouza)
|
|
matrices.
On big and complex rigs like blendrig or koro, it can give up to ~10% more FPS in best cases.
Hard to tackle all cases in tests though, so please report any unexpected slowdown
in armature animation playback!
|
|
|
