| Age | Commit message (Collapse) | Author |
|---|
|
|
|
While it still has known issues/bugs/limitations. Also do not make it the very first export menu item, while at it.
Differential: D14512
|
|
Simple error in an earlier commit, the flags should be or-ed.
|
|
The crash happens because the origindex layers created as part of
the modifier stack evaluation are not set in the `MeshRenderData` when
they should have been.
This is because when selecting in X-ray mode, a subdivision wrapper
is created to ensure that selection happens with a subdivided
geometry, and this replaces the `MDATA` wrapper which is also used to
setup the `MeshRenderData`.
As we do not seemingly have an `MDATA` wrapper, the draw code decides
that we can extract draw buffers directly from the BMesh, instead of
the mapped Mesh with origin indices layers.
To fix this, we should also consider to use mapped extraction if a
subdivision wrapper exists on the mesh.
Differential Revision: https://developer.blender.org/D14485
|
|
There were multiple issues at hand here:
- The default value has been changed to `{0, 0, 1}` see: rB25f1783673de636a6f0ca4457df8c05bc685981a
- The output needs the subtype set `PROP_DIRECTION`
- The noder properties were missing in `node_composit_set_butfunc`
Fixes T96860
|
|
Regression in [0] follow the same logic as edit-mode for using the local-matrix.
[0]: d052169e7e4b84b5d621fcbf15b187a4951f1f70
|
|
|
|
|
|
The lines paint mask IBO extraction was not implemented for GPU subdivision.
For it to work, we also now need to preserve the subdivision loop to
subdivision edge map, which until now was overwritten to store coarse edges
(the map to coarse edges is still preserved).
Also the paint flag stored in the 4th dimension of the loop normal buffer
was not properly set for flat shaded faces, leading to other kind of
artefacts and render issues.
|
|
|
|
The problem was when the stroke had less weights that the total number of vertex groups.
The API checked the total number of groups, but this is not required because `BKE_defvert_find_index` returns NULL is the vertex group index does not exist.
|
|
Regression in [0], also use pad buffer by 1 instead of 2 which is no
longer needed as the trailing slash is no longer added
after allocating the string.
0682af0d63a44b050d57bdaf7699e364a311d711
|
|
This was a mistake in the conditional structure introduced in 4b35d6950d4f
This commit also adds a new type of snap exclusion: `SNAP_NOT_EDITED`.
Thanks to @Ethan1080 for pointing out the error.
|
|
Following the logic is not necessary to check the mouse button because the status has changed before.
|
|
|
|
Fixes T96324, T96312, T96323
|
|
The problem was the stroke was created in the inverted loop before checking if the total of points is 0 and exit the loop.
Also some code Cleanup.
|
|
This broke between 3.0 and 3.1, upgrading to Python 3.10 seems the
likely cause as this code didn't change.
|
|
Currently there is a "calc_face_normal" argument to mesh to bmesh
conversion, but vertex normals had always implicitly inherited whatever
dirty state the mesh input's vertex normals were in. Probably they were
most often assumed to not be dirty, but this was never really correct in
the general case.
Ever since the refactor to move vertex normals out of mesh vertices,
cfa53e0fbeed7178c7, the copying logic has been explicit: copy the
normals when they are not dirty. But it turns out that more control is
needed, and sometimes normals should be calculated for the resulting
BMesh.
This commit adds an option to the conversion to calculate vertex
normals, true by default. In almost all places except the decimate
and edge split modifiers, I just copied the value of the
"calc_face_normals" argument.
Differential Revision: https://developer.blender.org/D14406
|
|
A mistake in the mesh normal refactor caused the wrong mesh to
be used when calculating normals with a shape key's deformation.
This commit fixes the normal calculation by using the correct mesh,
with just adjusted vertex positions, and calculating the results
directly into the result arrays when possible. This completely avoids
the need to make a local copy of the mesh, which makes sense,
since the only thing that changes is the vertex positions.
Differential Revision: https://developer.blender.org/D14317
|
|
|
|
For render image buffers to be acquired, a lock must be provided. Also
fixed wrong usage of release, it must always be called regardless if the
returned image buffer is NULL.
|
|
Vertices were not drawn properly as the logic for mapped mesh was used
in the BMesh case.
Edge display would ignore subdivided edges which would come from coarse
edges when setting display flags.
|
|
If there is no active object, it is to be expected that we are in
object mode as well.
|
|
Regression introduced in 52be06301257a82a1b4a5746e91ff60daa637ded
The `SNAP_NOT_SELECTED` option should only consider base selected if
we are in object mode.
|
|
If the mouse is not hovering the window, there is no active region. This is a
valid state, but the UI-list filter operator didn't account for that case.
|
|
|
|
Currently, whenever any BMesh is converted to a Mesh (except for edit
mode switching), original index (`CD_ORIGINDEX`) layers are added.
This is incorrect, because many operations just convert some Mesh into
a BMesh and then back, but they shouldn't make any assumption about
where their input mesh came from. It might even come from a primitive
in geometry nodes, where there are no original indices at all.
Conceptually, mesh original indices should be filled by the modifier
stack when first creating the evaluated mesh. So that's where they're
moved in this patch. A separate function now fills the indices with their
default (0,1,2,3...) values. The way the mesh wrapper system defers
the BMesh to Mesh conversion makes this a bit less obvious though.
The old behavior is incorrect, but it's also slower, because three
arrays the size of the mesh's vertices, edges, and faces had to be
allocated and filled during the BMesh to Mesh conversion, which just
ends up putting more pressure on the cache. In the many cases where
original indices aren't used, I measured an **8% speedup** for the
conversion (from 76.5ms to 70.7ms).
Generally there is an assumption that BMesh is "original" and Mesh is
"evaluated". After this patch, that assumption isn't quite as strong,
but it still exists for two reasons. First, original indices are added
whenever converting a BMesh "wrapper" to a Mesh. Second, original
indices are not added to the BMesh at the beginning of evaluation,
which assumes that every BMesh in the viewport is original and doesn't
need the mapping.
Differential Revision: https://developer.blender.org/D14018
|
|
Caused by rBc0bd240ad0a1.
To avoid crash, make boolean value false if active object data is NULL.
Should be backported to 2.93 LTS and 3.1 corrective releases.
|
|
Correct ANY/PRESS value pairing with TWEAK/MOUSE event types.
|
|
Previously, instances used the point domain, but now there is a special
domain for instance attributes that the node has to use.
|
|
A 7 year old commit, 2ec00ea0c1be1ace7c, used incorrect indexing for
the optional array of precomputed poly normals. Apparently that code
path was never used, or this issue would have been discovered earlier.
Recent changes calculate normals on a temporary mesh and use those
for the "low-res" layer, meaning the precomputed path was always taken.
|
|
Typo (copy/paste mistake) in rB923b28aab85768e2b.
|
|
Since 3b6ee8cee7080af20, a list of vertex groups cannot be retrieved
from curve objects for merging because curve objects do not support
vertex groups. Previously the empty list on the object was returned.
Only mesh objects are supported for the caps.
|
|
Old python exporter in 3.0 and earlier ordered faces by material,
but the new C++ exporter in 3.1+ did not, and was just writing them
in whatever is the order of the mesh data structure.
This mostly does not cause problems, except in some apps e.g.
Procreate -- for large enough meshes, this lack of
"order by material" (which ends up having more usemtl lines)
ends up creating more mesh subsets than necessary inside Procreate.
The change is not computationally heavy, e.g. exporting 6-level
subdivided Monkey mesh goes 1085ms -> 1105ms on my machine.
Reviewed By: @howardt
Differential Revision: https://developer.blender.org/D14368
Cherry-picked from: eb1755be355a + fab14f78542c + 8c072cdc935c
|
|
The logic in the code was _completely different_ from the documentation
and what the python exporter in 3.0 did. The new code assumed that
"export material groups" meant "append material name to the object name",
and was only ever kicking in when the "export object groups" option was
also checked. But the proper behavior (as in 3.0 exporter & the online docs),
is to emit g objectname_materialname before each usemtl line. Which is something entirely else.
Cherry picked from b9123b806fc4 (D14349) with minor conflict fixes.
|
|
Instead of scaling "the scene" (i.e. transform vertices by object matrix,
then multiply by scale factor), it was instead first applying the scale
factor in local space, and then transforming by the object matrix.
Cherry picked from 5bfdaaa80082, original differential D14347.
|
|
face order for negative scale
The new 3.1+ OBJ exporter did not have correct logic when faced with
non-uniform & mirrored (negative on odd number of axes) object scale:
- Normals were not transformed correctly (should use inverse transpose of the matrix),
and were not normalized,
- Face order was not "flipped" when transform has negative scale on odd number of axes
(visible when using "face orientation" viewport overlay).
Cherry-picked from 8aa365745a78, with minor conflict fixes.
Reviewed By: Howard Trickey
Differential Revision: https://developer.blender.org/D14343
|
|
|
|
implementation-defined value of `GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT`
Allow the user to set an anisotropic filtering setting below the implementation-defined value of `GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT`.
This bug-fix is also needed for 2.93 LTS.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14392
|
|
This was a use-after-free bug due to dangling pointers.
|
|
|
|
When using inverted filling and click inside a closed area and not outside as is expected, the algorithm to detect the contour to fill is unable to find the filling shape and try to fill outside of the valid index.
The infinite loop was adding more memory for each loop and the process continued while there was system resources and finally crashed the system.
As the tool in negative mode is designed to fill all areas when you click outside of any shape, now the algorithm check if the outline is not working as expected and cancels the filling process.
|
|
The previous code updated the wrong node tree. The result was that
the new group node did not have the socket that was supposed to
be linked.
|
|
This patch, D14303, from Aras Pranckevicius adds presets to the OBJ exporter,
and also adds a checkbox (default on) to apply modifiers before export.
|
|
When the light direction is not pointing away from the geometric normal and
there is a shadow terminator offset, self intersection is supposed to occur.
|
|
|
|
Modified source Armature ID in the join operation was not properly
tagged as such for the depsgraph (and therefore memfile undo)..
Issue caused/revealed by rBe648e388874a.
Should be backported to 3.1 should we make a corrective release.
|
|
Caused by 0cb5eae9d0617abedf745753c23061ddfcfd1416 which restored
support for 3D depth when selecting gizmos - making it difficult
to select single lines drawn in front of other gizmos.
Previously the first hit was always used.
Resolve by using a margin around arrow stems when selecting
which was already done for 2D arrows.
|
|
This fixes the crash by removing the `do_view3d_header_buttons` handler.
The code can work at a higher level here, using the operator for setting
the select mode, which makes this patch a cleanup as well.
The operator now has a description callback to add the custom
description used for the behavior in its invoke method.
Differential Revision: https://developer.blender.org/D13660
|
