Commit Graph

34 Commits

Author SHA1 Message Date
Campbell Barton e955c94ed3 License Headers: Set copyright to "Blender Authors", add AUTHORS
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.

While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.

Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.

Some directories in `./intern/` have also been excluded:

- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.

An "AUTHORS" file has been added, using the chromium projects authors
file as a template.

Design task: #110784

Ref !110783.
2023-08-16 00:20:26 +10:00
Jacques Lucke 129f78eee7 Blenkernel: move to C++
Also see #103343.

Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
  conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.

Pull Request: https://projects.blender.org/blender/blender/pulls/110182
2023-07-17 10:46:26 +02:00
Sergey Sharybin c1bc70b711 Cleanup: Add a copyright notice to files and use SPDX format
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.

This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.

Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.

Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:

    https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
Campbell Barton c434782e3a File headers: SPDX License migration
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-02-11 09:14:36 +11:00
Clément Foucault fb6bd88644 Revert "BLI: Refactor vector types & functions to use templates"
Includes unwanted changes

This reverts commit 46e049d0ce.
2022-01-12 12:50:02 +01:00
Clment Foucault 46e049d0ce 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:47:43 +01:00
Clément Foucault e5766752d0 Revert "BLI: Refactor vector types & functions to use templates"
Reverted because the commit removes a lot of commits.

This reverts commit a2c1c368af.
2022-01-12 12:44:26 +01:00
Clément Foucault a2c1c368af 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 @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-12 12:19:39 +01:00
Campbell Barton 0dc309bef6 Cleanup: remove redundant const qualifiers for POD types 2022-01-12 12:51:11 +11:00
Campbell Barton 9e365069af Cleanup: move public doc-strings into headers for 'blenlib'
- 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-12-09 20:01:44 +11:00
Campbell Barton f1e4903854 Cleanup: full sentences in comments, improve comment formatting 2021-06-26 21:50:48 +10:00
Alexander Gavrilov 02a0f6b04a Fluid Particles: fix viscoelastic spring threading crash again after D7394.
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-11-25 22:31:47 +03:00
Jacques Lucke 91694b9b58 Code Style: use "#pragma once" in source directory
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-08-07 09:50:34 +02:00
Jacques Lucke cf93b65a65 Cleanup: make remaining blenlib headers work in C++
Differential Revision: https://developer.blender.org/D6988

Reviewers: brecht
2020-03-02 15:05:15 +01:00
Alexander Gavrilov dca32f2b4f Fluid Particles: fix threading crash with viscoelastic springs.
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-11-09 13:44:43 +03:00
Campbell Barton a521ad7568 Cleanup: allow BLI_Buffer to be used without it's header
Without this any functions declared that take BLI_Buffer
also needed to include the header.
2019-05-23 16:32:58 +10:00
Campbell Barton e12c08e8d1 ClangFormat: apply to source, most of intern
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-04-17 06:21:24 +02:00
Campbell Barton de13d0a80c doxygen: add newline after \file
While \file doesn't need an argument, it can't have another doxy
command after it.
2019-02-18 08:22:12 +11:00
Campbell Barton eef4077f18 Cleanup: remove redundant doxygen \file argument
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
2019-02-06 15:45:22 +11:00
Campbell Barton 65ec7ec524 Cleanup: remove redundant, invalid info from headers
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.
2019-02-02 01:36:28 +11:00
Campbell Barton 078e012cd9 Cleanup: rename BLI_*_empty() -> clear()
Consistent with other BLI API's
2018-02-01 13:40:53 +11:00
Campbell Barton b9dea0f941 Remove BLI_buffer calloc option
This wasn't working reliably (after clear for example), and wasn't used anywhere.
2015-12-24 01:52:54 +11:00
Campbell Barton 5884a0d66e Correct last commit, picky type warnings 2015-10-04 15:11:38 +11:00
Campbell Barton 74a2fa3095 BLI_Buffer: add BLI_buffer_reinit
Useful for re-using a buffer when the existing data can be thrown away.
2015-10-04 14:29:27 +11:00
Campbell Barton 9f046e95c0 BLI_Buffer: support over 2gb allocations
Also move comment to C-source and enumerate useful features.
2015-10-04 14:10:26 +11:00
Campbell Barton 2af905391d cleanup: doxy comments 2015-02-14 08:00:41 +11:00
Campbell Barton 642c8243e7 BLI_buffer: empty macro 2014-10-10 10:10:13 +02:00
Campbell Barton 8beb565c59 code cleanup: headers - doxy comments. 2013-09-12 03:02:50 +00:00
Campbell Barton 00b39c4e5b code cleanup: more confusion with 0/NULL/false 2013-08-07 03:55:21 +00:00
Campbell Barton e3f6875df0 fix for error in BLI_buffer_declare_static(), the stack variable wasn't the right size, from original commit 53440.
Caused UV stretch display to fail.
2013-07-26 15:26:51 +00:00
Campbell Barton 1b994dbeb0 changes to BLI_buffer
- 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-03-16 00:12:14 +00:00
Campbell Barton 0d95dde79b add assert to BLI_buffer_at if a type is given different to 'elem_size' 2013-01-02 05:19:55 +00:00
Campbell Barton 9190c493c1 extend BLI_buffer
- 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.
2013-01-02 05:00:02 +00:00
Nicholas Bishop 2c9d22fe31 Add BLI_buffer, an alternative to BLI_array
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.
2012-12-30 18:28:10 +00:00