Age | Commit message (Collapse) | Author |
|
Before you could have the new sculpt symmetry code and the older weight
paint symmetry code active at the same time. This would lead to users
easily trashing their weigh paint data if they were not careful when
switching between modes.
Now the specific weight paint symmetry code is an exclusive toggle so
the user can't accidentally mirror strokes and vertex groups at the same
time. This also paves the way of supporting Y and Z symmetry in the
future for weight groups mirroring if we decide to add it in the future.
(As the UI part for it is done)
See https://developer.blender.org/D10426
|
|
There isn't really a reason for why this has to return a copy of
the data instead of a reference.
|
|
"Kind" is a bit less generic than "Info" for me. Especially, it implies
that the struct does not contain the name of a specific attribute
(for me anyway).
|
|
|
|
Caused by rB85fe12071ad7.
When looking at a render pass in viewport and move the camera, there's a
"flash" effect in this AOVs test file:
{F9753476}
{F9753473}
The cause seems to be that taa_current_sample when rendering
(DRW_state_is_image_render()) is ok because it has been incremented in
EEVEE_temporal_sampling_draw but taa_current_sample is wrong when we are
not rendering.
D10375 by Ulysse Martin (youle) with clang format changes.
Reviewed By: jbakker, lichtwerk, also blessing from fclem
Differential Revision: https://developer.blender.org/D10375
|
|
This allows accessing per-point attributes on the corner domain,
which can be useful e.g. when adding per-point displacement
to per-corner uv coordinates.
Also it is required to make an upcoming patch work well, that
makes the Point Distribute node use density weights per corner
instead of per point, giving the user more precise control over
the distribution.
|
|
This makes vertex colors available in geometry nodes similar to
how uvs are available. They can be used using the attribute system.
Vertex colors are stored per corner (as are uvs, but not like vertex weights).
Ref T84297.
Differential Revision: https://developer.blender.org/D10454
|
|
Previously, when a Geometry Nodes modifier outputs a point cloud
(e.g. generated using the Point Distribute node), other modifiers
could not use that data. Now, the point cloud data is converted to
mesh vertices for such modifiers.
Ref T85281.
Differential Revision: https://developer.blender.org/D10451
|
|
|
|
|
|
|
|
|
|
|
|
The integer mode still needs a random value in a 0 to 1 range, just like
floats. So slightly refactor to let the integer randomization use the
float implementation and then round to an int afterwards.
|
|
This is still a rolling release candidate with new builds every day
as a preparation to the final release.
|
|
And fix a (harmless) compiler warning.
|
|
From the the opengl wiki:
> Buffer objects are associated with a program's uniform block similarly to the way that texture objects are associated with sampler uniforms.
|
|
|
|
|
|
|
|
|
|
|
|
This commit extends the gpu python API with:
```
gpu.types.Buffer #"__init__", "to_list"
gpu.types.GPUTexture #"__init__", "clear", "read", "format"
gpu.types.GPUFrameBuffer #"__init__", "bind", "clear", "is_bound", "viewport", ("__enter__", "__exit__" with "GPUFrameBufferStackContext")
gpu.types.GPUUniformBuf #"__init__", "update"
gpu.state #"blend_set", "blend_get", "depth_test_set", "depth_test_get", "depth_mask_set", "depth_mask_get", "viewport_set", "viewport_get", "line_width_set", "line_width_get", "point_size_set", "color_mask_set", "face_culling_set", "front_facing_set", "program_point_size_set"
```
Add these methods to existing objects:
```
gpu.types.GPUShader #"uniform_sample", "uniform_buffer"
```
Maniphest Tasks: T80481
Differential Revision: https://developer.blender.org/D8826
|
|
|
|
* WITH_CPU_SSE was renamed to WITH_CPU_SIMD, and now covers both SSE and Neon.
* For macOS sse2neon.h is included as part of the precompiled libraries.
* For Linux it is enabled if the sse2neon.h header file is detected. However
this library does not have official releases and is not shipped with any Linux
distribution, so manual installation and configuration is required to get this
working.
Ref D8237, T78710
|
|
In preparation of adding Neon support.
Ref D8237, T78710
|
|
|
|
One of the sentences changed recently in rBc63df3b33f01 was missing
a word. No functional changes.
|
|
|
|
Was reported for Geometry Nodes Editor "New" button, but was true for
any modifier added via modifiers.new().
Now just add appropriate nofifier.
Maniphest Tasks: T85722
Differential Revision: https://developer.blender.org/D10450
|
|
|
|
The `material_index` attribute can adjust which material in the list
will be applied to each face of the mesh. There are two new things
about this attribute that haven't been exposed by the attribute API yet.
Each comes with limitations:
1. Integer data type: Most attribute nodes are currently written to use
float data types. This means that they can't write to this attribute
because they can't change the type of a built-in attribute.
2. Polygon domain: This is our first attribute using the polygon domain,
meaning until some of the interpolations are implemented, some
operations may not work as expected.
Currently the two nodes that work with this attribute are Attribute Fill
and Attribute Randomize.
Differential Revision: https://developer.blender.org/D10444
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`py_` prefix can be confused with the Python's own API's.
|
|
|
|
To avoid anti-aliasing artifacts on GPencil strokes that have a size smaller than 1 the thickness
is clamped and the opacity reduced. This was done in vertex shader but this had the side effect
of causing strokes that go from large to small to fade across their lengths.
**Solution**
The opacity modulation has now been moved to the fragment shader as advised by Clément Foucault.
The strokeThickness that was passed to the shader was clamped to prevent it from being too small so an additional
unclamped thickness has been passed to the fragment to calculate the opacity modulation. Alternatively I could have chosen
strokeThickness and clampedThickness but I decided against renaming the variables in the current code.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D10438
|
|
This is a follow up commit for rB96da8e9ca302b8d879744.
Ref T85281.
|
|
mesh modifier
Previously, when the output of a Geometry Nodes modifier would
contain instances, those could not be accessed by other existing
modifiers (e.g. the Array modifier). That is because those modifiers
don't know about instances.
Upcoming commits will improve an this in two ways:
* Also realize instances before deform modifiers.
* Convert a point cloud in the geometry to mesh vertices so that
they can be accessed as well.
Note, making instances real can result in loosing some information
that we do not support in Geometry Nodes yet. That includes some
special builtin attributes like bevel weights.
Ref T85281.
Differential Revision: https://developer.blender.org/D10432
|
|
Introduced by my recent commit: rBc48360c2559a
Accidentally used 4 instead of `necs->length`.
|
|
This will be used by the material index attribute when it is added.
|
|
Since "Applied Modifier" was always added last, it obscured more important
messages when using the shortcut to delete modifiers. The purpose of the
report when using the shortcut was to make it clear that something
happened. Since another report does that anyway, only display the
"Applied Modifier" report if the report list length hasn't changed.
|
|
Issue introduced by my commit: rB40b7929cc040
**User-level Problem**:
The issue resulted in a full-replace upper strip with only a Z location
channel full-replacing the XY location channels of the lower stack.
replaced to default. The expected behavior is that only the Z location
channel is affected.
**Technical-level Problem**:
Before the problematic commit, fcurves were blended as they were read.
So only existing animated channels would blend. My recent commit
changed the process to read all fcurve values into an isolated
upper_snapshot then blend with the lower stack. There is no data stored
to know whether the upper snapshot channel values were sampled from
fcurves or were default values. Only those sampled from fcurves should
be blended.
**Solution**:
Added a `blend_domain` bitmask member to NlaEvalChannelSnapshot.
The blending function only blends values within the `blend_domain`.
Sampled fcurve values are now marked as within the `blend_domain`.
We also now always copy the lower snapshot to the result snapshot which
only matters when they aren't the same. Currently, it's always the same
so the change is more for future unseen cases.
Reviewed By: sybren, #animation_rigging
Differential Revision: https://developer.blender.org/D10339
|
|
|
|
|
|
|