Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-02-11File headers: SPDX License migrationCampbell Barton
Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-01-12Revert "BLI: Refactor vector types & functions to use templates"Clément Foucault
Includes unwanted changes This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
2022-01-12BLI: Refactor vector types & functions to use templatesClment Foucault
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-12Revert "BLI: Refactor vector types & functions to use templates"Clément Foucault
Reverted because the commit removes a lot of commits. This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
2022-01-12BLI: Refactor vector types & functions to use templatesClément Foucault
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 @Howard Trickey (howardt) opinion on the matter. - The noexcept on the copy constructor of mpq(2|3) is being removed. But according to @Jacques Lucke (JacquesLucke) it is not a real problem for now. I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who helped during this and pushed me to reduce the duplication further. Reviewed By: brecht, sergey, JacquesLucke Differential Revision: http://developer.blender.org/D13791
2022-01-12Cleanup: remove redundant const qualifiers for POD typesCampbell Barton
2021-12-09Cleanup: move public doc-strings into headers for 'blenlib'Campbell Barton
- Added space below non doc-string comments to make it clear these aren't comments for the symbols directly below them. - Use doxy sections for some headers. - Minor improvements to doc-strings. Ref T92709
2021-06-26Cleanup: full sentences in comments, improve comment formattingCampbell Barton
2020-11-25Fluid Particles: fix viscoelastic spring threading crash again after D7394.Alexander Gavrilov
Since D6133 fluid particle code uses thread local storage to collect springs created during a time step before adding them to the actual spring array. Prior to the switch to TBB there was a single finalize callback which was called on the main thread, so it could use psys_sph_flush_springs and insert the new entries into the final buffer. However in D7394 it was replaced with a reduce callback, which is supposed to be thread safe and have no side effects. This means that the only thing it can safely do is copy entries to the other temporary buffer. In addition, careful checking reveals that the 'classical' solver doesn't actually add springs, so reduce isn't needed there. Differential Revision: https://developer.blender.org/D9632
2020-08-07Code Style: use "#pragma once" in source directoryJacques Lucke
This replaces header include guards with `#pragma once`. A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`), because they are used in other places. This patch has been generated by P1561 followed by `make format`. Differential Revision: https://developer.blender.org/D8466
2020-03-02Cleanup: make remaining blenlib headers work in C++Jacques Lucke
Differential Revision: https://developer.blender.org/D6988 Reviewers: brecht
2019-11-09Fluid Particles: fix threading crash with viscoelastic springs.Alexander Gavrilov
As correctly pointed out by a comment in the code, adding new springs wasn't thread safe, and caused crashes. Fix by buffering new springs in intermediate thread-local arrays, which are flushed on the main thread. This is valid because the new springs are not used until the next sim step. Differential Revision: https://developer.blender.org/D6133
2019-05-23Cleanup: allow BLI_Buffer to be used without it's headerCampbell Barton
Without this any functions declared that take BLI_Buffer also needed to include the header.
2019-04-17ClangFormat: apply to source, most of internCampbell Barton
Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-02-18doxygen: add newline after \fileCampbell Barton
While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-06Cleanup: remove redundant doxygen \file argumentCampbell Barton
Move \ingroup onto same line to be more compact and make it clear the file is in the group.
2019-02-01Cleanup: remove redundant, invalid info from headersCampbell Barton
BF-admins agree to remove header information that isn't useful, to reduce noise. - BEGIN/END license blocks Developers should add non license comments as separate comment blocks. No need for separator text. - Contributors This is often invalid, outdated or misleading especially when splitting files. It's more useful to git-blame to find out who has developed the code. See P901 for script to perform these edits.
2018-02-01Cleanup: rename BLI_*_empty() -> clear()Campbell Barton
Consistent with other BLI API's
2015-12-23Remove BLI_buffer calloc optionCampbell Barton
This wasn't working reliably (after clear for example), and wasn't used anywhere.
2015-10-04Correct last commit, picky type warningsCampbell Barton
2015-10-04BLI_Buffer: add BLI_buffer_reinitCampbell Barton
Useful for re-using a buffer when the existing data can be thrown away.
2015-10-04BLI_Buffer: support over 2gb allocationsCampbell Barton
Also move comment to C-source and enumerate useful features.
2015-02-14cleanup: doxy commentsCampbell Barton
2014-10-10BLI_buffer: empty macroCampbell Barton
2013-09-12code cleanup: headers - doxy comments.Campbell Barton
2013-08-07code cleanup: more confusion with 0/NULL/falseCampbell Barton
2013-07-26fix for error in BLI_buffer_declare_static(), the stack variable wasn't the ↵Campbell Barton
right size, from original commit 53440. Caused UV stretch display to fail.
2013-03-16changes to BLI_bufferCampbell Barton
- assert if BLI_buffer_at() is called with an out of bounds value. - add BLI_buffer_resize_data() macro which resizes and returns a pointer to the new array. - warn if missing call to BLI_buffer_free().
2013-01-02add assert to BLI_buffer_at if a type is given different to 'elem_size'Campbell Barton
2013-01-02extend BLI_bufferCampbell Barton
- add option to calloc or not, existing code wasnt consistent here, would calloc on first alloc but not on realloc, also - the static memory was never zero'd. use flag BLI_BUFFER_USE_CALLOC to ensure all new memory is zero'd (static/alloc/realloc's). - add BLI_buffer_declare_static / BLI_buffer_declare so its possible to have a buffer that never uses static memory.
2012-12-30Add BLI_buffer, an alternative to BLI_arrayNicholas Bishop
BLI_buffer is a dynamic homogeneous array similar to BLI_array, but it allocates a structure that can be passed around making it possible to resize the array outside the function it was declared in.