Age | Commit message (Collapse) | Author |
|
|
|
|
|
Skip light cache baking until T73921 is fixed. This should be fixed properly
but being able to run the tests at all is important now.
|
|
|
|
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
|
|
|
|
Introduce new IDTypeInfo structure.
Each ID type will have its own, with some minimal basic common info,
and ID management callbacks.
This patch only does it for Object type, for demo/testing purpose.
Moving all existing IDs is a goal of next "cleanup Friday".
Note that BKE_idcode features should then be merged back into BKE_idtype -
but this will have to be done later, once all ID types have been properly
converted to the new system.
Another later TODO might be to try and add callbacks for file read/write,
and lib_query ID usages looper.
This is part of T73719.
Thanks to @brecht for initial idea, and reviewing the patch.
Differential Revision: https://developer.blender.org/D6966
|
|
|
|
|
|
|
|
If there were merged vertices, sometimes the output faces
had wrong vertex indices. Added a test for this, and fixed.
|
|
As explained in T65568 by @LucaRood, the self collision system should exclude triangles that are connected by sewing springs.
Differential Revision: https://developer.blender.org/D6911
|
|
|
|
The array giving original vertex indices should not contain
entries for newly created vertices. Added a test to check this.
|
|
This test is authored by Himanshi Kalra (calra).
It requires a new modifers.blend in the svn tests.
|
|
The 'random' unit tests and some examples from the new boolean code
triggered asserts and crashes. This fixes those.
There is a new flag in the input that optionally disables a pass
over input to snap segment edges to other segments.
|
|
This fixes {T70269}.
Before this commit there was complicated code to try and compute the
correct parent inverse matrix for the 'Child Of' and 'Object Solver'
constraints outside the constraint evaluation. This was done mostly
correctly, but did have some issues. The Set Inverse operator now defers
this computation to be performed during constraint evaluation by just
setting a flag. If the constraint is disabled, and thus tagging it for
update in the depsgraph is not enough to trigger immediate evaluation,
evaluation is forced by temporarily enabling it.
This fix changes the way how the inverse matrix works when some of the
channels of the constraint are disabled. Before this commit, the channel
flags were used to filter both the parent and the inverse matrix. This
meant that it was impossible to make an inverse matrix that would
actually fully neutralize the effect of the constraint. Now only the
parent matrix is filtered, while inverse is applied fully. As a result,
pressing the 'Set Inverse' matrix produces the same transformation as
disabling the constraint. This is also reflected in the changed values
in the 'Child Of' unit test.
This change is not backward compatible, but it should be OK because the
old way was effectively unusable, so it is unlikely anybody relied on
it.
The change in matrix for the Object Solver constraint is due to a
different method of computing it, which caused a slightly different
floating point error that was slightly bigger than allowed by the test,
so I updated the matrix values there as well.
This patch was original written by @angavrilov and subsequently updated
by me.
Differential Revision: https://developer.blender.org/D6091
|
|
|
|
The 'Clear Inverse' operator didn't properly update the constraint, so
it didn't do anything until the entire depsgraph was updated. It's now
properly tagged for update.
|
|
In the collections unit test file developers can now disable layer
collections and declutter the 3D Viewport while working in
`constraints.blend`, without influencing the actual unit tests themselves.
|
|
No functional changes.
|
|
|
|
Currently this only tests the Child Of constraint. My aim is to cover
constraints with tests before they are refactored/altered.
No functional changes.
|
|
|
|
This also re-enables the fluid motion blur test.
|
|
rBf35f7bd97a4151 was the proper fix it seems.
|
|
|
|
|
|
There are two issues solved in this commit:
- Our Windows buildbot has slightly different floating point errors than
the Linux one, which meant a larger delta was required for float
comparisons.
- The test performs an export to a temporary Alembic file and
subsequently imports it. Deleting the temporary file was impossible on
Windows because it was still in use. This is now resolved by first
loading the default blend file before deleting the Alembic file.
|
|
This will currently fail to compile. Fixes upcoming.
|
|
|
|
The Alembic importer now works with local coordinates. Previously, the
importer converted transformations from Alembic to world coordinates
before processing them further; this processing often included
re-converting to local coordinates. This change made it possible to
remove some code that assumed that a child transform was only read after
its parent transform.
Blender's Alembic code follows the Maya convention, where in the zero
orientation the camera looks forward instead of down. This extra
rotation is now handled more consistently, and now also properly handles
children of cameras. This fixes T73269.
Unit tests were added to at least ensure that the importer and exporter
are compatible with each other, and that static and animated camera
transforms are handled in the same way.
|
|
This rename is to prepare for a future addition to the unit test file.
Currently it's named "import" and I will add an export test as well. The
rename is a separate commit to easily see the difference between the
rename and the addition of another test.
No functional changes.
|
|
|
|
Do not do much for now, but would have been enough to catch the crash
introduced the other day in linking code...
|
|
|
|
The changes come from the `functions` branch, where I'm using
these structures a lot.
This also includes a new `BLI::Optional<T>` type, which is similar
to `std::Optional<T>` which can be used when Blender starts using
C++17.
|
|
|
|
Patch from Jesse Y, reviewed by Habib Gahbiche.
Addes tests for modifiers: array, decimiate, mirror, screw, solidify,
subd, and weld.
|
|
|
|
A big rework of the code now uses exact predicates for orientation
and incircle. Also switched the main algorithm to use a faster
divide and conquer algorithm, which is possible with the exact
predicates.
|
|
This 'fixes' T68554: 'API mathutils.geometry.tessellate_polygon returns
bad results sometimes' by documenting the limitations of the current
implementation.
I've also added a unit test for the function, so that any change in this
behaviour will get noticed.
No functional changes.
|
|
|
|
The purpose of this line was to not use Blender Internal and associated old
materials, now either Eevee or Cycles is fine.
|
|
|
|
|
|
The dependency graph has to know whether a driver must be re-evaluated
every frame due to a dependency on the current frame number. For python
drivers it was using a heuristic based on searching for certain sub-
strings in the expression, notably including '('.
When the expression is actually evaluated using Python, this can't be
easily improved; however if the Simple Expression evaluator is used,
this check can be done precisely by accessing the parsed data.
Differential Revision: https://developer.blender.org/D6624
|
|
|
|
|
|
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
|