- "Parameters for custom (OSL-based) Cameras" -> "cameras": lower case
in tooltips.
- "Connect two nodes ... (automatically determined": missing
parenthesis.
- "Join curve... control points are detected(if disabled...": add
missing space.
- "Add Selected to Active Objects Collection" -> "Active Object's":
typo.
- "Duplicate the acive shape key" -> "active": typo.
- "Copy selected points ": remove trailing space.
- "Move cursor" -> "Cursor": title case for operator.
- "Paste text to clipboard" -> "from clipboard": typo.
- "An empty Action considered as both a 'layered' and a 'layered'
Action." -> "is considered as both a 'legacy' and a 'layered'
Action": likely copy-paste error.
- "Target's Z axis will constraint..." -> "will constrain": typo.
- "The layer groups is expanded in the UI" -> "layer group": typo.
- Deprecation warnings: add missing parentheses.
- "... on low poly geometry.Offset rays...": add missing space after
period.
- "... relative to the files directory" -> "... to the file's
directory": typo.
- "The unit multiplier for pixels per meter" -> "The base unit": this
property description was copy and pasted.
- "... beyond the faces UVs..." -> "the faces' UVs: typo.
- "Is tracking data contains ..." -> "Whether the tracking data
contains": grammar.
- "Selected text" -> "Text": title case for prop.
- "The user has been shown the "Online Access" prompt and make a
choice" -> "made a choice": grammar.
- "Glare ": remove trailing space.
- "Don't collapse a curves" -> "Do not collapse curves": grammar.
Some issues reported by Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/139118
This function to get the active attribute currently returns a custom
data layer pointer. This doesn't work when we transition to the new
`AttributeStorage` system. Returning an optional string is a simple
alternative that also aligns with the idea of changing the source of
truth from an index to a string stored on the geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/139115
Add support for the UsdPrimvarReader_TYPE templates for both import and
export. These are used by several USD test assets and support here
represents the last major piece of the UsdPreviewSurface spec to be
implemented.
On import these become `Attribute` nodes and on export the `Attribute`
nodes will become `UsdPrimvarReader_TYPE`'s accordingly.
Import:
- `UsdPrimvarReader_float` and `UsdPrimvarReader_int` will use the `Fac`
output
- `UsdPrimvarReader_float3` and `UsdPrimvarReader_float4` will use the
`Color` output
- `UsdPrimvarReader_vector`, `UsdPrimvarReader_normal`, and
`UsdPrimvarReader_point` will use the `Vector` output
Export (only `Geometry` Attribute types are considered):
- `Fac` will use `UsdPrimvarReader_float`
- `Color` will use `UsdPrimvarReader_float3`
- `Vector` will use `UsdPrimvarReader_vector`
- `Alpha` is not considered
MaterialX note:
Hydra-native support is a bit more involved and will have to be done
separately. Hydra w/USD sync is trivial to implement but those changes
have been left out here.
Pull Request: https://projects.blender.org/blender/blender/pulls/135143
This field's usage was removed with the brush assets project, previously
it was used during runtime in the `PAINT_OT_brush_select` operator.
This commit tags the DNA field as deprecated and marks the overall
`brush.cc` file with `#define DNA_DEPRECATED_ALLOW` to follow a similar
pattern as other BKE files dealing with I/O of ID types.
The field was added in 147b4b13ba and
updated in 7b7aba31f2 to prevent invalid
pointers from remaining on the brush.
Pull Request: https://projects.blender.org/blender/blender/pulls/138578
This patch implements basic support for evaluating function nodes on volume
grids. Conceptually, a function node always creates a new grid for the output,
though the output is often a modified version of the input. The topology of the
output grid is a union of all the input grids.
All input grids have to have the same transform. Otherwise one has to use
resampling to make grids compatible.
Non-grid inputs are allowed to be single values or fields. The fields are
evaluated in a voxel/tile context, so they compute a value per voxel or per
tile.
One optimization is missing that will probably be key in the future: the ability
to merge multiple function nodes and execute them at the same time. Currently
the entire function evaluation is started and finished for every function node
that outputs a grid. This will add significant overhead in some situations.
Implementing this optimization requires some more changes outside of the scope
of this patch though. It's good to have something that works first.
Note: Not all function nodes are supported yet, because we don't have grid types
for all of them yet. Most notably, there are no color/float4 grids yet.
Implementing those properly is not super straight forward and may require some
more changes, because there isn't a 1-to-1 mapping between grid types and socket
types (a float4 grid may correspond to a color or vector socket later on).
Using grids with function nodes and fields can result in false positive warnings
in the UI currently. That's a limitation of our current socket type inferencing
and can be improved once we have better socket shape inferencing.
Pull Request: https://projects.blender.org/blender/blender/pulls/125110
This adds a new Bit Math node which supports the following operations: `and`,
`or`, `xor`, `not`, `shift` and `rotate`.
For the `shift` and `rotate` operations, a posititive shift is a left shift and
a negative shift is a right shift.
Currently, the node always works on 32-bit integers which is what Geometry Nodes
uses internally for integers. If required, this can be extended to work on other
bit widths in the future.
The need for this came up every now and then. It can be useful when encoding
specific bits in integer attributes (for efficiency or because the geometry is
exported to other software that expects a certain format). Also, this node is
useful for some people doing crazy but fun things with Geometry Nodes like
emulating hardware. Even if the use-cases are not common, if they arise, it's
hard to work around and the cost of having this node is quite low for us.
Co-authored-by: Charlie Jolly <charliejolly@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/138290
#138747 adds a new interface item type for separators. Unfortunately, the
current code is not forward-compatible with those. This patch improves forward
compatibility by removing all unknown tree interface item types on-load.
Pull Request: https://projects.blender.org/blender/blender/pulls/139015
This allows multiple threads to request different specializations without
locking usage of all specialized shaders program when a new specialization
is being compiled.
The specialization constants are bundled in a structure that is being
passed to the `Shader::bind()` method. The structure is owned by the
calling thread and only used by the `Shader::bind()`.
Only querying for the specialized shader (Map lookup) is locking the shader
usage.
The variant compilation is now also locking and ensured that
multiple thread trying to compile the same variant will never result
in race condition.
Note that this removes the `is_dirty` optimization. This can be added
back if this becomes a bottleneck in the future. Otherwise, the
performance impact is not noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/136991
Previously, whenever the zone detection algorithm could not find a result, zones
were just not drawn at all. This can be very confusing because it's not
necessarily obvious that something is wrong in this case.
Now, invalid zones and links that made them invalid have an error.
Note, we can't generally detect the "valid part" of zones when there are invalid
links, because it's ambiguous which links are valid. However, the solution here
is to remember the last valid zones, and to look at which links would invalidate
those. Since the zone-detection results in runtime-only data currently, the
error won't show when reopening the file for now.
Implementation wise, this works by keeping a potentially outdated version of the
last valid zones around, even when the zone detection failed. For that to work,
I had to change some node pointers to node identifiers in the zone structs, so
that it is safe to access them even if the nodes have been removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/139044
This feature greatly increase depth buffer precision.
This is very noticeable in large view distance scenes.
This is enabled by default on GPUs that supports it (most of the hardware we
support already supports this). This makes rendering different on the GPUs
that do not support that feature (`glClipControl`).
While this give much better depth precision as before, we also have a lot of
imprecision caused by our vertex transformations. This can be improved in
another task.
Pull Request: https://projects.blender.org/blender/blender/pulls/138898
Caused by 9c35656766
More like a typo, in that commit, `ANIM_bonecoll_is_visible_editbone`
was swapped with `blender::animrig::bone_is_visible_editbone` (but that
was only meant to replace `ANIM_bone_is_visible_editbone`)
So to resolve, just use `ANIM_bonecoll_is_visible_editbone` again
Pull Request: https://projects.blender.org/blender/blender/pulls/139077
Previously, internal links of node are only shown when the link is muted AND
when the corresponding output is linked to something else. I can't think of any
reason for why it's important whether the output is linked or not. It seems
showing the internal link is always useful.
This patch makes it so that all internal links are always shown when a node is
muted, regardless of whether the corresponding output socket is linked or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/139086
Previously, when adding a group node it was always called `Group`. This is not
particularly useful. Also it's inconsistent with many other places like adding
modifiers where the name of the modifier depends on what modifier is added.
Now, newly added group node will have the same name as the group that it calls.
Node names still have to be unique though, so e.g. `.001` is still added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139093
Previously modifiers can only filter single layers, now filtering by
layer group is also supported.
This adds a toggle to the layer filter to switch to filtering by groups.
Resolves #123323.
Pull Request: https://projects.blender.org/blender/blender/pulls/123353
When using float2/int2/uint2 arrays the elements could be incorrectly
alligned. This wasn't noticable when using Blender as it isn't used,
However python addons and forks can use it.
Fixes an issue with UPBGE
Pull Request: https://projects.blender.org/blender/blender/pulls/139082
Importing memory is done to often. when memory doens't change the
previous imported memory can be used.
The idea is to keep track of the last used buffer and keep reusing
it until the view/resolution has changed. This should not happen during
a session.
Pull Request: https://projects.blender.org/blender/blender/pulls/138984
Currently, there are some constraints on the interface of node groups:
* Sockets have to be above panels.
* Outputs have to be above inputs.
The current code that ensures these constraints wasn't able to handle the
case when there are more interface items without the same constraints.
This patch is extracted from #138747.
... for Grease Pencil & Curves
Was only moving the points relative to the origin (so only they stayed
in place, handles were still transformed along with the origin).
In order to fix this this, we now take into account curves handles in
the whole `XFormObjectData` related code (for both Grease Pencil &
Curves). There was a handly existing pair of functions
[`curves::bezier::retrieve_all_positions` &
`curves::bezier::write_all_positions`] which we can use for Curves, for
Grease Pencil this uses code from those functions (but not the functions
directly -- indices would fail there because Grease Pencil would call
this from multiple layers).
This also introduces `BKE_grease_pencil_has_curve_with_type` so we can
know in advance how many elements we need for the
`XFormObjectData_GreasePencil`.
Also corrects a typo in c1c67c918e (swapping `XFormObjectData_Curves`
with `XFormObjectData_GreasePencil`)
Pull Request: https://projects.blender.org/blender/blender/pulls/138665
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
This is re-apply of PR !138982 was backed out in cef7cb4534 due to
Win x64 buildbot failure. The error was:
```
view3d_navigate_view_all.cc(321): error C2672: 'blender::bounds::transform_bounds': no matching overloaded function found
view3d_navigate_view_all.cc(322): error C2784: 'blender::Bounds<blender::VecBase<T,3>> blender::bounds::transform_bounds(const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &,const blender::Bounds<blender::VecBase<T,3>> &)': could not deduce template argument for 'const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &' from 'const blender::float4x4'
```
which has nothing whatsoever to do with the PR. But something
in the PR (i.e. rename of a completely unrelated enum entries)
presumably makes this specific VS2019 compiler version not be
able to resolve template argument type. Again, in completely
unrelated file with completely unrelated types.
So "the fix" is to help VS2019 compiler in that place by explicitly
specifying the template types. What exactly in the original
change triggers the issue, remains a mystery. "It is known" that
VS2019 is quite funky in template argument deduction, maybe this
is one of these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138995
