This is very bold right now - you simply can replace (or add) an action
to an override data-block. Actions themselves are not 'customizable'
through override at all currently (we may at least add
'add/remove/replace fcurves' feature in future), and nothing else in
animdata is overridable currently.
You can now override loc/rot/scale of objects and posebones.
Also added a basic operator to make an override of active linked object,
but this is very limited/wip/testing feature (you have to manually override
object and its armature, and relink to proper local overrides
yourself...). Final 'make proxy killer' will be much more automated of
course.
First real 'usable' commit, will be needed by the 'virtual data-block'
asset feature (i.e. to be able to link a mere image file as if it was a
linked datablock, and generate automatically an override of it to make
it editable).
We could do that in several different way, e.g. adding some tag during
DEG evaluation, etc. But this is not a critical process (it's main
purpose is user feedback), so current solution seems to work well enough
- and it's dead simple! ;)
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
See https://developer.blender.org/D2417 for details.
Note that since static overrides rely heavily on RNA, this commit is
essentially invisible from user PoV, more in next commits.
This function swaps the memory content of two data-blocks (of same type
obviously), while preserving most of the ID 'header' itself.
It is intended to be used to quickly and easily replace the data of an
existing ID by another one, presumably a temporary 'working' one,
without having to suffer from things like name changes,
registering/removing from Main database, etc.
Initially there was hope at least part of this work could be used for
dynamic overrides as well... but looks like not, so better be specific
and avoid any confusion.
PS: this commit break any file saved with static overrides, should not
be an issue though.
local and reference are awfully confusing names here, since destination
is a copy of reference that will become local override once applied, and
source is .blend-file-written version of local override...
Main reason here is to make comparison/override_diff/override_store/override_apply
customizable per RNA property if needed.
This should allow us especially to get advanced behavior on case-by-case
basis, when dealing with Pointer and Collection properties mostly.
Note that IDProps remain fuzzy area for now, a big part of the code
tries to take them into account, but it's most likely still missing some
bits, and definitively not tested at all yet!
Not sure why that piece of code stopped working, but now this operation
is pretty much never evaluated... Will have to either dig deeper in DEG
or ask Sergey about it, but not a crucial issue for now.
Animation is by definition another kind of (dynamic) override of properties,
which supersedes static override.
Note that this could be debated in some corner cases ('differential'
animation, like dloc/drot/dscale), but think we can ignore that for now,
and expect user to handle those manually when needed.
Means that from now on, we work based on blender2.8, no more master!
Conflicts:
source/blender/blenloader/intern/readfile.c
source/blender/blenloader/intern/writefile.c
source/blender/depsgraph/intern/builder/deg_builder_nodes.cc
source/blender/editors/interface/interface_ops.c
source/blender/makesdna/DNA_ID.h
source/blender/makesrna/intern/rna_ID.c
There are cases where we'll want to also override the reference pointer
(when we actually switch that datablock itself), but in some specific
situations, like when creating a new override, we need to keep org
pointer here!
No real reason we keep this only to copying, creating ID outside of
database is handy as well!
Also, add helpers to add/remove an ID from Main, and to set/clear its
'user refcounting' status. Those will be useful in future complex ID
manipulation cases (like static override...).
Not much happy, have to include BKE_curve in BLI_freetypefont to copy
nurbs... Not sure why fonts are in BLI tbh. We are already replicating
quite a bit of nurbs logic there. :(
Those are not actually copying the ID, only its internal subdata (and
other ID-specific handling). Generic processing common to all ID copying
is done by `BKE_id_copy_ex()`!
Makes things much simpler, and more consistent.
Also fix issue with new copying and bloody nodetrees, using same hack as
in original ntree copying code to detect 'root' ntrees that shall never
be put into bmain :(((((((
Note that those are an nightmare to handle correctly, current code is
like a plate of noodle, so... most likeley not fully working, think I'll
have to nuke localize code as well :(
(continuation of previous WIP commit, sorry about that one :/ ).
This commits changes quite a few things, distributing new copying flags
into sub-data copying code (mostly concerns ID refcounting or not).
It also removes ID refcounting handling from Modifiers' copy callback
(this was ugly from the start, proved to be problematic in current
master, and generally bad practice). This is now done by calling code.
Also, it brings back ID refcounting handling to main BKE_library's copy
code, which means in generic ID copying lower-level IDType-specific copy
code should not use it at all. Support at lower-level remains needed
though, unfortunately, to cope with partial copying tools etc.
It tried to assert that
addons/io_blend_utils/blender_bam-unpacked.whl/__init__.py was loaded when
the io_blend_utils module was imported. However, this happens only on
demand, and not directly when importing the add-on.
*Sigh* One more example of why we should keep ID management handling in
as few places as possible! It's impossible to keep more than a few
places in sync regarding which ID pointer is refcounted etc.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
The crash did not happen yet because we always had proper vmemh defined in
the parent scope.
Patch by Ivan Ivanov (aka obiwanus), thanks!
Differential Revision: https://developer.blender.org/D2715
Idea is the same, looks like it will be a tad simpler than with copy
though, since we should not need to change each ID type freeing func, as
ID usercount handling is done in main BKE_library code (would like to do
that for copy as well, but it's not that simple).
Namely, those allowing to link an object to an armature.
Thing is, we cannnot and absolutely do not want to use same trick as
armature proxies regarding deforming their related geometries.
So instead, we'll automatically make override of objects using
overridden armature as deformer, ultimately. This also allows for
several overrides of a same linked data.
Not sure how much good/bad this is, will have to ask artists once it's
ready for testing (cannot think of any non-ugly way to do that 'magic
trick' tbh).
Nothing functionnal for now, just made it possible for override to have
NULL reference ID.
Those overrides would be used as templates (created in original file of
the ID, they define some kind of default overriding settings). They
should also allow to forcefully lock some properties (forbid users of
that library ID to override some properties).
On second thought, modifying real data-block to store diff in it is...
just bad. Because it affects actual data, because it involves complicated
and heavy processes like remapping, and because it stores useless values
in .blend file (i.e. values that would give garbage results if e.g.
opening .blend file with older version of Blender, etc.).
So instead, decided to save an extra data-block in .blend file each time
we have some differential overrides.
Note that for now, we do full copy of datablock into its extra 'storage'
sibbling for .blend file. This is bad (think about double copy of heavy
mesh...) and will have to be fixed. Whole copy process will need serious
work anyway, for that kind of features we need to be able to copy
without increase usercount of IDs etc.
In fact, here, maybe we even need a smarter version of copy that would
only duplicate sub-data as needed by diff-overriden properties...
That way we don't have to add the same stupid few lines to *all*
datatypes writers! Obvious gain on efficiency and security from coding PoV.
Conflicts:
source/blender/blenloader/intern/writefile.c
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader
maybe).
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2510
Typical case: bones having constraints targetting other bones from same
armature. ID swap needs remapping here.
Really have to find something better than regular ID copy + swap + relinking
for override operations, this is horribly inneficient, complicated
and... most likely a nest of bugs and worms.
(pretty sure e.g. we still can generate same pointers during writefile
with current code :( ).
Seems CUDA failed to de-duplicate the array across multiple inlined
versions of the shadow_blocked(). Helped it a bit with that now.
Gives about 100MB memory improvement on a scenes after previous
commit and brings up memory "regression" to only 100MB comparing to
the master branch now.
This commit enables record-all behavior of transparent shadows
rays.
Render times difference goes as following:
GTX 1080 render time
BMW -0.5%
Fishy Cat -0.0%
Pabellon Barcelona -11.6%
Classroom +1.2%
Koro -58.6%
Kernel will now use some extra VRAM memory to store the intersection
array (200MB on my configuration). This we can optimize out with some
further commits.
The idea is to record all possible transparent intersections when
shooting transparent ray on GPU (similar to what we were doing on
CPU already).
This avoids need of doing whole ray-to-scene intersections queries
for each intersection and speeds up a lot cases like transparent
hair in the cost of extra memory.
This commit is a base ground for now and this feature is kept
disabled for until some further tweaks.
Now we break the traversal cycle and then perform volume attenuation
and check with zero throughput. Not sure it makes any measurable sense
at this moment, but in the future it might help de-duplicating some
extra logic here.
Removed unnecessary call to DM_update_tessface_data(). This call is
already performed by DM_ensure_tessface(dm). The call being performed
twice caused a failing BLI_assert().
Reviewed by: Kévin Dietrich
With the new names the arguments (yup, zup) are in the same order as
they appear in the function name. The old names used copy_src_dst(dst,
src), which I found very confusing. Furthermore, now it is clear from
where to where the copy is made.
This makes the function names a little bit longer, though. If that is
a real issue, we can just name them zup_from_yup(zup, yup).
Reviewed by: Kévin Dietrich
I.e. support override of loc/rot/scale of posechannels.
Also implied to add some minimal support of collections in 'diff
generating' RNA code.
Still much to be done of course.
So, now 'proportional' RNA properties (here, Object's scale) is stored
as 'multiply' override op.
Once again, this is mostly testing for now, there are a lot of potential
issues and traps in current code that'll need more background work to
address later if we keep working in this direction.
Main remaining TODO to complete the proof of concept now is sketching
out a bit of UI/UX control over override!
This commit mainly extend/refactor RNA prop copy and equals functions
into more advanced override utils (since equals is a subset of
aurooverride operations generation, and copy is a subset of override
operations application).
And some other work needed on the road...
Still called from pre-depsgraph eval step, does an RNA comparison and
generate overriding rules for changed props...
Note: we most certainly do not want to run this on all depsgraph eval.
Own current idea would be to just tag IDs e.g. in depsgraph callback,
and run actual auto-generation e.g. in a low-priority job, maybe? not
sure... :|
Also, fix stupid mistake in RNA applying of override (used when reading
file to apply static override), and add object's loc/rot/scale as
overridable properties.
Add a 'NOOP' override ruul to prevent any kind of override on a given
RNA path, and an ID flag 'AUTOOVERRIDE' to allow automatic definition of
override rules based on changed data.
Again, just defines, do not do anything yet.
Note that this is dummy empty placeholder for now!
Idea here is that depsgraph is best place to generate our override rules
based on data changes. That way all tools in Blender keep working as
usual, on local data, and overrides are generated when needed just
before IDs get actually evaluated.
Depsgraph has key advantage of only running over *changed* data-blocks
already.
Not sure this is actually valid idea, but for tests will do the work.
If we want to keep it, we'll have to find a way to prevent this running
too often though, especially not during most animation-triggered
evaluations.
Mostly code using override data to selectively update a copy of linked one
with local data.
As said, still totally hackish and experimental, but it works - you can
create overrides of linked Objects, and override their position, yeha! :P
Mostly nasty testing code, only overriding location of object for now.
And of course, we are still missing bits in read/write code to actually
do the override.
Also, add some minimal exposure of override in RNA, here again, most to
be done still.
Could very easily get into infinite loop when comparing Pointer
properties... And in any case, comparing ID pointer should be enough, no
need to dive into all ID properties!
