| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Currently strings are used for cases where a list of identifiers would
be useful to show.
Add support for string properties to reference a callback to populate
candidates to show when editing a string. The user isn't prevented from
typing in text not found in this list, it's just useful as a reference.
Support for expanding the following strings has been added:
- Operator, menu & panel identifiers in the keymap editor.
- WM operators that reference data-paths expand using the
Python-consoles auto-complete functionality.
- Names of keying sets for insert/delete keyframe operators.
Details:
- `bpy.props.StringProperty` takes an option `search` callback.
- A new string callback has been added, set via
`RNA_def_property_string_search_func` or
`RNA_def_property_string_search_func_runtime`.
- Addresses usability issue highlighted by T89560,
where setting keying set identifiers as strings isn't practical.
- Showing additional right-aligned text in the search results is
supported but disabled by default as the text is too cramped in most
string search popups where the feature would make sense. It could be
enabled as part of other layout tweaks.
Reviewed By: brecht
Ref D14986
|
|
This commit makes PointerRNA passed to RNA path API const.
Main change was in the `path` callback for RNA structs, and indirectly
the `getlength` callback of properties.
|
|
- Missing star prefix.
- Unnecessary indentation.
- Blank line after dot-points
(otherwise doxygen merges with the previous dot-point).
- Use back-slash for doxygen commands.
- Correct spelling.
|
|
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
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
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
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
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
|
|
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
There are cases where there is no way to ensure we do have/know about an
active scene. Further more, this should not be required to perform
'real' updates on data, only to perform additional special handling in
current scene (mostly related to editing tools, UI, etc.).
This pointer is actually almost never used in practice, and half of its current
usages are fairly close to abuse of the system (like calls to
`ED_gpencil_tag_scene_gpencil` or `BKE_rigidbody_cache_reset`).
This commit ensures that the few places using this 'active scene' pointer are
safely handling the `NULL` case, and clearly document the fact that a
NULL scene pointer is valid.
|
|
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
|
|
This adds id_properties_clear() and id_properties_ensure() functions
to RNA structs. This is meant as an initial change based on discussion
in review of D9697. However, they may be useful in other situations.
The change requires refactoring the internal idproperties callback to
return a pointer to the IDProperty pointer, which actually turns out
to be quite a nice cleanup.
An id_properties attribute could be added in the future potentially.
Differential Revision: https://developer.blender.org/D11908
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
This patch introduces non linear sliders. That means, that the movement
of the mouse doesn't map linearly to the value of the slider.
The following changes have been made.
- Free logarithmic sliders with maximum range of (`0 <= x < inf`)
- Logarithmic sliders with correct value indication bar.
- Free cubic sliders with maximum range of (`-inf < x < inf`)
- Cubic sliders with correct value indication bar.
Cubic mapping has been added as well, because it's used for brush sizes
in other applications (Krita for e.g.).
To make a slider have a different scale type use following line in RNA:
`RNA_def_property_ui_scale_type(prop, PROP_SCALE_LOGARITHMIC);`
or:
`RNA_def_property_ui_scale_type(prop, PROP_SCALE_CUBIC);`
Test the precision, step size and soft-min if you change the scale type
of a property as it will feel very different and may need tweaking.
Ref D9074
|
|
Callbacks used in `bpy.props` didn't hold a references to the functions
they used.
While this has been the case since early 2.5x it didn't cause any
problems as long as the class held a reference.
With Python 3.10 or when using `from __future__ import annotations`,
the annotations are no longer owned by the class once evaluated.
Resolve this by holding a reference in the module, which now supports
traverse & clear callbacks so the objects are visible to Python's
garbage collector.
Also refactor storage of Python data, moving from an array into a struct.
|
|
Use _fn as a suffix for callbacks.
|
|
Document some of the less obvious implications for
re-using Python instances.
|
|
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
|
|
The triplet static RNA / runtime RNA / custom properties is a real pain to
deal with...
Using the new `PropertyRNAOrID` struct helps clarifying and properly
dealing with all three cases.
Note that this makes override of py-defined RNA properties working
(support for that will be committed next).
Differential Revision: https://developer.blender.org/D8249
|
|
Introduce new PropertyRNAOrID structure, storing most useful data about
an 'opaque' PropertyRNA in relation with a given PointerRNA struct.
It deals with all the three cases (pure static RNA, runtime RNA where
data is actually stored in IDProperties, and pure IDProperties, aka
custom data.
|
|
pointer properties.
Since makesrna runs after all properties have been defined, we have to
remember with a new internal flag when we explicitely disable the
'PROP_PTR_NO_OWNERSHIP' flag for a property.
Otherwise there was no way to do so for ID pointer properties...
|
|
By using own path construction instead of handy printf-like functions,
we get a 10% improvement on overall diffing process!
This remains way to slow on some complex production characters, but
always good to have still.
|
|
RE_engine_register_pass is sometimes in the headers with type
as an integer parameter, sometimes as eNodeSocketDatatype.
This caused warnings, the root cause was makesrna was not able
to generate the proper type for enums and defaulted to int.
makesrna has been extended with the RNA_def_property_enum_native_type
that allows telling makesrna the native type of an enum, if set it
will be used otherwise it will still fall back to int.
Differential Revision: https://developer.blender.org/D7117
Reviewed By: brecht
|
|
|
|
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
|
|
|
|
Comments after code can cause awkward line breaks.
|
|
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
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
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.
|
|
Done using:
source/tools/utils_maintenance/c_sort_blocks.py
|
|
|
|
|
|
|
|
We were using int's for bool arguments in BKE,
just to avoid having wrapper functions.
|
|
Access to main database is actually rarely needed, but some custom
'apply' functions do need it (like Collections' overriding of objects or
children collections).
|
|
This is unused currently, but is mandatory for incomming support to
Collections objects and children items override support.
|
|
We are already running out of available flags in main, generic int, and
everytime I work on static override I find new special cases that will
need new specific propflag, so...
|
|
Code also handling auto-generation of static overrides.
Aside from some naming consistency cleanup, this commit:
* Is the first step addressing the 'operator' issue with static
overrides, by implementing a first version of the 'restore from
reference' behavior.
* Fixes several issues that were discovered on the way in enhanced
RNA comparision code, like the 'zero-length dynamic array' case, or some
infinite looping caused by some non-ID pointers (that for some
mysterious reasons did not show up previously...).
* Factorizes a bit said RNA comparison code (auto-static override
generation and comparison/check were essentially doing the same thing).
|
|
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
|
|
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
|
|
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
Actual usage of this will be added in a follow-up commit.
|
|
|
|
Practically all access to enum data is read-only.
|
