| Age | Commit message (Collapse) | Author |
|---|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
Old Name New Name
========= =========
init_def_material BKE_materials_init
BKE_material_gpencil_default_free BKE_materials_exit
test_object_materials BKE_object_materials_test
test_all_objects_materials BKE_objects_materials_test_all
give_matarar BKE_object_material_array
give_totcolp BKE_object_material_num
give_current_material_p BKE_object_material_get_p
give_current_material BKE_object_material_get
assign_material BKE_object_material_assign
assign_matarar BKE_object_material_array_assign
give_matarar_id BKE_id_material_array
give_totcolp_id BKE_id_material_num
assign_material_id BKE_id_material_assign
clear_matcopybuf BKE_material_copybuf_clear
free_matcopybuf BKE_material_copybuf_free
copy_matcopybuf BKE_material_copybuf_copy
paste_matcopybuf BKE_material_copybuf_paste
BKE_material_init_gpencil_settings BKE_gpencil_material_attr_init
BKE_material_add_gpencil BKE_gpencil_material_add
BKE_material_gpencil_get BKE_gpencil_material
BKE_material_gpencil_default_get BKE_gpencil_material_default
BKE_material_gpencil_settings_get BKE_gpencil_material_settings
|
|
|
|
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
|
|
The combined export was using the old flag format.
|
|
|
|
A collection of smaller changes that are required in the /blender/source files. A lot of them are also due to variable renaming.
Reviewed By: sergey
Maniphest Tasks: T59995
Differential Revision: https://developer.blender.org/D3855
|
|
|
|
|
|
This is a partial rollback of f18ad385dffe70f5e57df00ff9bbb7b42fa05be0. It
turned out to be more tricky to determine animatedness of an object.
This fixes T71986.
|
|
There are no more 'layers' in Blender. I chose 'Visible Objects' rather
than 'Visible Collections' to be consistent with the other
'{Renderable,Selected} Objects Only' options.
No functional changes.
|
|
`AbcTransformWriter::hasAnimation` recently became smarter than just
returning `true`, but wasn't quite smart enough yet. Constraints are now
considered a source of 'animation'.
|
|
|
|
Instead of always writing the transform on every frame, it's now checked
whether the object is animated at all. This could be made stricter to
reduce false positives, for example by checking FCurves and drivers to
see whether translation/rotation/scale is animated. However, this
approach is already better than the `return true` we had before.
This commit adds the BKE_animdata_id_is_animated(id) function, which
returns true if the ID datablock has non-empty animation data. This is
determined by checking the the active action's fcurves, the drivers, and
NLA tracks.
|
|
The Alembic file metadata object was created in one place, a bit of
metadata was added, then it was passed along with other properties which
were then injected as metadata in another function. This is now cleaned up.
No functional changes.
|
|
This commit implements the change in behaviour described in T71246.
In short:
For export, per mesh:
- Custom loop normals are defined → loop normals are exported.
- One or more polys are marked flat → loop normals are exported.
- Otherwise, no normals are exported.
For import, when the Alembic mesh contains:
- loop normals (kFacevaryingScope) → use as custom loop normals, and
enble Auto Smooth to have Blender actually use them.
- vertex normals (kVertexScope or kVaryingScope) → convert to loop
normals, and handle as above.
- no normals → mark mesh as smooth.
- unsupported normal types (kConstantScope, kUniformScope,
kUnknownScope) → handle as 'no normals'.
This also fixes T71130: Alembic split normal export issue
Previously the mesh flag `ME_AUTOSMOOTH` was used in conjunction with
the poly flag `ME_SMOOTH` to determine whether loop normals or vertex
normals were exported. This behaviour was hard to predict for artists,
and hard to describe in the manual. Instead, Blender now only exports
loop normals, computing them if necessary. This way, the mesh in Alembic
should always have the same loop normals as in Blender.
Maniphest Tasks: T71130
Differential Revision: https://developer.blender.org/D6197
|
|
When importing subdivision surfaces a 'Topology Changed' error was shown
even though the topology didn't change at all. The code was comparing to
`totpoly` where `totloop` should have been used.
|
|
The auto-smoothing flag can now be used by artists when the Alembic file
does not contain custom loop normals.
- Auto-smoothing disabled: mesh is flat-shaded.
- Auto-smoothing enabled: works as usual; set angle to 180° to ensure
a 100% smoothed mesh.
|
|
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
|
|
Modifier stack evaluation would copy mesh settings other than mesh topology
automatically, outside of the individual modifier evaluation. This leads to hard
to understand code, and makes it unclear which settings are available in following
modifiers, and which only after the entire stack is evaluated.
Now every modifier is responsible to ensure the mesh it outputs preserves materials,
texture space and other settings, or alters them as needed.
Fixes T64739: incorrect texture space for various modifiers
Differential Revision: https://developer.blender.org/D5808
|
|
space issues"
This reverts commit e7a514369fe700dcc5a1fe433c8f709ed9595ded, it introduces
a bug in selection in edit mode.
Fixes T70103: can't select extruded Vertex
Ref T64739
|
|
Creases are stored by the vertex indices of the edges. Sometimes they
were stored with (v1, v2) when the edge itself was stored with (v2, v1).
We now search for both orientations.
Sorting the vertex indices before searching avoids the second search
altogether when loading the example file of T70021.
|
|
Error was introduced in 34143e45104b.
|
|
The parent hairs were written to Alembic even when the 'Parent Particles'
checkbox (`use_parent_particles`) was disabled. In this case the parent
hairs were not correct in Blender's memory, and thus also not correct in
the exported Alembic file. The Alembic exporter now respects this setting
and doesn't write the parent hairs when 'Parent Particles' is off.
|
|
Importing an Alembic file with a relative path is now also possible.
|
|
Modifier stack evaluation would copy mesh settings other than mesh topology
automatically, outside of the individual modifier evaluation. This leads to hard
to understand code, and makes it unclear which settings are available in following
modifiers, and which only after the entire stack is evaluated.
Now every modifier is responsible to ensure the mesh it outputs preserves materials,
texture space and other settings, or alters them as needed.
Fixes T64739: incorrect texture space for various modifiers
Differential Revision: https://developer.blender.org/D5808
|
|
crashes
The static mesh issue described in T65816 has been resolved by @Sergey
in T60094.
This commit fixes the last bit of the puzzle, which was two-fold:
- A missing depsgraph update when setting `orig_object.data = new_mesh`
from Python. Thanks @Sergey for providing the fix :)
- Properly locking the interface while exporting. This prevents crashes
as described in T60094. The previous approach of calling
`BKE_spacedata_draw_locks()` was not enough.
|
|
The `do_update` variable wasn't set after changing the `progress`
variable, causing the GUI only to update on redraw (f.e. when the user
was waving the mouse around).
|
|
variables
Using pointers instead of references when passing progress variables
makes the C++ code more in line with the C code (as it doesn't transform
pointer parameters to reference parameters). Also makes it easier to
spot when a common Blender pattern is implemented incorrectly (fix will
be in the next commit).
|
|
Currently unused, but will allow to keep of an owner of the depsgraph.
Could also simplify other APIs in the future by avoiding to pass bmain
explicitly to relation update functions and things like that.
|
|
This partially reverts commit 0b2d1badecc48b5cbff5ec088b29c6e9acc5e1d0
Post increment can deep-copy for C++ iterators, while in my own checks
GCC was able to optimize this to get the same output,
better follow C++ best practice and use pre-increment for iterators.
|
|
When the result isn't used, prefer post increment/decrement
(already used nearly everywhere in Blender).
|
|
|
|
|
|
|
|
This fixes the glitching hairs described in T56408, T63534, and possibly
also T63534.
The fix consists of returning the original mesh (i.e. as visible in edit
mode) when constructing the ORCO mesh. This allows a static set of
coordinates to be used when computing the child hair positions.
The original mesh is only returned when it has the same topology (at
least same number of vertices, loops, and polys. It's up the author of
the Alembic file to ensure stable geometry when it's desired to be
compatible with Blender's hair system.
Reviewers: mont29, brecht
Differential Revision: https://developer.blender.org/D5492
|
|
|
|
Some statements were split across multiple lines because of their
trailing comments.
In most cases it's clearer to put the comments above.
|
|
The mesh can be freed by BKE_mesh_nomain_to_mesh(), so we need to get
the `ME_AUTOSMOOTH` flag before that call, and not after.
|
|
Meshroom writes two hierarchies to Alembic, one rooted at
`/mvgRoot/mvgCameras` and the other at `/mvgRoot/mvgCamerasUndefined`.
These paths have no schema definition, and thus are ignored by Blender.
The cameras themselves have those schemaless paths as parent, and have
their transforms marked as "inherited", e.g. relative to their parent.
As these cameras have no valid parent, there is no Blender object to use
to convert their local matrices to world matrices, and Blender just
decided to reset them to the unit matrix.
Now "inherited" transforms without a parent in Blender are interpreted
as world transforms. Reparenting those objects to a Blender object will
re-interpret the transforms as local to the parent again.
|
|
T68035 by @luzpaz
|
|
|
|
|
|
When the mesh is using custom normals, those should always be exported,
regardless of the `ME_SMOOTH` flag on the invidivual polys.
Also replaced the loop normal writing with the same logic as we use for
reading (less pointer arithmetic, more normal counting).
|
|
Loop normals are called 'Face-varying normals' in Alembic. Before this
commit, the existence of such normals was used to enable smooth shading.
This is incorrect, as the normals could encode flat faces just as well.
This commit adds the loading of these normals as custom loop normals. It
then also enables Auto-Smoothing on the mesh (which is a bit of a
misnomer and indicates to Blender that the custom normals should be
used).
Fixes the glitching described in T65959.
Differential Revision: https://developer.blender.org/D5191
|
|
The name now indicates what happens when the variable is set to true.
No functional changes.
|
|
The only thing that is stored in this pointer is a `Mesh*`, and casting
it from/to `void*` is unnecessary and confusing. Maybe the entire
CDStreamConfig class could/should be removed at some point.
No functional changes.
|
|
By having a switch statement that lists all the values of the enum, it is
clear which cases we're not handling, and it also allows for warnings in
the future when the enum expands.
No functional changes.
|
|
No functional changes.
|
|
The `poly_start` parameter was always 0, so adding it to a poly index
from Alembic is a no-op.
No functional changes.
|
