2022-02-11 09:07:11 +11:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
# Copyright 2006 Blender Foundation. All rights reserved.
|
2006-11-17 02:27:12 +00:00
|
|
|
|
2013-08-17 05:33:55 +00:00
|
|
|
set(INC
|
2010-09-06 10:15:41 +00:00
|
|
|
.
|
2021-06-22 10:42:32 -07:00
|
|
|
# ../blenkernel # don't add this back!
|
2011-07-17 09:11:13 +00:00
|
|
|
../makesdna
|
2014-12-02 15:23:58 +05:00
|
|
|
../../../intern/atomic
|
2015-12-10 01:18:01 +01:00
|
|
|
../../../intern/eigen
|
2019-04-24 14:39:31 +10:00
|
|
|
../../../intern/guardedalloc
|
2013-03-12 07:25:53 +00:00
|
|
|
../../../extern/wcwidth
|
2021-10-26 13:05:59 +02:00
|
|
|
../../../extern/json/include
|
2011-05-31 01:15:44 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
set(INC_SYS
|
2011-01-25 14:43:13 +00:00
|
|
|
${ZLIB_INCLUDE_DIRS}
|
Add support for Zstandard compression for .blend files
Compressing blendfiles can help save a lot of disk space, but the slowdown
while loading and saving is a major annoyance.
Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there
are now several more modern algorithms that outperform it in every way.
In this patch, I decided for Zstandard aka Zstd for several reasons:
- It is widely supported, both in other programs and libraries as well as in
general-purpose compression utilities on Unix
- It is extremely flexible - spanning several orders of magnitude of
compression speeds depending on the level setting.
- It is pretty much on the Pareto frontier for all of its configurations
(meaning that no other algorithm is both faster and more efficient).
One downside of course is that older versions of Blender will not be able to
read these files, but one can always just re-save them without compression or
decompress the file manually with an external tool.
The implementation here saves additional metadata into the compressed file in
order to allow for efficient seeking when loading. This is standard-compliant
and will be ignored by other tools that support Zstd.
If the metadata is not present (e.g. because you manually compressed a .blend
file with another tool), Blender will fall back to sequential reading.
Saving is multithreaded to improve performance. Loading is currently not
multithreaded since it's not easy to predict the access patterns of the
loading code when seeking is supported.
In the future, we might want to look into making this more predictable or
disabling seeking for the main .blend file, which would then allow for
multiple background threads that decompress data ahead of time.
The compression level was chosen to get sizes comparable to previous versions
at much higher speeds. In the future, this could be exposed as an option.
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
2021-08-21 03:15:31 +02:00
|
|
|
${ZSTD_INCLUDE_DIRS}
|
2020-08-28 10:56:44 -04:00
|
|
|
${GMP_INCLUDE_DIRS}
|
2006-11-17 02:27:12 +00:00
|
|
|
)
|
|
|
|
|
2010-10-23 04:05:55 +00:00
|
|
|
set(SRC
|
|
|
|
intern/BLI_args.c
|
2013-01-19 07:35:55 +00:00
|
|
|
intern/BLI_array.c
|
2020-08-06 20:17:44 +10:00
|
|
|
intern/BLI_assert.c
|
2021-05-25 17:16:35 +02:00
|
|
|
intern/BLI_color.cc
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/BLI_dial_2d.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_dynstr.c
|
2015-04-04 17:15:33 +11:00
|
|
|
intern/BLI_filelist.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_ghash.c
|
2018-02-18 21:44:56 +11:00
|
|
|
intern/BLI_ghash_utils.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_heap.c
|
2018-11-06 12:52:34 +11:00
|
|
|
intern/BLI_heap_simple.c
|
2019-09-12 14:23:21 +02:00
|
|
|
intern/BLI_index_range.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_kdopbvh.c
|
|
|
|
intern/BLI_linklist.c
|
2018-04-13 13:31:55 +02:00
|
|
|
intern/BLI_linklist_lockfree.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_memarena.c
|
2019-05-07 17:52:57 +02:00
|
|
|
intern/BLI_memblock.c
|
2017-07-29 23:38:20 +10:00
|
|
|
intern/BLI_memiter.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/BLI_mempool.c
|
2021-01-14 22:02:48 +01:00
|
|
|
intern/BLI_mmap.c
|
2018-11-26 20:25:15 +01:00
|
|
|
intern/BLI_timer.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/DLRB_tree.c
|
2016-05-30 15:25:36 +10:00
|
|
|
intern/array_store.c
|
2016-06-08 18:34:01 +10:00
|
|
|
intern/array_store_utils.c
|
2015-02-14 07:28:15 +11:00
|
|
|
intern/array_utils.c
|
2015-01-09 10:56:17 +01:00
|
|
|
intern/astar.c
|
2018-12-15 11:47:24 +03:00
|
|
|
intern/bitmap.c
|
2016-10-26 20:11:09 +11:00
|
|
|
intern/bitmap_draw_2d.c
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/boxpack_2d.c
|
2012-12-30 18:28:10 +00:00
|
|
|
intern/buffer.c
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/convexhull_2d.c
|
2022-03-18 10:57:45 +01:00
|
|
|
intern/cpp_type.cc
|
2020-08-28 10:56:44 -04:00
|
|
|
intern/delaunay_2d.cc
|
2020-04-28 14:05:24 +02:00
|
|
|
intern/dot_export.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/dynlib.c
|
2014-03-25 08:00:51 +11:00
|
|
|
intern/easing.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/edgehash.c
|
2012-09-03 07:37:38 +00:00
|
|
|
intern/endian_switch.c
|
2018-09-19 10:40:35 +10:00
|
|
|
intern/expr_pylike_eval.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/fileops.c
|
2021-12-21 15:53:52 +01:00
|
|
|
intern/fileops.cc
|
2021-08-19 23:57:00 +02:00
|
|
|
intern/filereader_file.c
|
|
|
|
intern/filereader_gzip.c
|
|
|
|
intern/filereader_memory.c
|
Add support for Zstandard compression for .blend files
Compressing blendfiles can help save a lot of disk space, but the slowdown
while loading and saving is a major annoyance.
Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there
are now several more modern algorithms that outperform it in every way.
In this patch, I decided for Zstandard aka Zstd for several reasons:
- It is widely supported, both in other programs and libraries as well as in
general-purpose compression utilities on Unix
- It is extremely flexible - spanning several orders of magnitude of
compression speeds depending on the level setting.
- It is pretty much on the Pareto frontier for all of its configurations
(meaning that no other algorithm is both faster and more efficient).
One downside of course is that older versions of Blender will not be able to
read these files, but one can always just re-save them without compression or
decompress the file manually with an external tool.
The implementation here saves additional metadata into the compressed file in
order to allow for efficient seeking when loading. This is standard-compliant
and will be ignored by other tools that support Zstd.
If the metadata is not present (e.g. because you manually compressed a .blend
file with another tool), Blender will fall back to sequential reading.
Saving is multithreaded to improve performance. Loading is currently not
multithreaded since it's not easy to predict the access patterns of the
loading code when seeking is supported.
In the future, we might want to look into making this more predictable or
disabling seeking for the main .blend file, which would then allow for
multiple background threads that decompress data ahead of time.
The compression level was chosen to get sizes comparable to previous versions
at much higher speeds. In the future, this could be exposed as an option.
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
2021-08-21 03:15:31 +02:00
|
|
|
intern/filereader_zstd.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/fnmatch.c
|
2022-03-19 08:26:29 +01:00
|
|
|
intern/generic_vector_array.cc
|
|
|
|
intern/generic_virtual_array.cc
|
|
|
|
intern/generic_virtual_vector_array.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/gsqueue.c
|
2014-11-14 11:00:10 +01:00
|
|
|
intern/hash_md5.c
|
|
|
|
intern/hash_mm2a.c
|
2018-07-18 13:03:09 +02:00
|
|
|
intern/hash_mm3.c
|
2021-09-15 11:02:39 +02:00
|
|
|
intern/index_mask.cc
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/jitter_2d.c
|
2019-03-20 01:20:46 +11:00
|
|
|
intern/kdtree_1d.c
|
2019-03-20 00:57:52 +11:00
|
|
|
intern/kdtree_2d.c
|
2019-03-18 11:22:48 +11:00
|
|
|
intern/kdtree_3d.c
|
|
|
|
intern/kdtree_4d.c
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/lasso_2d.c
|
2022-03-29 19:44:01 -05:00
|
|
|
intern/length_parameterize.cc
|
2022-05-05 17:33:10 +10:00
|
|
|
intern/listbase.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/math_base.c
|
|
|
|
intern/math_base_inline.c
|
2020-07-16 11:28:31 +02:00
|
|
|
intern/math_base_safe_inline.c
|
2015-04-22 04:10:15 +10:00
|
|
|
intern/math_bits_inline.c
|
2020-08-28 10:56:44 -04:00
|
|
|
intern/math_boolean.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/math_color.c
|
2013-04-27 12:51:23 +00:00
|
|
|
intern/math_color_blend_inline.c
|
2011-12-28 22:57:25 +00:00
|
|
|
intern/math_color_inline.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/math_geom.c
|
|
|
|
intern/math_geom_inline.c
|
2012-11-10 19:11:25 +00:00
|
|
|
intern/math_interp.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/math_matrix.c
|
|
|
|
intern/math_rotation.c
|
2022-04-15 09:54:15 -05:00
|
|
|
intern/math_rotation.cc
|
2015-07-13 17:48:13 +02:00
|
|
|
intern/math_solvers.c
|
2015-07-13 17:53:22 +02:00
|
|
|
intern/math_statistics.c
|
2021-06-22 17:00:18 +02:00
|
|
|
intern/math_time.c
|
2020-08-28 10:56:44 -04:00
|
|
|
intern/math_vec.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/math_vector.c
|
|
|
|
intern/math_vector_inline.c
|
2015-10-20 14:39:08 +02:00
|
|
|
intern/memory_utils.c
|
2020-08-28 10:56:44 -04:00
|
|
|
intern/mesh_boolean.cc
|
|
|
|
intern/mesh_intersect.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/noise.c
|
2021-09-10 14:25:32 +02:00
|
|
|
intern/noise.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/path_util.c
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/polyfill_2d.c
|
|
|
|
intern/polyfill_2d_beautify.c
|
2012-10-19 07:20:37 +00:00
|
|
|
intern/quadric.c
|
2020-07-09 16:37:44 +02:00
|
|
|
intern/rand.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/rct.c
|
2021-10-03 14:23:26 +02:00
|
|
|
intern/resource_scope.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/scanfill.c
|
2014-02-13 19:09:28 +11:00
|
|
|
intern/scanfill_utils.c
|
2021-10-26 13:05:59 +02:00
|
|
|
intern/serialize.cc
|
2022-01-06 13:54:55 +11:00
|
|
|
intern/session_uuid.c
|
2011-09-09 02:52:20 +00:00
|
|
|
intern/smallhash.c
|
2013-08-19 10:40:47 +00:00
|
|
|
intern/sort.c
|
2013-09-05 22:24:12 +00:00
|
|
|
intern/sort_utils.c
|
2012-08-05 23:29:43 +00:00
|
|
|
intern/stack.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/storage.c
|
|
|
|
intern/string.c
|
2012-03-07 15:55:12 +00:00
|
|
|
intern/string_cursor_utf8.c
|
2020-09-09 13:40:14 +02:00
|
|
|
intern/string_search.cc
|
2011-09-15 08:07:42 +00:00
|
|
|
intern/string_utf8.c
|
2017-01-16 17:33:34 +01:00
|
|
|
intern/string_utils.c
|
2014-04-02 11:43:54 +02:00
|
|
|
intern/system.c
|
2020-05-25 12:24:56 +02:00
|
|
|
intern/task_graph.cc
|
2020-04-09 15:51:44 +02:00
|
|
|
intern/task_iterator.c
|
2020-04-30 07:59:23 +02:00
|
|
|
intern/task_pool.cc
|
|
|
|
intern/task_range.cc
|
|
|
|
intern/task_scheduler.cc
|
2020-07-02 16:19:18 +02:00
|
|
|
intern/threads.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/time.c
|
2014-01-29 20:01:30 +11:00
|
|
|
intern/timecode.c
|
2020-04-22 12:53:47 +02:00
|
|
|
intern/timeit.cc
|
2021-09-17 11:53:00 +02:00
|
|
|
intern/uuid.cc
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/uvproject.c
|
2018-02-18 21:27:33 +11:00
|
|
|
intern/voronoi_2d.c
|
2012-10-19 07:20:37 +00:00
|
|
|
intern/voxel.c
|
2010-10-23 04:05:55 +00:00
|
|
|
intern/winstuff.c
|
2014-01-15 08:38:00 +11:00
|
|
|
intern/winstuff_dir.c
|
2010-11-29 04:35:56 +00:00
|
|
|
|
2021-06-09 22:49:45 +10:00
|
|
|
# Private headers.
|
|
|
|
intern/BLI_mempool_private.h
|
|
|
|
|
2019-03-18 11:22:48 +11:00
|
|
|
# Header as source (included in C files above).
|
|
|
|
intern/kdtree_impl.h
|
|
|
|
intern/list_sort_impl.h
|
|
|
|
|
2019-09-12 14:23:21 +02:00
|
|
|
|
2013-07-28 10:38:25 +00:00
|
|
|
BLI_alloca.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_allocator.hh
|
Geometry Nodes: refactor virtual array system
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
|
|
|
BLI_any.hh
|
2013-09-05 19:56:49 +00:00
|
|
|
BLI_args.h
|
2011-05-09 04:06:48 +00:00
|
|
|
BLI_array.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_array.hh
|
2016-05-30 15:25:36 +10:00
|
|
|
BLI_array_store.h
|
2016-06-08 18:34:01 +10:00
|
|
|
BLI_array_store_utils.h
|
2015-02-14 07:28:15 +11:00
|
|
|
BLI_array_utils.h
|
2020-05-27 10:52:07 +10:00
|
|
|
BLI_asan.h
|
2018-06-17 11:56:20 +02:00
|
|
|
BLI_assert.h
|
2015-01-09 10:56:17 +01:00
|
|
|
BLI_astar.h
|
2012-02-22 23:57:31 +00:00
|
|
|
BLI_bitmap.h
|
2016-10-26 20:11:09 +11:00
|
|
|
BLI_bitmap_draw_2d.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_blenlib.h
|
2022-02-16 10:53:40 -06:00
|
|
|
BLI_bounds.hh
|
2022-03-25 12:04:14 +11:00
|
|
|
BLI_boxpack_2d.h
|
2013-09-05 19:56:49 +00:00
|
|
|
BLI_buffer.h
|
2020-04-21 16:55:00 +02:00
|
|
|
BLI_color.hh
|
2022-04-20 22:03:45 -07:00
|
|
|
BLI_color_mix.hh
|
2013-09-05 19:56:49 +00:00
|
|
|
BLI_compiler_attrs.h
|
2014-05-02 01:14:15 +10:00
|
|
|
BLI_compiler_compat.h
|
2014-09-25 13:05:42 +10:00
|
|
|
BLI_compiler_typecheck.h
|
2018-03-16 12:16:29 +01:00
|
|
|
BLI_console.h
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_convexhull_2d.h
|
2022-03-18 10:57:45 +01:00
|
|
|
BLI_cpp_type.hh
|
2022-03-25 12:04:14 +11:00
|
|
|
BLI_cpp_type_make.hh
|
2019-08-10 08:24:20 -05:00
|
|
|
BLI_delaunay_2d.h
|
2022-04-26 17:12:34 +02:00
|
|
|
BLI_devirtualize_parameters.hh
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_dial_2d.h
|
2020-07-08 14:57:31 +02:00
|
|
|
BLI_disjoint_set.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_dlrbTree.h
|
2020-04-28 14:05:24 +02:00
|
|
|
BLI_dot_export.hh
|
|
|
|
BLI_dot_export_attribute_enums.hh
|
2011-05-06 15:17:42 +00:00
|
|
|
BLI_dynlib.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_dynstr.h
|
2014-03-25 08:00:51 +11:00
|
|
|
BLI_easing.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_edgehash.h
|
2021-07-08 13:20:32 +10:00
|
|
|
BLI_endian_defines.h
|
2012-09-03 07:37:38 +00:00
|
|
|
BLI_endian_switch.h
|
|
|
|
BLI_endian_switch_inline.h
|
2021-05-13 13:20:16 +02:00
|
|
|
BLI_enumerable_thread_specific.hh
|
2018-09-19 10:40:35 +10:00
|
|
|
BLI_expr_pylike_eval.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_fileops.h
|
2021-12-21 15:53:52 +01:00
|
|
|
BLI_fileops.hh
|
2011-10-22 15:35:49 +00:00
|
|
|
BLI_fileops_types.h
|
2021-08-26 12:41:26 +10:00
|
|
|
BLI_filereader.h
|
2022-05-06 11:22:10 +02:00
|
|
|
BLI_float3x3.hh
|
2020-04-21 16:55:00 +02:00
|
|
|
BLI_float4x4.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_fnmatch.h
|
2021-02-23 11:47:01 +01:00
|
|
|
BLI_function_ref.hh
|
2022-03-19 08:26:29 +01:00
|
|
|
BLI_generic_array.hh
|
|
|
|
BLI_generic_pointer.hh
|
|
|
|
BLI_generic_span.hh
|
|
|
|
BLI_generic_value_map.hh
|
|
|
|
BLI_generic_vector_array.hh
|
|
|
|
BLI_generic_virtual_array.hh
|
|
|
|
BLI_generic_virtual_vector_array.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_ghash.h
|
|
|
|
BLI_gsqueue.h
|
2017-04-19 00:25:31 +10:00
|
|
|
BLI_hash.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_hash.hh
|
2014-11-14 11:00:10 +01:00
|
|
|
BLI_hash_md5.h
|
|
|
|
BLI_hash_mm2a.h
|
2018-07-18 13:03:09 +02:00
|
|
|
BLI_hash_mm3.h
|
2020-06-09 10:10:56 +02:00
|
|
|
BLI_hash_tables.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_heap.h
|
2018-11-06 12:52:34 +11:00
|
|
|
BLI_heap_simple.h
|
2020-06-08 17:37:43 +02:00
|
|
|
BLI_index_mask.hh
|
2022-02-23 16:56:27 +01:00
|
|
|
BLI_index_mask_ops.hh
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_index_range.hh
|
2020-12-16 12:19:17 +01:00
|
|
|
BLI_inplace_priority_queue.hh
|
Render Layers and Collections (merge from render-layers)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
2017-02-07 10:18:38 +01:00
|
|
|
BLI_iterator.h
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_jitter_2d.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_kdopbvh.h
|
|
|
|
BLI_kdtree.h
|
2019-03-18 11:22:48 +11:00
|
|
|
BLI_kdtree_impl.h
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_lasso_2d.h
|
2022-03-29 19:44:01 -05:00
|
|
|
BLI_length_parameterize.hh
|
2020-07-16 13:17:31 +10:00
|
|
|
BLI_linear_allocator.hh
|
2014-04-18 20:32:50 +10:00
|
|
|
BLI_link_utils.h
|
2018-06-17 11:56:20 +02:00
|
|
|
BLI_linklist.h
|
2018-04-13 13:31:55 +02:00
|
|
|
BLI_linklist_lockfree.h
|
2013-08-17 05:33:55 +00:00
|
|
|
BLI_linklist_stack.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_listbase.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_listbase_wrapper.hh
|
|
|
|
BLI_map.hh
|
2020-06-09 10:10:56 +02:00
|
|
|
BLI_map_slots.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_math.h
|
|
|
|
BLI_math_base.h
|
2022-03-25 12:04:14 +11:00
|
|
|
BLI_math_base.hh
|
2020-07-16 11:28:31 +02:00
|
|
|
BLI_math_base_safe.h
|
2015-05-17 16:09:15 +10:00
|
|
|
BLI_math_bits.h
|
2020-08-28 10:56:44 -04:00
|
|
|
BLI_math_boolean.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_math_color.h
|
2022-03-29 19:44:01 -05:00
|
|
|
BLI_math_color.hh
|
2013-04-27 12:51:23 +00:00
|
|
|
BLI_math_color_blend.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_math_geom.h
|
|
|
|
BLI_math_inline.h
|
2012-12-04 14:43:42 +00:00
|
|
|
BLI_math_interp.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_math_matrix.h
|
2020-09-30 11:51:42 +10:00
|
|
|
BLI_math_mpq.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_math_rotation.h
|
2022-04-15 09:54:15 -05:00
|
|
|
BLI_math_rotation.hh
|
2015-07-13 17:48:13 +02:00
|
|
|
BLI_math_solvers.h
|
2015-07-13 17:53:22 +02:00
|
|
|
BLI_math_statistics.h
|
2021-06-22 17:00:18 +02:00
|
|
|
BLI_math_time.h
|
BLI: Refactor vector types & functions to use templates
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
2022-01-12 12:57:07 +01:00
|
|
|
BLI_math_vec_mpq_types.hh
|
2022-01-24 21:23:30 +11:00
|
|
|
BLI_math_vec_types.hh
|
|
|
|
BLI_math_vector.h
|
2022-02-23 12:30:56 +11:00
|
|
|
BLI_math_vector.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_memarena.h
|
2019-05-07 17:52:57 +02:00
|
|
|
BLI_memblock.h
|
2017-07-29 23:38:20 +10:00
|
|
|
BLI_memiter.h
|
2015-10-20 14:39:08 +02:00
|
|
|
BLI_memory_utils.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_memory_utils.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_mempool.h
|
2020-08-28 10:56:44 -04:00
|
|
|
BLI_mesh_boolean.hh
|
|
|
|
BLI_mesh_intersect.hh
|
2021-01-14 22:02:48 +01:00
|
|
|
BLI_mmap.h
|
2020-09-07 23:10:17 +10:00
|
|
|
BLI_multi_value_map.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_noise.h
|
2021-09-10 14:25:32 +02:00
|
|
|
BLI_noise.hh
|
2022-04-26 17:12:34 +02:00
|
|
|
BLI_parameter_pack_utils.hh
|
2022-05-05 17:33:10 +10:00
|
|
|
BLI_path_util.h
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_polyfill_2d.h
|
|
|
|
BLI_polyfill_2d_beautify.h
|
2020-06-09 10:10:56 +02:00
|
|
|
BLI_probing_strategies.hh
|
2012-10-19 07:20:37 +00:00
|
|
|
BLI_quadric.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_rand.h
|
2020-07-16 13:17:31 +10:00
|
|
|
BLI_rand.hh
|
2021-08-03 08:10:07 +02:00
|
|
|
BLI_range.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_rect.h
|
2021-04-01 15:55:08 +02:00
|
|
|
BLI_resource_scope.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_scanfill.h
|
2022-01-06 13:54:55 +11:00
|
|
|
BLI_serialize.hh
|
2020-07-30 11:12:13 +02:00
|
|
|
BLI_session_uuid.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_set.hh
|
2020-06-09 10:10:56 +02:00
|
|
|
BLI_set_slots.hh
|
2021-03-26 12:23:21 +11:00
|
|
|
BLI_simd.h
|
2012-04-27 07:26:28 +00:00
|
|
|
BLI_smallhash.h
|
2013-08-19 10:40:47 +00:00
|
|
|
BLI_sort.h
|
2022-03-22 01:13:28 +01:00
|
|
|
BLI_sort.hh
|
2013-09-05 22:24:12 +00:00
|
|
|
BLI_sort_utils.h
|
2020-06-09 11:58:47 +02:00
|
|
|
BLI_span.hh
|
2012-08-05 23:29:43 +00:00
|
|
|
BLI_stack.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_stack.hh
|
2013-09-05 19:56:49 +00:00
|
|
|
BLI_strict_flags.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_string.h
|
2012-03-07 15:55:12 +00:00
|
|
|
BLI_string_cursor_utf8.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_string_ref.hh
|
2020-09-30 11:51:42 +10:00
|
|
|
BLI_string_search.h
|
2011-10-20 09:47:05 +00:00
|
|
|
BLI_string_utf8.h
|
2017-01-16 17:33:34 +01:00
|
|
|
BLI_string_utils.h
|
2013-05-28 19:35:26 +00:00
|
|
|
BLI_sys_types.h
|
2014-04-02 11:43:54 +02:00
|
|
|
BLI_system.h
|
2013-10-12 14:08:59 +00:00
|
|
|
BLI_task.h
|
2021-01-20 16:08:52 +11:00
|
|
|
BLI_task.hh
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_threads.h
|
2014-01-29 20:01:30 +11:00
|
|
|
BLI_timecode.h
|
2020-04-22 12:53:47 +02:00
|
|
|
BLI_timeit.hh
|
2018-11-26 20:25:15 +01:00
|
|
|
BLI_timer.h
|
2020-12-02 13:25:25 +01:00
|
|
|
BLI_user_counter.hh
|
2011-01-07 18:36:47 +00:00
|
|
|
BLI_utildefines.h
|
2017-09-19 20:25:20 +10:00
|
|
|
BLI_utildefines_iter.h
|
|
|
|
BLI_utildefines_stack.h
|
|
|
|
BLI_utildefines_variadic.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_utility_mixins.hh
|
2021-09-17 11:53:00 +02:00
|
|
|
BLI_uuid.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_uvproject.h
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_vector.hh
|
2020-07-23 22:30:05 +02:00
|
|
|
BLI_vector_adaptor.hh
|
2020-04-21 17:31:56 +02:00
|
|
|
BLI_vector_set.hh
|
2020-06-09 10:10:56 +02:00
|
|
|
BLI_vector_set_slots.hh
|
2021-03-21 19:31:24 +01:00
|
|
|
BLI_virtual_array.hh
|
|
|
|
BLI_virtual_vector_array.hh
|
2018-02-18 21:27:33 +11:00
|
|
|
BLI_voronoi_2d.h
|
2010-11-29 04:35:56 +00:00
|
|
|
BLI_voxel.h
|
|
|
|
BLI_winstuff.h
|
|
|
|
PIL_time.h
|
2013-09-03 21:22:43 +00:00
|
|
|
PIL_time_utildefines.h
|
2022-02-23 12:30:56 +11:00
|
|
|
|
|
|
|
# Without these files listed, they aren't known to CMake.
|
|
|
|
../../../extern/json/include/json.hpp
|
2008-01-22 05:34:53 +00:00
|
|
|
)
|
|
|
|
|
2019-04-14 15:18:44 +02:00
|
|
|
set(LIB
|
2019-04-16 06:18:52 +02:00
|
|
|
bf_intern_eigen
|
|
|
|
bf_intern_guardedalloc
|
|
|
|
extern_wcwidth
|
CMake: Refactor external dependencies handling
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
2020-01-20 18:36:19 +01:00
|
|
|
|
2020-09-15 11:16:35 +02:00
|
|
|
${ZLIB_LIBRARIES}
|
Add support for Zstandard compression for .blend files
Compressing blendfiles can help save a lot of disk space, but the slowdown
while loading and saving is a major annoyance.
Currently Blender uses Zlib (aka gzip aka Deflate) for compression, but there
are now several more modern algorithms that outperform it in every way.
In this patch, I decided for Zstandard aka Zstd for several reasons:
- It is widely supported, both in other programs and libraries as well as in
general-purpose compression utilities on Unix
- It is extremely flexible - spanning several orders of magnitude of
compression speeds depending on the level setting.
- It is pretty much on the Pareto frontier for all of its configurations
(meaning that no other algorithm is both faster and more efficient).
One downside of course is that older versions of Blender will not be able to
read these files, but one can always just re-save them without compression or
decompress the file manually with an external tool.
The implementation here saves additional metadata into the compressed file in
order to allow for efficient seeking when loading. This is standard-compliant
and will be ignored by other tools that support Zstd.
If the metadata is not present (e.g. because you manually compressed a .blend
file with another tool), Blender will fall back to sequential reading.
Saving is multithreaded to improve performance. Loading is currently not
multithreaded since it's not easy to predict the access patterns of the
loading code when seeking is supported.
In the future, we might want to look into making this more predictable or
disabling seeking for the main .blend file, which would then allow for
multiple background threads that decompress data ahead of time.
The compression level was chosen to get sizes comparable to previous versions
at much higher speeds. In the future, this could be exposed as an option.
Reviewed By: campbellbarton, brecht, mont29
Differential Revision: https://developer.blender.org/D5799
2021-08-21 03:15:31 +02:00
|
|
|
${ZSTD_LIBRARIES}
|
2019-04-14 15:18:44 +02:00
|
|
|
)
|
|
|
|
|
2013-10-03 12:22:44 +00:00
|
|
|
if(WITH_MEM_VALGRIND)
|
|
|
|
add_definitions(-DWITH_MEM_VALGRIND)
|
|
|
|
endif()
|
|
|
|
|
2020-04-30 07:59:23 +02:00
|
|
|
if(WITH_TBB)
|
|
|
|
add_definitions(-DWITH_TBB)
|
|
|
|
|
|
|
|
list(APPEND INC_SYS
|
|
|
|
${TBB_INCLUDE_DIRS}
|
|
|
|
)
|
2020-05-04 23:58:48 +02:00
|
|
|
|
|
|
|
list(APPEND LIB
|
|
|
|
${TBB_LIBRARIES}
|
|
|
|
)
|
2020-04-30 07:59:23 +02:00
|
|
|
endif()
|
|
|
|
|
2020-08-28 10:56:44 -04:00
|
|
|
if(WITH_GMP)
|
|
|
|
add_definitions(-DWITH_GMP)
|
|
|
|
|
|
|
|
list(APPEND INC_SYS
|
|
|
|
${GMP_INCLUDE_DIRS}
|
|
|
|
)
|
|
|
|
|
|
|
|
list(APPEND LIB
|
|
|
|
${GMP_LIBRARIES}
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2012-03-20 02:17:37 +00:00
|
|
|
if(WIN32)
|
2022-01-28 14:08:11 +11:00
|
|
|
if(WITH_BLENDER_THUMBNAILER)
|
|
|
|
# Needed for querying the `thumbnailer .dll` in `winstuff.c`.
|
2021-10-28 21:03:47 +02:00
|
|
|
add_definitions(-DWITH_BLENDER_THUMBNAILER)
|
|
|
|
endif()
|
2012-03-20 02:17:37 +00:00
|
|
|
list(APPEND INC
|
|
|
|
../../../intern/utfconv
|
|
|
|
)
|
2019-04-16 12:35:50 +02:00
|
|
|
list(APPEND LIB
|
|
|
|
bf_intern_utfconv
|
|
|
|
)
|
2020-05-01 07:37:48 -06:00
|
|
|
list(APPEND SRC
|
|
|
|
intern/system_win32.c
|
|
|
|
)
|
2012-03-20 02:17:37 +00:00
|
|
|
endif()
|
|
|
|
|
2020-03-26 17:52:41 +01:00
|
|
|
|
|
|
|
if(APPLE)
|
|
|
|
list(APPEND SRC
|
|
|
|
intern/storage_apple.mm
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2020-02-25 13:05:09 +01:00
|
|
|
if(UNIX AND NOT APPLE)
|
|
|
|
list(APPEND LIB
|
|
|
|
bf_intern_libc_compat
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2015-04-04 10:37:00 +11:00
|
|
|
# no need to compile object files for inline headers.
|
|
|
|
set_source_files_properties(
|
|
|
|
intern/math_base_inline.c
|
2020-07-16 11:28:31 +02:00
|
|
|
intern/math_base_safe_inline.c
|
2015-04-22 04:10:15 +10:00
|
|
|
intern/math_bits_inline.c
|
2015-04-04 10:37:00 +11:00
|
|
|
intern/math_color_blend_inline.c
|
|
|
|
intern/math_color_inline.c
|
|
|
|
intern/math_geom_inline.c
|
|
|
|
intern/math_vector_inline.c
|
|
|
|
PROPERTIES HEADER_FILE_ONLY TRUE
|
|
|
|
)
|
2012-11-23 15:12:13 +00:00
|
|
|
|
2019-04-14 15:18:44 +02:00
|
|
|
blender_add_lib(bf_blenlib "${SRC}" "${INC}" "${INC_SYS}" "${LIB}")
|
2020-07-23 15:23:55 +02:00
|
|
|
|
|
|
|
if(WITH_GTESTS)
|
|
|
|
set(TEST_SRC
|
Geometry Nodes: refactor virtual array system
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
|
|
|
tests/BLI_any_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_array_store_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_array_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_array_utils_test.cc
|
2022-02-16 10:53:40 -06:00
|
|
|
tests/BLI_bounds_test.cc
|
2021-05-25 17:16:35 +02:00
|
|
|
tests/BLI_color_test.cc
|
2022-03-18 10:57:45 +01:00
|
|
|
tests/BLI_cpp_type_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_delaunay_2d_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_disjoint_set_test.cc
|
|
|
|
tests/BLI_edgehash_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_expr_pylike_eval_test.cc
|
2021-12-21 15:53:52 +01:00
|
|
|
tests/BLI_fileops_test.cc
|
2022-05-06 11:22:10 +02:00
|
|
|
tests/BLI_float3x3_test.cc
|
2022-01-06 13:54:55 +11:00
|
|
|
tests/BLI_function_ref_test.cc
|
2022-03-19 08:26:29 +01:00
|
|
|
tests/BLI_generic_array_test.cc
|
|
|
|
tests/BLI_generic_span_test.cc
|
|
|
|
tests/BLI_generic_vector_array_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_ghash_test.cc
|
|
|
|
tests/BLI_hash_mm2a_test.cc
|
|
|
|
tests/BLI_heap_simple_test.cc
|
|
|
|
tests/BLI_heap_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_index_mask_test.cc
|
|
|
|
tests/BLI_index_range_test.cc
|
2020-12-16 12:19:17 +01:00
|
|
|
tests/BLI_inplace_priority_queue_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_kdopbvh_test.cc
|
2022-03-29 19:44:01 -05:00
|
|
|
tests/BLI_length_parameterize_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_linear_allocator_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_linklist_lockfree_test.cc
|
|
|
|
tests/BLI_listbase_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_map_test.cc
|
|
|
|
tests/BLI_math_base_safe_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_math_base_test.cc
|
|
|
|
tests/BLI_math_bits_test.cc
|
|
|
|
tests/BLI_math_color_test.cc
|
|
|
|
tests/BLI_math_geom_test.cc
|
|
|
|
tests/BLI_math_matrix_test.cc
|
2020-11-30 19:31:21 +03:00
|
|
|
tests/BLI_math_rotation_test.cc
|
2020-11-28 14:44:10 +03:00
|
|
|
tests/BLI_math_solvers_test.cc
|
2021-06-22 17:00:18 +02:00
|
|
|
tests/BLI_math_time_test.cc
|
BLI: Refactor vector types & functions to use templates
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
2022-01-12 12:57:07 +01:00
|
|
|
tests/BLI_math_vec_types_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_math_vector_test.cc
|
|
|
|
tests/BLI_memiter_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_memory_utils_test.cc
|
2020-08-28 10:56:44 -04:00
|
|
|
tests/BLI_mesh_boolean_test.cc
|
|
|
|
tests/BLI_mesh_intersect_test.cc
|
2020-07-24 12:15:13 +02:00
|
|
|
tests/BLI_multi_value_map_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_path_util_test.cc
|
|
|
|
tests/BLI_polyfill_2d_test.cc
|
|
|
|
tests/BLI_ressource_strings.h
|
2022-01-06 13:54:55 +11:00
|
|
|
tests/BLI_serialize_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_session_uuid_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_set_test.cc
|
|
|
|
tests/BLI_span_test.cc
|
|
|
|
tests/BLI_stack_cxx_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_stack_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_string_ref_test.cc
|
2020-09-30 11:51:42 +10:00
|
|
|
tests/BLI_string_search_test.cc
|
2020-08-07 16:43:42 +02:00
|
|
|
tests/BLI_string_test.cc
|
|
|
|
tests/BLI_string_utf8_test.cc
|
|
|
|
tests/BLI_task_graph_test.cc
|
|
|
|
tests/BLI_task_test.cc
|
2021-09-17 11:53:00 +02:00
|
|
|
tests/BLI_uuid_test.cc
|
2020-07-23 15:23:55 +02:00
|
|
|
tests/BLI_vector_set_test.cc
|
|
|
|
tests/BLI_vector_test.cc
|
2021-03-21 19:31:24 +01:00
|
|
|
tests/BLI_virtual_array_test.cc
|
2020-08-19 16:44:53 +02:00
|
|
|
|
|
|
|
tests/BLI_exception_safety_test_utils.hh
|
2020-07-23 15:23:55 +02:00
|
|
|
)
|
2020-08-07 16:43:42 +02:00
|
|
|
set(TEST_INC
|
|
|
|
../imbuf
|
|
|
|
)
|
2020-07-23 15:23:55 +02:00
|
|
|
set(TEST_LIB
|
|
|
|
bf_blenlib
|
|
|
|
)
|
|
|
|
include(GTestTesting)
|
2020-09-15 11:16:35 +02:00
|
|
|
blender_add_test_executable(blenlib "${TEST_SRC}" "${INC};${TEST_INC}" "${INC_SYS}" "${LIB};${TEST_LIB}")
|
2020-08-07 16:43:42 +02:00
|
|
|
|
|
|
|
add_subdirectory(tests/performance)
|
2020-07-23 15:23:55 +02:00
|
|
|
endif()
|