Add check for `NULL` `from` pointer to `BLO_main_validate_shapekeys`,
and delete these shapekeys, as they are fully invalid and impossible to
recover.
Found in a studio production file (`animation
test/snow_parkour/shots/0040/0040.lighting.blend`, svn rev `1111`).
Would be nice to know how this was generated too...
Previous implementation had a copy of the image user, which doesn't
contain all the data to identify changes. This patch introduces a new
struct to store the data and can be extended with other data as well
(color spaces, alpha settings).
For the attribute search button, the tooltip was missing
if the input socket type has attribute toggle activated.
Differential Revision: https://developer.blender.org/D14142
I noticed that there were a few variables that should not be visible per default.
It seems to me to simply be an oversight, so I went ahead and cleaned them up.
Reviewed By: Sybren, Ray molenkamp
Differential Revision: http://developer.blender.org/D14132
StringGrid has been deprecated in openvdb 9.0.0 and will be removed soon
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D14133
Due to recent changes there have been reports of incorrect loading of
GPU textures. This fix reverts a part of {D13238} that might be the
source of the issue.
This does not happen with **any** image, but with images that have ID
properties.
ID properties are used to store view projection matrices (e.g. for
reprojection with `Image from View` or `Quick Edit` -- these are the
ones we are interested in), but of course they can be used for anything
else, too. The images in the file from the report have ID properties from
an Addon for example.
So the crash can reliably be reproduced with **any** image doing the
following:
```
bpy.data.images['myImage']['myIDprop'] = "foo"
```
This would lead code in `texture_paint_camera_project_exec` to think the
needed `view_data` is on the image (but in reality it was just some
other IDprop).
Solution is simple: just check `view_data` is really valid after getting
it from the IDprops.
Maniphest Tasks: T95787
Differential Revision: https://developer.blender.org/D14116
Although rB56407432a6a did fix missing subdivision in some cases, in
other cases it did not return the mesh wrapper (like when using
autosmooth, which requires a copy of the mesh), so the non-subdivided
mesh was still returned.
Not all coarse vertices were used to compute the center value (off by
one), and the interpolation for the current would always start at the
base corner for the base face instead of the base corner for the current
patch.
The root issue was caused by a mistake in modifier copy data which was
wrongly re-generating source modifier data identifier.
The c8cca88851 simply exposed a bug in code which always was there
since the modifiers session UUID was introduced.
Shows an importance of const qualifier :)
Since now we delegate the evaluation of the last subsurf modifier in the stack
to the draw code, Cycles does not get a subdivided mesh anymore. This is because
the subdivision wrapper for generating a CPU side subdivision is never created
as it is only ever created via `BKE_object_get_evaluated_mesh` which Cycles does
not call (rather, it accesses the Mesh either via `object.data()`, or via
`object.to_mesh()`).
This ensures that a subdivision wrapper is created when accessing the object data
or converting an Object to a Mesh via the RNA/Python API.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D14048
The crash is caused as we did not check that the RNA pointer is null
before trying to use it. This moves the existing checks from the
modifier panels into the template functions so the logic is a bit
centralized.
The issue has two causes: on one hand origin indices were not handled
properly, on the other hand the extraction type (Mesh, BMesh, or mapped)
was not detected correctly.
For the second case reuse the MeshRenderData creation from the coarse
code path so that we make the same decisions. Loose geometry extraction
had to be updated to properly handle the BMesh cases.
For the origin indices, in some cases (for edges and faces), the arrays
used by the subdivision code already have the origin indices baked into
them, so mapping them a second time through the origin index layer is
wrong, and could cause out of bounds accesses.
For vertices especially, we would use two arrays: one for mapping
subdivision vertices to coarse vertices, and another one to map coarse
vertices to subdivision loops used for the selection index buffer. The
second one is now removed (which saves a bit of memory) as it is did not
have the proper data setup for use with the origin indices and we can
easily compute it using the first array anyway.
Fix segfault when calling `some_id.id_properties_ui("propname").update()`,
i.e. call the `update()` function without any keyword arguments. In such
a case, Python passes `kwargs = NULL`, but `PyDict_Contains()` is not
`NULL`-safe.
The Viewer marked the gpu texture to be out of date. But it should have used
the mark_full_update as the gpu textures
are only used by the render/draw engines.
The image/node editor uses the image engine that have its own GPU textures.
Currently one a single texture slot is used to update the screen.
Current design is implemented to use multiple textures.
for now limit the number of texture slots to 1.
This node is a bit of a weird case, because it uses the value stored in an
output socket as an input. So when we want to determine if the Dot
changed, we also have to check if the Normal output changed.
A cleaner solution would be to refactor this by either storing the normal
on the node directly (instead of in an output socket), or by exposing it
by a separate input. This refactor should be done separately though.
Due to the freeing and re-creation of textures performed when binding
offscreen viewports, VR viewport textures would be needlessly
re-created every drawing iteration, leading to a negative impact on VR
frame rate.
This was brought to light by 6738ecb64e, which introduced an
additional texture clear operation on initialization and was
prohibitively costly on some systems when performed every frame.
Now, the textures for VR viewports will not be always re-created
during offscreen binding, but only when necessary using a pre-drawing
step (`wm_xr_session_surface_offscreen_ensure()`).
Reviewed By: jbakker, fclem
Differential Revision: https://developer.blender.org/D14059
For the majority of node groups created in Blender 3.0 the behavior does not change.
So far we only found a single file where this setting has an effect.
Differential Revision: https://developer.blender.org/D14078
Complex Solidify creates edge bevel weights on the rim if the
according vertex has some vertex bevel weight. If there are no
edge bevel weights, they were left disabled even if vertex bevel
weights are used.
Some curve objects don't have an evaluated mesh at all, but line art
currently assumes that all curve objects have one before converting
it to a mesh internally. Fix this by checking if the curve object has an
evaluated mesh before skipping it.
The remaining problem is that evalauted from non-mesh objects or
evaluated curves from non-curve objects, etc. will be ignored if
"Allow Duplicates" is off. That's a different problem though.
Differential Revision: https://developer.blender.org/D14036
The main issue is that the image and image user is not updated correctly
in `rna_ImageUser_update`. `BKE_image_user_frame_calc` does not set the
correct frame, because the image is null. Also `IMA_GPU_REFRESH` is not
set for the same reason.
When gpu materials are first created, it is expected that the frame is set
correctly, and the flag is set if necessary. Therefore, somewhere during
depsgraph evaluation, those have to be updated. The depsgraph node
to do the update existed already. Now there is a new relation so that it is
executed when the node tree changed, not only when the frame changed.
This is partially caused by a stupid mistake in cfa53e0fbe
where I missed initializing the `vert_normals` pointer in
`MResolvePixelData`. It's also caused by questionable assumptions
from DerivedMesh code that vertex normals would be valid.
The fix used here is to create a temporary mesh with the data necessary
to compute vertex normals, and ensure them here. This is used because
normal calculation is only implemented for `Mesh` and edit mesh, not
`DerivedMesh`. While this might not be great for performance, it's
potentially aligned with future refactoring of this code to remove
`DerivedMesh` completely. Since this is one of the last places the data
structure is used, that would be a great improvement.
Differential Revision: https://developer.blender.org/D13960
The crash was happening when the mesh had loose edges.
Loose edges are not part of OpenSubdiv topology and hence should not be
communicated to the refiner. Pass ta boolean flag indicating whether an
edge is loose or not in the mesh foreach routines, which seems to be
the easiest way.
From a strict language point of view the code required a braces around
`trgba` initialization. But it is easier to rely on the fact that fields
which are not specified are zero-initialized.
