The issue was that we used `from_orthonormal_axes` which obviously expects that
the axes are orthonormal. However, with custom curve normals this is not always the
case. Math wise, an additional normalization is necessary because the cross product
is not automatically normalized anymore.
This change also means that `point_matrix` may have a shearing component. But I
think that's fine here because the matrix is only immediately applied on vertex positions.
This shouldn't affect any case where the normal and tangent are orthonormal.
Pull Request: https://projects.blender.org/blender/blender/pulls/123238
Do this by:
- Removing depth and depth test.
- Scale the sphere to the covered pixels size.
- Use infinite orthographic matrix
We can still improve this by scaling the sphere
bigger depending on the accuracy at its position.
Fix#123165
`booleans_mix_calc` was incorrect. While it computed the correct result in
many common cases, under some specific circumstances, at was wrong.
Whether it was wrong also depended on how the range was split up for
multi-threading which is not deterministic.
The function was used in `Mesh::normals_domain` which then also returned
the wrong domain in some cases.
Avoid warning the user that there is a geometry, if it does not have any points/data.
Such geometry components shouldn't just be removed generally. because they
still contain information (such as the set of existing attributes).
The threshold is way too high as the light power gets very small.
It still make sense to include the power here because
some lights might be disabled for some BSDF types, and
skipping the LTC eval code can be beneficial.
So reducing the threshold to very low value near FLT_MIN
to fix the issue.
Fix#123193
The issue was a floating point precision issue
between the number of the cycle and the time
within the cycle (`cycle` and `cyct`).
Due to that the `cycle` would advance to the
next whole number while the `cycle time`
is still slightly under that.
This is fixed by calculating the `cycle` with double precision.
This has a measurable performance
impact (for `fcm_cycles_time`)
| Before | After |
| - | - |
| 39ns | 44ns |
For fcurves with a cycle modifier,
this code is run at every evaluate call.
The only time when that would be an issue is
in the graph editor, where there is an evaluate
call for roughly every pixel for curves that have a modifier.
However even in that scenario the performance
is the same within run to run variance (for `graph_draw_curves`)
| Before | After |
| - | - |
| 91565ns | 91430ns |
Pull Request: https://projects.blender.org/blender/blender/pulls/123222
Allow assigning integer values beyond int32 range to float/double
IDProperties. Extract the py object value into a temporary int64 value
in these cases.
These two lights have a second culling pass that
uses some shapes defined in view space.
These shapes need to have their handedness flipped
otherwise the test fails.
Fix#122614
Conceptually, these are the same as IDProps used for regular dynamic RNA
data (should have been done that way from the beginning). At least make
them statically typed, to avoid all kind of issues when the IDProp type
change and does not match expectations from the geometry nodes anymore.
Ref. #122743.
Pull Request: https://projects.blender.org/blender/blender/pulls/122891
All IDProperties generated as part of 'storage backend' for dynamic RNA
properties are now statically typed.
Also adds some basic unittests for the new statically typed IDProperty
system, based on py-defined RNA data.
Ref. #122743.
This implements (most of) the proposal in #122743:
* Add a new `IDP_FLAG_STATIC_TYPE` IDProperty flag.
* Update `BPy_IDProperty_Map_ValidateAndCreate` and related to never
change an existing property type if statically typed.
The biggest change happens in bpy assignement code, since instead of
replacing the old exisitng property by a newly created one, and copying
over a few settings, now the old property is kept if possible, and a new
one is only created if needed.
And in case the existing property is statically typed, if it cannot be
re-used to store the given value, and error is reported and it remains
unchanged.
`IDP_ARRAY` is also supported for basic numeric types, so 'vector'
properties and such work as expected. Lentgh is considered as part of
the static type (i.e. one can only assign a 3 components py sequence to
a 3-len array property, etc.).
Such in-place update is not yet implemented for `IDP_IDPARRAY` and
`IDP_GROUP` types. While important (especially the group one), they are
not that critical for the current issues related to changing IDProperty
types.
The hidden socket in the Viewer is not shown when a new link to it is created.
This is because the hidden property of the socket is not updated when a new
link to it is created.
Fixing it by simply manually update the property after a new link is created.
Pull Request: https://projects.blender.org/blender/blender/pulls/120503
This could happen for non manifold meshes (like a water plane)
when using the accurate method.
If last hit in the volume ray is a frontface, we now consider
everything behind it in volume.
I didn't think the BMesh extraction mode could arrive at the case where
only loose edges are requested, but turns out it can because of the
mesh wrapper system where the evaluated mesh is actually a BMesh with
deformed positions.
Related to #119999 and #122059.
In case the _source_ PropertyRNA was unset (i.e. its underlying
IDProperty storage did not exist), the copy operation would silently
fail.
In fact, the existing code handling IDProperties separately in
`RNA_property_copy` was pretty bad, since it would also bypass all the
RNA 'setting value' code (like custom setters, update handling).
Turns out, liboverride RNA apply code can already handle all of these
cases, so simply pass the raw 'unresolved' RNA property to it, and
remove all this special handling code from `RNA_property_copy`, solves
all the issues.
Extract
- Cycles denoiser enum.
- Extensions user preferences UI.
- Node operator poll message from new node function.
Improve
- Split "(Enabled|Disabled) on startup, overriding the preference."
into two messages.
Disambiguate
- "Add" when describing the action of adding something should use the
Operator context.
- "Dimensions", in noise textures.
- "Transform" as a noun, the matrix transform type of Geometry Nodes,
as opposed to the verb to move things in space.
- "Parent" as a noun or verb (the parent of an object, to parent an
object to another).
Some issues reported by Satoshi Yamasaki, deathblood, and Gabriel Gazzán.
Pull Request: https://projects.blender.org/blender/blender/pulls/122969
Masks are not updated when edited when using the GPU compositor. That's
because the GPU compositor caches static resources and invalidates them
according to the recalculate flags that the depsgraph flushes to IDs.
The issue is that the flags are not flushed to the evaluated IDs of the
compositor depsgraph, but rather to some other evaluated versions of the
IDs.
To fix this, we make the compositor depsgraph persistent and store it in
the scene runtime. This allows us to reliably track changes to resources
used by the compositor and also reduces the overhead of depsgraph
creation in the compositor job.
Patch originally provided by Sergey.
Fixes#121188.
Pull Request: https://projects.blender.org/blender/blender/pulls/123085
Fixing a bug which was causing forward-slash separators in
skeleton joint paths to be replaced with underscores, resulting in
invalid skeletons.
This was inadevertantly introduced in 9ad2c7df0b. I should
have caught this when I reviewed #122471.
Pull Request: https://projects.blender.org/blender/blender/pulls/123031
