| Age | Commit message (Collapse) | Author |
|---|
|
Define enum `eContextResult` and use its values for returns, instead of
just returning 1, 0, or -1 (and always having some comment that explains
what -1 means).
This also cleans up the mixup between returning `0` and `false`, and `1`
and `true`. An inconsistency was discovered during this cleanup, and
marked with `TODO(sybren)`. It's not fixed here, as it would consititute
a functional change.
The enum isn't used everywhere, as enums in C and C++ can have different
storage sizes. To prevent issues, callback functions are still declared
as returning`int`. To at least make things easier to understand for
humans, I marked those with `int /*eContextResult*/`.
This is a followup of D9090, and is intended to unify how context
callbacks return values. This will make it easier to extend the approach
in D9090 to those functions.
No functional changes.
Differential Revision: https://developer.blender.org/D9095
|
|
|
|
See
https://www.sphinx-doc.org/en/master/usage/restructuredtext/domains.html#info-field-lists
|
|
Following the most widely used convention for including todo's in
the code, that is: `TODO(name):`, `FIXME(name)` ... etc.
|
|
Printing an evaluated view layer would show:
Evaluated Scene 'Scene'
- Now __repr__ uses the __str__ fallback for evaluated data,
as done in other situations where we can't create a string that
would evaluate to the data.
- __str__ now shows when the data is evaluated.
- __str__ always includes the memory address
(which was previously only shown for structs without a name).
|
|
No functional changes.
|
|
Add back this function, removed 2e14b7fb9770b.
Useful for checking operators used in menus.
|
|
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/python` module.
No functional changes.
|
|
|
|
Using 'name' for the full path of a file reads badly,
especially when id.name is used in related code.
|
|
Previously the static/class flag was ignored,
always using class methods.
|
|
|
|
Support extending properties as well as methods.
|
|
This isn't so closely related to the RNA API,
it's a way to use the C/Python API to extend RNA types
and can be in it's own file.
|
|
Makes it more clear that code using this is related to the RNA
integration of a type.
Part of T74432.
Also ran clang-format on affected files.
|
|
Also pass some args as 'const'.
|
|
Mpving utils from idcode to idtype proved to be somewhat painful for
some reasons, but now all looks good.
Had to add a fake/empty shell for the special snowflake too,
`ID_LINK_PLACEHOLDER/INDEX_ID_NULL`...
|
|
|
|
This allows fast access to various arrays in the Python API.
Most notably, `image.pixels` can be accessed much more efficiently now.
**Benchmark**
Below are the results of a benchmark that compares different ways to
set/get all pixel values. I do the tests on 2048x2048 rgba images.
The benchmark tests the following dimensions:
- Byte vs. float per color channel
- Python list vs. numpy array containing floats
- `foreach_set` (new) vs. `image.pixels = ...` (old)
```
Pixel amount: 2048 * 2048 = 4.194.304
Byte buffer size: 16.8 mb
Float buffer size: 67.1 mb
Set pixel colors:
byte - new - list: 271 ms
byte - new - buffer: 29 ms
byte - old - list: 350 ms
byte - old - buffer: 2900 ms
float - new - list: 249 ms
float - new - buffer: 8 ms
float - old - list: 330 ms
float - old - buffer: 2880 ms
Get pixel colors:
byte - list: 128 ms
byte - buffer: 9 ms
float - list: 125 ms
float - buffer: 8 ms
```
**Observations**
The best set and get speed can be achieved with buffers and a float image,
at the cost of higher memory consumption. Furthermore, using buffers when
using `pixels = ...` is incredibly slow, because it is not optimized.
Optimizing this is possible, but might not be trivial (there were multiple
attempts afaik).
Float images are faster due to overhead introduced by the api for byte images.
If I profiled it correctly, a lot of time is spend in the `[0, 1] -> {0, ..., 255}`
conversion. The functions doing that conversion is `unit_float_to_uchar_clamp`.
While I have an idea on how it can be optimized, I do not know if it can be done
without changing its functionality slightly. Performance wise the best solution
would be to not do this conversion at all and accept byte input from the api
user directly, but that seems to be a more involved task as well.
Differential Revision: https://developer.blender.org/D7053
Reviewers: JacquesLucke, mont29
|
|
'Private' can be a rather confusing term, especially when considering
its meaning in programming languages.
So now root node trees and master collections are 'embedded' IDs
instead.
|
|
|
|
|
|
Logic for registering and checking properties of registrable classes was
broken, allowing to ignore some errors.
Recent fix rBeb798de101a `broke` the result of the
pyapi_idprop_datablock test, because previously that test would fail
(i.e. suceed, as it is an 'expected to break test') for a reason it was
not designed to check.
This is the problem with that kind of tests - you cannot really check
that they are failing on the expected reason(s)...
|
|
Also correct some outdated symbol references,
add missing 'name' commands.
|
|
|
|
|
|
|
|
|
|
This commit solves the bug itself (code was broken when real_id owner of
the private data ID could not be found), and generates a more sensible
representation for all evaluated IDs, makes no sense to display them as
being part of `bpy.data....`!
|
|
|
|
|
|
Blender UI Layout API allows supplying parameters to operators via
button definitions. If an operator behavior strongly depends on its
parameters, it may be difficult to write a tooltip that covers all
of its operation modes. Thus it is useful to provide a way for the
operator to produce different descriptions based on the input info.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5709
|
|
We can now generate a proper path here, make use of it.
Note: not sure how property pyrna path is supposed to be accessed? code is
similar to the struct pyrna path anyway...
|
|
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
|
|
Helps debugging errors when classes are registered twice.
|
|
T68035 by @luzpaz
|
|
D5084 by @nBurn with edits
|
|
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
|
|
|
|
Most code uses ReportList argument last (or at least not first)
when an optional report list can be passed in.
|
|
The goal is to prevent assignment of temporary or evaluated meshes
to objects from the main database.
Majority of the change is actually related on passing reports around.
On a positive side there are more error prints which can become more
visible to scripters.
There are still possible further improvements in the related areas.
For example, disable user counting for evaluated ID datablocks when
assignment happens. But can also happen later on as a separate
improvement.
Reviewers: brecht, campbellbarton, mont29
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4884
|
|
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
|
|
Prepare for enabling ReflowComments.
|
|
|
|
|
|
Add a callback to allow custom node editors to draw their own
backdrop.
Differential Revision: https://developer.blender.org/D4709
Reviewed by: JacquesLucke
|
|
|
|
|
|
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
|
