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.
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/
Currently when converting from the legacy curve type to the new type,
which happens during evaluation of every legacy curve object, the
`CurveEval` type is used as an intermediate step. This involves
copying all data twice, and allocating a bunch of temporary arrays.
It's also another use of `CurveEval` that has to be removed before
we remove the type.
The main user difference besides the subtlety described below
will be improved performance.
**Invalid Handles and Types**
One important note is that there are two cases (that I know of)
where handles and handle types can be invalid in the old curve
type. The first is animation, where animated handle positions don't
necessary respect the types. The second is control points with a
single aligned handle that didn't necessarily align with the other.
In master (partially on purpose) the code corrects the first situation
(which caused T98965). But it doesn't correct the second situation.
It's trivial to correct for the second case with this patch (because of the
eager calculation decided on in D14464), but this patch makes the choice
not to correct for //either//.
Though not correcting the handle types puts curves in an invalid state,
it also adds flexibility by allowing that option. Users must understand
that any deformation may correct invalid handles.
Fixes T98965
Differential Revision: https://developer.blender.org/D15290
Campbell Barton
Sergey Sharybin
Hans Goudey