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/
When a file passed in from the command line failed to load,
blender would exit & save the quit.blend.
Resolve by adding a `do_user_exit_actions` to WM_exit_ex which is
false in backgrounds mode or when an error has occurred.
---
Back-ported [0] & [1] from main with fix [2] included.
[0]: c803ddab29
[1]: d7d1c524e3
[2]: d3d91b79e0
When a file passed in from the command line failed to load,
blender would exit & save the quit.blend.
Resolve by adding a `do_user_exit_actions` to WM_exit_ex which is
false in backgrounds mode or when an error has occurred.
This would print whenever 'bpy' was imported, because in this case
Blender's Python integration loads all modules immediately because it
can't import modules as needed via the inittab mechanism.
Also correct code-comments for why inittab can't be used.
Optionally extract all help text, even for options not available
on the current platform or with the current build options.
Useful so it's possible to extract help text for the user-manual
which doesn't depend on the blender build used for extraction.
This hard-coded assumption meant that operators would behave as if
bl_property = "type" was assigned in the operator - when the variable
wasn't found.
Remove the hard coded name. Operators that depended on this now need
to assign bl_property = "type" in the operator class explicitly.
Remove this because it wasn't documented as means operator behavior
could change unexpectedly when renaming a property.
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
Some property labels need a context to disambiguate them from others
which have the same name.
The only way to show the proper text currently for such properties is
to override it in the UI code with a translation context, like:
```python
layout.prop(obj, "area", text="Area",
context=i18n_contexts.amount)
```
Python properties already store a translation context though, but this
context cannot be chosen from a Python script.
For instance, typing:
```python
bpy.types.Scene.test_area = bpy.props.BoolProperty(name="Area")
print(bpy.context.scene.bl_rna.properties['test_area'].translation_context)
```
will print `*`, the default context for Python props.
This commit allows specifying a context in this manner:
```python
from bpy.app.translations import contexts as i18n_contexts
bpy.types.Scene.test_number_area = bpy.props.BoolProperty(
name="Area", translation_context=i18n_contexts.amount
)
print(bpy.context.scene.bl_rna.properties['test_number_area'].translation_context)
```
will now print `Amount` and can be translated differently from other
labels. In this instance, the word for a surface area measurement,
instead of a UI area.
-----
This is what translated properties look like using the existing ("Area", "") and ("Area", "Amount") messages:
The panel can be generated with this script:
[python_prop_contexts_test.py](/attachments/ab613cdc-8eba-46bc-8f3c-ad0a97e7a6e5)
Pull Request: https://projects.blender.org/blender/blender/pulls/107150
Add a ensure_utf8 argument to WM_clipboard_text_get so callers don't
have to handle validation themselves.
Copying non-utf8 text into the Python console and buttons was possible,
causing invalid cursor position and a UnicodeDecodeError accessing
ConsoleLine.body from Python.
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
- "... (matches pythons ...)": capitalize and use possessive ('s).
- "Layer Proxy Protection": replace proxy by override, following 2.80.
- "Enable Plane Trim": expand description.
- "Make curve path children to rotate along the path": remove "to".
- "Option for curve-deform: make deformed child to stretch along
entire path": remove "to".
- "... apply the curve radius with path following it and deforming":
rephrase unclear description.
- "Custom light falloff curve" : unrelated to lights, used in Grease
Pencil modifiers.
- "Grease Pencil layer assigned to the generated strokes": rephrase
because a GP stroke is assigned to a layer, not the other way
around.
- "Attribute domain where the attribute domain is stored in the
simulation state": remove second "domain" (typo).
Pull Request: https://projects.blender.org/blender/blender/pulls/107916
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
A recent change from [0] added an assert when a string lookup was
performed on a collection item with no name-property,
but silently failed with release builds.
This isn't correct in a couple of ways.
The assert makes it seem like the RNA API needs to be updated when
it's in fact valid to have collection items without a name-property.
It also misleads script authors to silently fail since it implies a
key that exists would return a result.
Raise a TypeError exception when string lookups are attempted on
collections that don't support them.
This change also applies to get() & __contains__().
[0]: 5bb3a3f157
These two didnt check if keywords were passed in, crashed on running
`PyDict_GET_SIZE` on NULL (in case of no keywords).
Oversight in ee292a1d66.
Now just check if keywords are actually passed in.
Pull Request: https://projects.blender.org/blender/blender/pulls/107285
This happens when the collection's item type doesn't have a
'nameproperty' to index with. For debug builds we error out with an
assert, since in general this shouldn't happen. For release builds
Python will report item not found.
Pull Request: https://projects.blender.org/blender/blender/pulls/107086
`PyObject_GetBuffer` was used without checking that it was successful.
This could cause the code to access an incompatible or uninitialized
`Py_buffer`.
Add the missing checks, and clears the raised `PyExc_BufferError`
to silently fall back to accessing the PyObject as a sequence.
This is the case e.g. of the `parent` collection pointer of collections
children of a scene's master collection, or some nodetree pointers in
the UI data (node editor).
Right now handling of this new flag is exactly the same as in owning
embedded case, the distiction between both usages will happen in future
commits.
This commit is expected to have no behavioral change at all.
This checkin will use OIIO to replace the image save/load code for BMP,
DDS, DPX, HDR, PNG, TGA, and TIFF.
This simplifies our build environment, reduces binary duplication,
removes large amounts of hard to maintain code, and fixes some bugs
along the way.
It should also help reduce rare differences between Blender and Cycles
which already uses OIIO for most situations. Or potentially makes them
easier to solve once discovered.
This is a continuation of the work for #101413
Pull Request: https://projects.blender.org/blender/blender/pulls/105785
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
Now only dynamic function parameters that use ParameterDynAlloc support
dynamically sized parameters arrays.
Add tests for both dynamic arrays that don't support resizing
(Image.pixels) and dynamic sized arguments using
(VertexGroup.add(index=[..])).
Regression in [0] which extended support for dynamic sized function
arguments.
[0]: dfb8c5974e
The C4100 warning is related to unused formal parameters in functions.
Enabling it better aligns with "-Wunused-parameter" option in other
compilers.
While suppressing it with `__pragma(warning(suppress:4100))` is not the
same as using `__attribute__((__unused__))` in GCC or Clang, it is
still preferable to use it over completely hiding the warning.
This ensures consistent warning behavior across compilers and improves
code quality by addressing unused function parameters.
(Note that some warnings in Windows-specific code have already been
silenced in 7fcb262dfd)
Pull Request: https://projects.blender.org/blender/blender/pulls/105534
Add a filepath argument to load/save pre/post.
Also add save_post_failed and load_post_failed handlers so it's always
possible to for the pre handlers to run a matching post action.
This makes it possible to know the filepath of the blend file mean
loaded/saved as well as supporting running an action when load/save
operations fail.
When loading and saving the startup-file, the path argument is set to
an empty string.
Details:
New RNA types were added to support storing primitive values in
PointerRNA. Primitive{String/Int/Float/Boolean}RNA. These will likely
only be used in some limited cases, in the case of BKE_callback_exec it
allows strings to be included as part of the PointerRNA **pointers
argument.
Ref !104769.
Drivers: Introduce the Context Properties
The goal: allow accessing context dependent data, such as active scene camera
without linking to a specific scene data-block. This is useful in cases when,
for example, geometry node setup needs to be aware of the camera position.
A possible work-around without changes like this is to have some scene
evaluation hook which will update driver variables for the currently evaluating
scene. But this raises an issue of linking: it is undesirable that the asset
scene is linked to the shot file.
Surely, it is possible to have post-evaluation handler to clear the variables,
but it all starts to be quite messy. Not to mention possible threading
conflicts.
Another possibility of introducing a way to achieve the goal is to make it so
the dependency graph somehow parses the python expression where artists can
(and already are trying to) type something like:
depsgraph.scene.camera.matrix_world.col[3][0]
But this is not only tricky to implement properly and reliably, it hits two
limitations:
- Currently dependency graph can only easily resolve dependencies to a RNA
property.
- Some properties access which are valid in Python are not considered valid
RNA properties by the existing property resolution functions:
`camera.matrix_world[3][0]` is a valid RNA property, but
`camera.matrix_world.col[3][0]` is not.
Using driver variables allows to have visual feedback when the path resolution
fails, and there is no way to visualize errors in the python expression itself.
This change introduces the new variable type: Context Property. Using this
variable type makes allows to choose between Active Scene and Active View
Layer. These scene and view layer are resolved during the driver evaluation
time, based on the current dependency graph.
This allows to create a driver variable in the following configuration:
- Type: Context Property
- Context Property: Active Scene
- Path: camera.matrix_world[3][0]
The naming is a bit confusing. Tried my best to keep it clear keeping two
aspects in mind: using UI naming when possible, and follow the existing
naming.
A lot of the changes are related on making it so the required data is available
from the variable evaluation functions. It wasn't really clear what the data
would be, and the scope of the changes, so it is done together with the
functional changes.
It seems that there is some variable evaluation logic duplicated in the
`bpy_rna_driver.c`. This change does not change it. It is not really clear why
this separate code path with much more limited scope of supported target types
is even needed.
There is also a possible change in the behavior of the dependency graph: it
is now using ID of the resolved path when building driver variables. It used
to use the variable ID. In common cases they match, but when going into nested
data-blocks it is actually correct to use relation to the resolved ID. Not sure
if there was some code to ensure that, which now can be resolved. Also not sure
whether it is still needed to ensure the ID specified in the driver target is
build as well. Intuitively it is not needed.
Pull Request #105132
New (experimental) Stanford PLY importer and exporter written in C++.
Handles: vertices, faces, edges, vertex colors, normals, UVs. Both
binary and ASCII formats are supported.
Usually 10-20x faster than the existing Python based PLY
importer/exporter.
Additional notes compared to the previous Python addon:
- Importing point clouds with vertex colors now works
- Importing PLY files with non standard line endings
- Exporting multiple objects (previous exporter didn't take the vertex
indices into account)
- The importer has the option to merge vertices
- The exporter supports exporting loose edges and vertices along with
UV map data
This is squashed commit of PR #104404
Reviewed By: Hans Goudey, Aras Pranckevicius
Co-authored-by: Arjan van Diest
Co-authored-by: Lilith Houtjes
Co-authored-by: Bas Hendriks
Co-authored-by: Thomas Feijen
Co-authored-by: Yoran Huzen
