The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
BGL is deprecated and will not work on Metal devices. Although the
inital plan was to remove it in Blender 4.0, We don't see any harm
to still have it in the code-base until OpenGL itself is deprecated.
Add-on developers are warned when using the BGL module that the
add-on/script will not work on all platforms.
There are still some limitations inside the GPU module that needs
a more friendly API. This API isn't clear at this time.
Pull Request: https://projects.blender.org/blender/blender/pulls/112579
Replacing PyErr_Print with PyErr_Display in [0] caused string errors
not to display because PyErr_Display doesn't normalize the exception.
Normalizing before displaying the error resolves this.
[0]: 6a0f98aeef
Some of the comments for exiting were outdated & vague.
Add additional comments to clarify out SystemExit, sys.exit() & atexit
are used to handle exit requests from Python within Blender.
Non-matching calls to PyErr_Fetch/Restore cause a leak in v3.12,
so ensure calls are symmetrical or avoid where possible.
Simplify extraction of the exception buffer.
- Only overwrite the stderr (the stdio isn't used).
- Simplify pyc_exception_buffer_handle_system_exit usage.
- Remove goto's.
Also simplify calling conventions for PyC_ExceptionBuffer functions.
- They must be called when an error has occurred.
- Always return a string, never null since a null return value would
only happened in rare/unexpected cases which wasn't being checked
for by some callers, leading to potential crashes.
The internals of PyErr_Print/PyErr_Display & the traceback module
are different enough that it's not likely the Python traceback
implementation will be used.
While in practice sys.modules has __main__ module, the purpose of
PyC_MainModule_Backup/Restore is to temporarily override __main__.
Running code outside of the text editor (callbacks for timers for e.g.)
could remove the __main__ module which would then crash when running
a script from the text editor.
- Account for new member in _PyArg_Parser.
- Many Python op-codes have been removed.
For the moment these are disabled in is_opcode_secure.
Some should be added back as intrinsics, noted in code-comments.
New code exposing ID Pointers CustomProperties to the UI (b3c7f3c8a9)
would cause invalid data access when calling `as_dict()` on py-defined ID
pointers ID properties, since these have no ID type defined by default.
The code of `as_dict()` will now forcefully generate a valid ID type
value, either by using the type of the currently assigned ID, or falling
back to the Object ID type.
Found while opening some lighting production files from the Pets
Project.
Customprops to IDs are supported since years through code, but were
never exposed directly in the UI of customporperties.
This commit mainly:
* Adds a new `DATA_BLOCK` type to UI customprops types.
* Exposes the existing `id_type` settings to python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110458
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.
Use PyC_ParseUnicodeAsBytesAndSize parser instead of "s" / "z" type
specifier. This relates to #111033, resolving Python exceptions which
causes icons not to load (for e.g.).
Now bytes are also supported as path arguments.
Expose PyC_UnicodeAsBytesAndSize using a parser which PyArg_ParseTuple
can use. This should be used with PyArg_ParseTuple instead of "s" type
specifier when passing in file-system path arguments.
PyC_ParseUnicodeAsBytesAndSize_OrNone has been included to match "z".
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
The Python API uses the term size for string lengths for
PyUnicode_AsUTF8AndSize and related API's, causing Blender's return
arguments to use the term `size` too in some cases.
This is error prone since Blender includes space from the the null byte
when the term size is used (by convention).
PyUnicode_AsUTF8AndSize is used when renaming a custom python property,
this method stores the size of the string without including the null
terminator in the size.
Renaming a custom python property now includes the null terminator when
copying the new string name.
Pull Request: https://projects.blender.org/blender/blender/pulls/107983
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/
