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
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
Most important changes are in the Animation exporter and Animation Importer.
There is still some cleaning up to be done. But the Exporter/Importer basically
work within Blender 2.8
Some details:
User Interface:
The interface has been reorganized to look more like the FBX interface.
New options in user interface:
* keep_keyframes:
When sampling the distance between 2 keyframes is defined by
the sampling rate. Furthermore the keyframes defined in the
FCurves are not exported. However when this option is enabled
then also the defined keyframes will be added to the exported fcurves
* keep_smooth_curves:
When sampling we do not use FCurves. So we also have no Curve handles
for smooth exporting. However when this option is enabled, Blender
does its best to recreate the handles for export. This is a very
experimental feature and it is know to break when:
- the exported animated objects have parent inverse matrices
different from the unit matrix
- The exported objects have negative scaling
There may be many other situations when this feature breaks.
This needs to be further tested. It may be removed later or replaced
by something less wonky.
BlenderContext:
is a new class that contains the bridge to Blender. It contains
pointers to the current export/import context plus derived values
of Depsgraph, Scene, Main
Reporting:
I reorganized the output on the Blender Console to become more
informative and more readable
Preservation of Item names:
name attributes are now encoded with XML entities. This makes
sure that i can export/import names exactly defined in the tool.
This affects material names, bone names and object names.
Hierarchy export:
* Object and Bone Hierarchies are now exported correctly
by taking the Blender parent/child hierarchy into account
* Export also not selected intermediate objects
Problem:
When we export an Object Hierarchy, then we must export
all elements of the hierarchy to maintain the transforms. This
is especially important when exporting animated objects, because the
animation curves are exported as relative curves based on the
parent-child hierarchy. If an intermediate animated object is missing
then the exported animation breaks.
Solution:
If the "Selected" Optioon is enabled, then take care
to also export all objects which are not selected and hidden,
but which are parents of selected objects.
Node Based Material Importer (wip):
Added basic support for Materials with diffuse color and
diffuse textures. More properties (opacity, emission) need
changes in the used shader.
Note: Materials are all constructed by using the principled BSDF shader.
Animation Exporter:
* Massive optimization of the Animation Bake tool (Animation Sampler).
Instead of sampling each fcurve separately, i now sample all
exported fcurves simultaneously. So i avoid many (many!)
scene updates during animation export.
* Add support for Continuous Acceleration (Fcurve handles)
This allows us to create smoother FCurves during importing Collada
Animation curves. Possibly this should become an option ionstead of
a fixed import feature.
* Add support for sampling curves (to bake animations)
* The animation sampler now can be used for any animation curve.
Before the sampler only looked at curves which are supported by
Standard Collada 1.4. However the Collada exporter currently
ignores all animation curves which are not covered by the 1.4.1
Collada Standards. There is still some room for improvements
here (work in progres)
Known issues:
* Some exports do currently not work reliably, among those
are the camera animations, material animations and light animations
those animations will be added back next (work in progres)
* Exporting animation curves with keyframes (and tangents)
sometimes results in odd curves (when parent inverse matrix is involved)
This needs to be checked in more depth (probably it can not be solved).
* Export of "all animations in scene" is disabled because the
Collada Importer can not handle this reliably at the
moment (work in progres).
* Support for Animation Clip export
Added one extra level to the exported animations
such that now all scene animations are enclosed:
<Animation name="id_name(ob)_Action">
<Animation>...</Animation>
...
</Animation>
Animation Importer:
* Import of animations for objects with multiple materials
When importing multiple materials for one object,
the imported material animation curves have all been
assigned to the first material in the object.
Error handling (wip):
The Importer was a bit confused as it sometimes ignored fatal
parsing errors and continued to import. I did my best to
unconfuse it, but i believe that this needs to be tested more.
Refactoring:
update : move generation of effect id names into own function
update : adjust importer/exporter for no longer supported HEMI lights
cleanup: Removed no lopnger existing attribute from the exporter presets
cleanup: Removed not needed Context attribute from DocumentExporter
fix : Avoid duplicate deletion of temporary items
cleanup: fixed indentation and white space issues
update : Make BCAnimation class more self contained
cleanup: Renamed classes, updated comments for better reading
cleanup: Moved static class functions to collada_utils
cleanup: Moved typedefs to more intuitive locations
cleanup: indentation and class method declarations
cleanup: Removed no longer needed methods
update : Moved Classes into separate files
cleanup: Added comments
cleanup: take care of name conventions
... : many more small changes, not helpful to list them all
- 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`.
OpenCOLLADA is a validating parser, so is pretty strict about document form. The added error handler will print out any errors the parser finds. A pop-up will be shown too, advising the user to check the console for the error log.
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
fix included in report from Martijn Berger (mberger)
made some small changes.
- use ints rather then unsigned long for printing, values are not likely to be very large.
- CMake remove strict flags from collada build dir since I had warnings in the collada headers.
- added xml2 to collada libraries else I couldnt get collada building.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
