| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
For now just assume that a node group without output sockets is
an output node. Ideally, we would use run-time information stored
on the node group itself to determine if the group contains a
top-level output node (e.g. Material Output). That can be
implemented separately.
In the larger scheme of things, top-level outputs within node
groups seem to break the node group abstraction and reusability
a bit.
|
|
Differential Revision: https://developer.blender.org/D14227
|
|
There are two issues revealed in the bug report:
- the GPU subdivision does not support meshes with only loose geometry
- the loose geometry is not subdivided
For the first case, checks are added to ensure we still fill the
buffers with loose geometry even if no polygons are present.
For the second case, this adds
`BKE_subdiv_mesh_interpolate_position_on_edge` which encapsulates the
loose vertex interpolation mechanism previously found in
`subdiv_mesh_vertex_of_loose_edge`.
The subdivided loose geometry is stored in a new specific data structure
`DRWSubdivLooseGeom` so as to not pollute `MeshExtractLooseGeom`. These
structures store the corresponding coarse element data, which will be
used for filling GPU buffers appropriately.
Differential Revision: https://developer.blender.org/D14171
|
|
|
|
The issue was uncovered by the 0f89bcdbebf5, but the root cause goes
into a much earlier design violation happened in the code: the modifier
evaluation function is modifying input mesh, which is not something
what is ever expected.
Bring code closer to the older state where such modification is only
done for the object in edit mode.
---
From own tests works seems to work fine, but extra eyes and testing
is needed.
Differential Revision: https://developer.blender.org/D14191
|
|
This is a follow up for rBd5e73fa13dd275fb9c76b1e41142ab086dd2e6be.
The issue was found with the file in T95997.
|
|
|
|
When dimension of images aren't a multifold of 256 parts of the gpu
textures are not updated. This patch will calculate the correct part of
the image that needs to be reuploaded.
|
|
Internally the update tiles are 256x256. Due to some miscalculations
tiles were not generated correctly if the dimension of the image wasn't
a multifold of 256.
|
|
New code from the vertex normal refactor cfa53e0fbeed combined with older code
from 592759e3d62a that disabled instancing for custom normals and autosmooth
meant that instancing was always disabled.
However we do not need to disable instancing for custom normals and autosmooth
at all, this can be shared between instances just fine.
|
|
The usual 'shape keys snowflake' nightmare again...
|
|
|
|
These features are complicated to support on GPU and hardly compatible
with subdivision in the first place. In the future, with T68891 and
T68893, subdivision and custom smooth shading will be separate workflows.
For now, and to better prepare for this future (although long term
plan), we should discourage workflows mixing subdivision and custom
smooth normals, and as such, this disables GPU subdivision when
autosmoothing or custom split normals are used.
This also adds a message in the modifier's UI to indicate that GPU
subdivision will be disabled if autosmooth or custom split normals are
used on the mesh.
Differential Revision: https://developer.blender.org/D14194
|
|
The scale-to-fit option did nothing for single words when
the text box had a height. This happened because it was expected that
text would be wrapped however single words never wrap.
Now the same behavior for zero-height text boxes is used when text
can't be wrapped onto multiple lines.
|
|
59343ee1627f4c369e missed one case of normals being
retrieved from polygon custom data instead of the normals API.
The fix is simple.
|
|
Currently, when normals are calculated for a const mesh, a custom data
layer might be added if it doesn't already exist. Adding a custom data
layer to a mesh is not thread-safe, so this can be a problem in some
situations.
This commit moves derived mesh normals for polygons and
vertices out of `CustomData` to `Mesh_Runtime`. Most of the
hard work for this was already done by rBcfa53e0fbeed7178.
Some changes to logic elsewhere are necessary/helpful:
- No need to call both `BKE_mesh_runtime_clear_cache` and
`BKE_mesh_normals_tag_dirty`, since the former also does the latter.
- Cleanup/simplify mesh conversion and copying since normals are
handled with other runtime data.
Storing these normals like other runtime data clarifies their status
as derived data, meaning custom data moves more towards storing
original/editable data. This means normals won't automatically benefit
from the planned copy-on-write refactor (T95845), so it will have to be
added manually like for the other runtime data.
Differential Revision: https://developer.blender.org/D14154
|
|
|
|
Even though 5.0 has been released newer distributions wont include it,
so quiet warnings.
|
|
There was accidentally some displacement related code running even when not
using displacement.
Differential Revision: https://developer.blender.org/D14169
|
|
- No need for `normal_tx` array if we normalize the planes in `plane_tx`.
- No need to calculate the distance squared to a plane (with `dist_signed_squared_to_plane_v3`) if the plane is normalized. `plane_point_side_v3` gets the real distance, accurately, efficiently and also signed.
So normalize the planes of the member `CameraViewFrameData::plane_tx`.
|
|
A simple mistake with a null mesh in rBcfa53e0fbeed.
|
|
This makes the fix for T95839 simpler.
Similar to 969c4a45ce09100ed.
|
|
The node animation versioning code passes `nullptr` to the `oldName` and
`newName` parameters, but those weren't `NULL`-safe. I added an extra
check for this.
No functional changes, just a crash fix.
|
|
This removes manual handling of normals that was hard-coded
to false in the one place the function was called. This change
will help to make a fix to T95839 simpler.
|
|
It's better not to expose the details of where the dirty flags are
stored to every place that wants to know if the normals are dirty.
Some of these places are relics from before vertex normals were
computed lazily anyway, so this is more of an incrememtal cleanup.
This will make part of the fix for T95839 simpler.
|
|
The "Fill Caps" option on the Curve to Mesh node introduced in
rBbc2f4dd8b408ee makes it possible to fill the open ends of the sweep
to create a manifold mesh.
This patch fixes an edge case, where caps were created even when the
rail curve (the curve used in the "Curve" input socket) was cyclic
making the resulting mesh non-manifold.
Differential Revision: https://developer.blender.org/D14124
|
|
In ffmpeg 5.0, several variables were made const to try to prevent bad API usage.
Removed some dead code that wasn't used anymore as well.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D14063
|
|
StringGrid has been deprecated in openvdb 9.0.0 and will be removed soon
Reviewed By: Brecht
Differential Revision: http://developer.blender.org/D14133
|
|
Some instances might be "empty" and therefore have no dimensions.
Those should be ignored here.
|
|
This was an issue when e.g. `bpy.data.meshes.new_from_object` was
used on an object that uses geometry nodes.
|
|
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.
|
|
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.
|
|
The root issue was caused by a mistake in modifier copy data which was
wrongly re-generating source modifier data identifier.
The c8cca8885181 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
|
|
lib_query/foreach_id code.
This will have to be backported to 2.93 and possibly 2.83 if possible.
|
|
IMA_GPU_REFRESH is replaced by
BKE_image_partial_update_mark_full_update and should not be used
anymore.
|
|
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.
|
|
Multithreaded tasks have to be isolated when holding a mutex, which was
missing for the generation of the subdivision wrapper.
|
|
This reverts commit ff9dc1986e6c9a54fd0bb228e8813551e6baa042.
|
|
This is the same behavior as when applying a geometry nodes modifier
that adds anonymous attributes.
|
|
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 cfa53e0fbeed7178c78
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.
|
|
|
|
Under some circumstances, simply adding a curve object and going
to edit mode would cause a crash. This is because the evaluated
`CurveEval` was accessed but also freed by the dependency graph.
The fix reverts the part of b76918717dbfd8363f that uses the
`CurveEval` for the curve object bounds. While this isn't ideal,
it was the previous behavior, and some unexpected behavior
with object bounds is much better than a crash. Plus, given the plans
of using the new "Curves" data-block for evaluated curves, this
situation will change relatively soon anyway.
|
|
|
|
Account for `CurveEval`, which stores the proper deformed and
procedurally created data, unlike the `nurb` list, which has always
just meant a copy of the original curve.
Also account for the case when the curve is empty by using a -1, 1,
fallback bounding box in that case, just like mesh objects.
|
