| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This way we can easily control format and keep it consistent.
And also possibly do other trickery, like coloring addresses!
|
|
The issue was only visible with copy-on-write enabled, and related to the
fact, that dependency graph builder binds original FCurves.
For now use smallest patch possible to make things to work and to make
draguu happy.
Need to think of a smarter way to deal with drivers, bones and view layers.
|
|
|
|
|
|
|
|
Now it's possible to have debug messages for following things:
- Graph construction
- Graph evaluation
- Graph tagging
|
|
|
|
renaming/fixing code
|
|
|
|
|
|
|
|
Conventions were already followed nearly everywhere.
|
|
|
|
Currently this is a no-visible-changes change, but the idea is to use this
dedicated flag to tell which exact components of ID changed, make it more
granular than just OBJECT and OBJECT_DATA. Allow setting this field based
on what components new dependency graph flushed on evaluation.
|
|
New dependency graph is supposed to have relation from animation node to
the node which corresponds to a property which is modified by that curve.
This means it is up to dependency graph to flush recalc flags, and no
manual control is needed in the animation code.
|
|
# Conflicts:
# source/blender/editors/mesh/editmesh_select.c
|
|
T52009)
* For the T48988 fix (i.e. separate Ease In/Out properties for Bendy Bones
in Edit vs Pose modes), old animation data needed to be patched to use
the new property names. This is needed to partially fix some of the
issues in T53356 (though the Rigify code itself still needs to be patched).
* For the T52009 fix, old files needed to have the frame_start and frame_end
properties on the FModifier (base-class) updated to match that of the
FMod_Stepped type-specific class. This wasn't done in the earlier commit
since it wasn't worth going through all animation data just for the sake
of updating these relatively-rare settings, but since we're doing it anyway
now, it makes sense to include this here.
|
|
it easier to apply fixes to all F-Curves in a file
|
|
|
|
|
|
Previously it was returning short, which was really easy to (a) compare against
non-ID type value (b) forget to handle some specific value in switch statement.
Both issues happened in the nearest past, so it's time to tighten some nuts
here.
Most of the change related on silencing strict compiler warning now, but there
is also one tricky aspect: ID_NLA is not in the IDType enum. So there is still
cast to short to handle that switch. If someone has better ideas how to deal
with this please go ahead :)
|
|
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
|
|
|
|
The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
|
|
|
|
Probe is a real general term, the new name is used often in docs online.
|
|
That's the kind of commit that are nice to do - getting rid of
half-working custom pieces of code, now that we have generic tools
to do same thing. ;)
|
|
We went for a new datablock because blending probe functionality with empties was going to be messy.
|
|
|
|
|
|
Things like `BLI_uniquename` had nothing, but really nothing to do in
BLI_path_util files!
Also, got rid of length limitation in `BLI_uniquename_cb`, we can use
alloca here to avoid overhead of malloc while keeping free size (within
reasonable limits of course).
|
|
This aims at always ensuring that ID.newid (and relevant LIB_TAG_NEW)
stay in clean (i.e. cleared) state by default.
To achieve this, instead of clearing after all id copy call (would be
horribly noisy, and bad for performances), we try to completely remove
the setting of id->newid by default when copying a new ID.
This implies that areas actually needing that info (mainly, object editing
area (make single user...) and make local area) have to ensure they set
it themselves as needed.
This is far from simple change, many complex code paths to consider, so
will need some serious testing. :/
|
|
This is required since new dependency graph evaluates drivers in threads
so it was possible to have some partially written ID tag there.
|
|
|
|
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
|
|
Un-indent blocks, rename vars.
|
|
Drivers can use this to refer to the data which the driver is applied to,
useful for objects, bones, to avoid having to create a variable pointing to its self.
|
|
used locally.
Will be used by link/append code.
|
|
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...
|
|
This func now actually takes an ID type as argument, added new 'id_can_have_animdata()'
to check whether a datablock may be animated or not.
|
|
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.
|
|
|
|
FCurve evaluation depended on FCurve.curval, which isn't threadsafe.
Now only use this value for debug display,
and pass the value instead of storing in the FCurve for all but debug-display.
|
|
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
|
|
We have callbacks for that, they also do some checks and help ensure things are done
correctly. Only place where this is assumed not true is blenloader (since here we
may affect refcount of library IDs as well...).
|
|
- 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`.
|
