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
We can't use the fast path when the mesh is used by mulitple objects and so
slower sculpting is expected then. But fake users should not affect this. This
also fixes the same type of error in a few other areas.
The default was changed with an initial implementation of the feature.
With the feedback from animators, having a behavior which affects curves
outside of a changing range is not convenient for professional animators
working on high quality character animation. On the other hand, automatic
smoothing is better for casual animation of object motion.
This change adds an ability to change the default via User Preferences.
Differential Revision: https://developer.blender.org/D5875
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 0b2d1badec
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.
Some external tools seem to have issues with the definition
of Collada <transparency> - a float value in range (0,1).
However it is possible to use the <transparent> color as a container
for the <transparency> value. This seems to be a more reliable
method to export transparency values from Blender PBSDF Shaders.
The relevant documentation is in the collada 1.14 reference manual,
page 7-5 about the usage of transparent and transparency.
This fix makes export and import of the <transparency>
and <transparent> values more convenient and more reliable.
Reviewers: brecht, jesterking
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5305
Fixed: The Collada Exporter only supports export of
Lambert Shaders. But Shininess is not supported with
Lambert Shaders. The exporter must not add Shininess
to the Shader data!
Fixed: The Collada Importer adds an illegal value of -1
for reflectivity when this parameters is not defined in
the imported collada data. Now reflectivity is only
set when the import data contains a valid value.
Discarded: The Collada Importer handles shininess in a
dubious way. I have discarded import for now.
This needs to be reworked carefully in 2.81.
Differential Revision: https://developer.blender.org/D5262
- added import of transparency and emission into principled BSDF Shader
- added support for importing all default collada material parameters
* diffuse
* emission
* index_of_refraction
* shininess (mapped to BSDF Roughness)
* reflectivity (mapped to BSDF Metallic)
* transparency + transparent mapped to BSDF Alpha)
* ambient (creates unconnected texture node)
* specular (creates unconnected texture node)
* reflective(creates unconnected texture node)
- added support for exporting collada material parameters:
* diffuse
* emission
* index_of_refraction
* shininess (mapped to BSDF Roughness)
* reflectivity (mapped to BSDF Metallic)
* transparency + transparent mapped to BSDF Alpha)
- prepared support for exporting the following parameters
but currently commented out:
* ambient (creates unconnected texture node)
* specular (creates unconnected texture node)
* reflective(creates unconnected texture node)
Problem: For now we only allow export of principled BSDF based
materials. I am not sure from where to get ambient, specular
and reflective as those values are not included in the
principled BSDF Shader (wip).
1.) The Blender order of applying transforms is:
Scale
Rotation
Transformation
Reasoning: This order ensures there is no shearing, which happens
when you do scaling after rotation, see also:
https://blender.stackexchange.com/questions/1806
The Collada exporter now exports in the order how the transforms
need to be applied upon import.
2.) Also removed obsolete #if 0 lines
Currently we can not export Decompsed Transforms in combination with
Armature asnimations. As a temporary workaround enforce export
of transformations as Matrix for armature objects.
