| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Caused by NULL dereference of `Editing` before NULL check was done.
|
|
Affected by rB8621fdb10dc4
Crash if single-user data is created when we apply transform
on multi-user image data. Crash occurs because creation of new copy
was not handled in `single_obdata_users` for empty objects (image for example)
Reviewed By: dfelinto, mont29
Maniphest Tasks: T100040
Differential Revision: https://developer.blender.org/D15587
|
|
From [0], restrict namsepace access to anything with an underscore
prefix since these may be undocumented.
[0]: 00c7e760b323e5fa46703d0e4769c8f1d9c35f2e
|
|
any face
The Python based importer had a special case handling of "no faces in
the whole file at all", where it ended up treating the whole file
as essentially a point-cloud-like object (just loose vertices, no
faces or edges). The new importer code was missing this special case.
Fixes T100017. Added gtest coverage that was failing without the fix.
# Conflicts:
# source/blender/io/wavefront_obj/importer/obj_import_file_reader.cc
|
|
The importer code was written under incorrect assumption that vertex
data (v, vn, vt commands etc.) are grouped by object, i.e. follow the
o command, and that each object has its own vertex data commands. This
is not the case -- all the vertex data in the whole OBJ file is
"global", with no relation to any objects/groups; it's just that the
faces belong to the object, and then they pull in any vertices they
like.
This patch fixes this incorrect assumption in the importer:
- Vertex data is now properly global; no need to track some sort of
"offsets" per object like it was doing before.
- For each object, face definitions track the minimum & maximum vertex
indices referenced by the object, and then all that vertex range is
created in the final Blender object. Note: it might be (unusual, but
possible) that an object does not reference a sequential range of
vertices, e.g. just a single face with vertex indices 1, 10, 100 --
the resulting Blender mesh will have all the 100 vertices (some
"loose" without belonging to a face). It should be possible to track
the used vertices exactly (e.g. with a vector set), but I haven't
done that for performance reasons.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D15410
# Conflicts:
# source/blender/io/wavefront_obj/importer/obj_import_file_reader.cc
# source/blender/io/wavefront_obj/importer/obj_import_mesh.cc
# source/blender/io/wavefront_obj/importer/obj_import_objects.hh
# source/blender/io/wavefront_obj/tests/obj_importer_tests.cc
|
|
Address the issue by re-working line continuation handling: stop
trying to parse sequences like "backslash, newline" (which is the
bug: it should also handle "backslash, possible whitespace, newline")
during parsing. Instead, fixup line continuations after reading chunks
of input file data - turn backslash and the following newline into
spaces. The rest of parsing code does not have to be aware of them
at all then.
Makes the file attached to T99536 load correctly now.
# Conflicts:
# source/blender/io/common/intern/string_utils_test.cc
# source/blender/io/wavefront_obj/importer/obj_import_string_utils.cc
# source/blender/io/wavefront_obj/importer/obj_import_string_utils.hh
|
|
The stroke points were changed but the bounding box calculation was not done and this produced a problem in any bounding box check done by different tools.
|
|
Any script that raised a SystemExit called by --python, --python-expr
command line args or by executing the text block would exit without
printing a message. This caused the error from T99966 to be hidden.
Add explicit handling for SystemExit to ensure the message is always
shown before exiting.
More details noted in code-comments.
|
|
|
|
Loading factory settings left the region NULL, causing the brushes
poll function to crash.
|
|
Regression in [0] accessed the modifier type before NULL check.
[0]: 78fc5ea1c398f70d22cda72be33c105146c0d542
|
|
Was accidental regression in rBed9b21098dd27bf9364397357f89b4c2648f40c2
Remove the input slider's PROP_FACTOR subtype in favor of the default to
align with other IOR sliders. This provides much better control when
dragging the value with the mouse.
Differential Revision: https://developer.blender.org/D15477
|
|
|
|
Old name is confusing since SCULPT_TOOL_PAINT can paint
on images too, and it's planned for smear to as well.
|
|
null-check for grp.
Reviewed By: fclem
Maniphest Tasks: T99646
Differential Revision: https://developer.blender.org/D15436
|
|
Account for negative BHead length (already handled by blend file loading).
|
|
It was smart enough to check if the buffer had the right
size but neglected to cast to a 64 bit value so it
overflowed.
Differential Revision: https://developer.blender.org/D15457
Reviewed By: brecht
|
|
This was a missing feature and this commit solves this.
|
|
There were two bugs, a regression in [0] and the object-data wasn't
tagged for depsgraph updating.
[0]: 19df0e3cfd5b9fed891ed81dd1123b2351605a7d
|
|
Ref D15330.
|
|
Specifically BKE_texpaint_slots_refresh_object was being called, which
causes cycles to reset at strange times (like moving the mouse cursor
in pose, boundary and various other tools).
This (along with some code that checks if the pbvh pixels need
to be rebuilt) is only run if is_paint_mode (which used to be
needs_colors) is true.
|
|
Note there is a bug in BKE_object_is_visible_in_viewport, it
returns false when the object is in local mode.
The transform operator poll should do a similar test. That
would allow us to move the test from sculpt_brush_strok_invoke
to SCULPT_mode_poll (at the moment we cannot do this due to
the brush operator falling through to the translate keymap
item in global view3d keymap).
|
|
Regression in [0] which revealed an error in [1].
Logic for pose channel custom transform ignored ARM_NO_CUSTOM.
[0]: 3267c91b4d5caab7da8aef071a446dd2e86f86a9
[1]: c3fef001ee926fc183255b623f56da9fc5fcbb73
|
|
The falloff was applied to scale by error. Now, the falloff is only applied to the rotation.
Differential Revision: https://developer.blender.org/D15364
.
|
|
Regression in [0] which didn't account for the bounds of empty objects.
Add support support calculating bounds from empty draw-type to use in
pose-bone culling.
[0]: 3267c91b4d5caab7da8aef071a446dd2e86f86a9
|
|
Caused by [0] which made accessing the drag-start require a function
instead of being the value written into the event cursor coordinates.
[0]: b8960267dd51f9108b3b49e9b762e6b4d35ae1dc
|
|
Regression in [0] caused operations such as file-load or file-new
from any window besides the first to write into the freed:
`wmWindow.eventstate`.
Resolve by copying the event instead of restoring the region relative
cursor position after modifying it.
[0]: 789b1617f70e07f1c9bcb5253f1233acacbf6c8a
|
|
|
|
This changes the boolean modifier material index handling to be
consistent with the mesh boolean geometry nodes, which was
last changed in 1a6d0ec71cf3b0c2c22bc1. The issues was that the
material maps were retrieved at the object level, which doesn't
really make sense because the boolean is a geometry-level
operation. It was also confusing and prone to incorrect behavior
because it's more complex to retrieve information from two places.
Differential Revision: https://developer.blender.org/D15365
|
|
Baking assumed that color attributes could only have two configurations:
float color data type on vertices, or byte color type on face corners.
In reality the options can be combined to make four total options.
This commit handles the four cases explicitly with a somewhat
more scaleable approach (though this should really be C++ code).
Differential Revision: https://developer.blender.org/D15244
|
|
|
|
This reverts commit e2c02655c78b2c669468ae568ddf4b17953cc98d.
It caused regression T99323 which is more severe than the original fixed T98773.
|
|
|
|
Backport for the Blender 3.2 branch.
Differential Revision: https://developer.blender.org/D15355
|
|
|
|
Optionally use `sphinx_changelog_gen.py` to dump current version of the
API in a JSON file, and use closest previous one listed in given index
file to create a changelog RST page for Sphinx.
Part of {T97663}.
|
|
Main change is to make it use JSON format for its dump files, instead of
some Python code.
It also introduces an index for those API dump files, mapping a blender
version to the relevant file path.
This is then used to automatically the most recent (version-number wise)
previous API dump to compare against current one, when generating the
change log RST file.
Part of {T97663}.
|
|
Crash happened because sequencer data was not initialized. Ensure data
is initialized before adding strip.
|
|
* TBB MEX version is now 2021, since this versin introduces 'oneTBB'
which brings a lot of incompatibilities with previous versions.
* Fix several typos and mistakes in OSD, Embree and OIDN build code that
prevented proper usage of a local TBB build.
|
|
|
|
depending on the visibility of other objects
The material ID was being wrongly passed in the shader.
|
|
There were two problems:
1) The checking of the collision was not working with one point only.
2) For one point, the masking was checked always and if the masking was not activated, the stroke was skipped.
|
|
The resource binding were missing from the shading group
(`shgroup->uniform_attrs`), leading to no custom property UBO creation
(`drw_uniform_attrs_pool_update`) when issuing the drawcall,
resulting in a missing UBO bind.
The fix make sure to no duplicate the bindings by creating a simple
shader bind instead of a `GPUMaterial` bind.
Candidate for 3.2.1 corrective release.
|
|
The ORCO property was not being properly initialized in this case.
Candidate for 3.2.1 corrective release.
|
|
Use view position to retreive world space direction to retain float
precision.
Candidate for 3.2.1 corrective release.
|
|
Using Light output is supported in Cycles. This patch adds support for it
and remove the crash in `ntree_shader_weight_tree_invert()` by treating
it as any other outputs.
Candidate for 3.2.1 corrective release.
|
|
This happened because of the false assumption that `std::array<char, 32>`
would be treated as a container and not relocate their content if the
`Vector` would grow. Replacing with actual object allocation fixes the
issue.
Candidate for 3.2.1 corrective release.
|
|
|
|
|
