| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Also some descriptive text into doc-strings.
|
|
Order copyright immediately after the license block,
this was done almost everywhere with a few exceptions.
Remove authors from a few files (we had already removed "Contributors"
section however with old patches being applied this gets added back in).
Also move descriptive text into the doxygen comment block under \file.
In some cases remove the text as it was accidentally copied.
|
|
Some items on the Quick Setup screen can be truncated with some
languages and/or with High DPI monitors. This patch adjusts column
sizes and turns off the expand on Spacebar options, making everything
fit a bit better.
See D9853 for more details.
Differential Revision: https://developer.blender.org/D9853
Reviewed by Julian Eisel
|
|
|
|
Also order items to match the "Add" menu.
|
|
The outliner selection can now be used for renaming objects,
object-data & materials.
|
|
|
|
|
|
Use selected objects collection instances to rename in the 3D view.
|
|
User must activate the operator from the outliner,
so that the selected collections can be determined.
Reviewed By: campbellbarton
Ref D13821
|
|
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
|
|
Change that was missing in {rBca64bd0aacda}.
|
|
The prop name was wrong.
|
|
This errored out in two scenarios:
- current frame not in strips framerange (this was reported)
- no strips selected at all
Now handle these cases properly in the operator and give appropriate
report info.
Maniphest Tasks: T94295
Differential Revision: https://developer.blender.org/D13642
|
|
|
|
Use the translation API to lookup the string before formatting occurs.
Differential Revision: https://developer.blender.org/D13400
|
|
In rBdcdbaf89bd11, I introduced a new operator
(`file.asset_library_refresh()`) to handle Asset Browser refreshing more
separate from File Browser refreshing. However, there already was
`asset.asset_list_refresh()`, which at this point only works for asset
view templates, but was intended to cover the Asset Browser case in
future too. This would happen once the Asset Browser uses the asset list
design of the asset view template.
So rather than having two operators for refreshing asset library data,
have one that just handles both cases, until they converge into one.
This avoids changes to the Python API in future (deprecating/changing
operators).
Differential Revision: https://developer.blender.org/D13239
|
|
In rBdcdbaf89bd11, I introduced a new operator
(`file.asset_library_refresh()`) to handle Asset Browser refreshing more
separate from File Browser refreshing. However, there already was
`asset.asset_list_refresh()`, which at this point only works for asset
view templates, but was intended to cover the Asset Browser case in
future too. This would happen once the Asset Browser uses the asset list
design of the asset view template.
So rather than having two operators for refreshing asset library data,
have one that just handles both cases, until they converge into one.
This avoids changes to the Python API in future (deprecating/changing
operators).
Differential Revision: https://developer.blender.org/D13239
|
|
Followup to https://developer.blender.org/D10288
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D10346
|
|
|
|
Refreshing the assets requires `file_OT_asset_library_refresh` in the
asset browser, and `asset_OT_list_refresh` for the asset view. Both
are now done from `ASSET_OT_open_containing_blend_file`.
|
|
|
|
Even never-shown RNA properties should have at least a description, as
this is used by API doc generation scripts.
NOTE: this is more of an opportunistic set of changes than a proper
complete fix of that loack of documentation.
|
|
The preset menu name was not renamed in 4ddad5a7ee5d.
|
|
The preset menu name was not renamed in 4ddad5a7ee5d.
|
|
|
|
|
|
This was only needed for skipping version numbers when the numbering
scheme changed for 3.0.
|
|
|
|
This patch makes the layout of the custom property panel more coherent
with the rest of the property editor interface, makes it less busy,
allows more space for the buttons for the actual properties, and
simplifies editing values of unsupported property types or long arrays.
- Remove the box around each property.
- Use an non-embossed X icon for deleting.
- Use an "edit" icon instead of the text for the meta-data edit operator.
The "gear" icon used for editing isn't ideal here.
- Increase the max array length for drawing the values directly to 8.
- Add an "Edit Property Value" operator for dictionaries or longer arrays.
- Replace the "Library Override" text with an icon.
- Use a proper split factor, the same as the rest of the UI.
Differential Revision: https://developer.blender.org/D12805
|
|
|
|
|
|
Use "Tag" instead of "Unnamed Tag" as default name for tags. Other default
names in Blender also don't add "Unnamed" or similar.
|
|
URL presets weren't working, raising a Python exception
when the splash screen was displayed.
|
|
This fixed an error in a corner case, and is a reasonable check anyway.
|
|
- Fix a typo that used the max instead of the min for the soft max
- Assign the correct "last property type" when the operator starts
- Only check values for the soft range when use soft range is turned on
|
|
Following operators now only report messages back when they are called via their invoke-methods:
- ANIM_OT_keyframe_insert
- ANIM_OT_keyframe_insert_by_name
- ANIM_OT_keyframe_insert_menu
- ANIM_OT_keyframe_delete
- ANIM_OT_keyframe_clear_v3d
- ANIM_OT_keyframe_delete_v3d
Also removed the attribute confirm_success from the following operators:
- ANIM_OT_keyframe_insert
- ANIM_OT_keyframe_insert_by_name
- ANIM_OT_keyframe_insert_menu
- ANIM_OT_keyframe_delete
- ANIM_OT_keyframe_delete_by_name
Note: addons/scripts possibly need to be updated if they use the above operators AND set the "confirm_success" attribute
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12697
|
|
Buttons to edit asset metadata are now disabled for assets from an
external library (i.e. assets not stored in the current .blend file).
Their tooltips explain why they are disabled.
Had to do some RNA trickery to disable the metadata properties at RNA
level, not at UI script level.
The basic idea is:
* Local data-block assets set the data-block as owning ID for the asset
metadata RNA pointer now.
* That way we can use the owner ID to see where the metadata belongs to
and decide if it's editable that way.
* Additionaly, some Python operators needed better polling so they show
as grayed out, and don't just fail.
One important thing: Custom properties of the metadata can still be
edited. The edits won't be saved however. Would be nice to disable that,
but it's currently not supported on BPY/IDProperty/RNA level.
Addresses T82943.
Differential Revision: https://developer.blender.org/D12127
|
|
This commit changes the custom property edit operator to make editing
different properties types more obvious and expose more of the data,
made more easily possible by the recent UI data refactor.
Previously, the operator guessed the type you wanted based on what you
wrote in a text box. That was problematic, you couldn't make a string
property with a value of `1234`, and you had to know about the Python
syntax for lists in order to create an array property. It was also slow
and error prone; it was too easy to make a typo.
Improvements compared to the old operator:
- A type drop-down to choose between the property types.
- Step and precision values are exposed.
- Buttons that have the correct type based on the property.
- String properties no longer display min, max, etc. buttons.
- Generally works in more cases. The old operator tended to break.
- Choose array length with a slider.
- Easy to choose to use python evaluation when necessary.
- Code is commented, split up, and much easier to understand.
The custom property's value is purposefully not exposed, since the Edit
operator is for changing the property's metadata now, rather than the
value itself. Though in the "Python" mode the value is still available.
More improvements are possible in the future, like exposing different
subtypes, and improving the UI of the custom properties panel.
Differential Revision: https://developer.blender.org/D12435
|
|
Added description for Batch rename which pop-ups when
hovering the mouse over "Batch rename" inside the edit menu.
Fixes T91390
Reviewed By: Blendify
Maniphest Tasks: T91390
Differential Revision: https://developer.blender.org/D12594
|
|
Initializing the description property was completely forgotten.
It also seems it may be missing sometimes, so use `get`.
Also, clean values when there is no data, and correctly use
the return value of `get_value_eval` in one instance.
|
|
Use the key-config name for the file name.
|
|
In {rB9cff9f9f5df0} asset_library was renamed → asset_library_ref.
Missed to update this in assets.py.
Differential Revision: https://developer.blender.org/D12497
|
|
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
|
|
This commit fixes the custom property edit operator for the the case of
editing group properties. Currently this isn't supported very well, the
data is converted to a string, but the operator shouldn't fail anyway.
This allows editing properties created like this:
C.object['abuse'] = {'parent' : ['child1', 'child2']}
These changes reflect some issues with the design of the operator.
Requiring guessing the type of the data does not work well at all, and
makes code more complicated. In the future this operator can be updated
to use a type drop-down.
Differential Revision: https://developer.blender.org/D12364
|
|
Since the UI data is now stored in the property, and the property is
deleted on the next line, this doesn't need to be called separately.
|
