This was preventing correct attribute rendering with multiple attributes.
Since the `CurveInfos` struct is used for data sharing between C++ and
GLSL and inside a UBO it needs to obey the `std140` alignment rules which
states that arrays of scalars are padded to the size of `vec4` for each
array entry.
When using the old particle hair with the hair info length it wasn't
working with AMD GPUs. The reason was that the drw_curves uniform buffer
wasn't initialized what made the shader select the incorrect length.
When GPU subdivision is used, and the modifier is not set to be applied
on the cage, UV selection is not synced with the face selection in the
viewport.
This happens because the extraction, despite being in edit mode, is set
to `MESH` instead of `BMESH` (or `MAPPED` in some cases) like for CPU
subdivision, and since the mesh is not always synchrnised with the BMesh
the edit mode flags are not always updated.
With GPU subdivision, when creating the `MeshRenderData`, the condition
`has_mdata && do_final && editmesh_eval_final != editmesh_eval_cage` is
true which forces the `MESH` extraction. Following comment in D14485,
this replace the `has_mdata` in the condition with `use_mapped` which
solves the issue.
Differential Revision: https://developer.blender.org/D15248
Addendum to previous fix, which was for point selection, this fixes the
face selection mode. The issue is caused by wrong flags used for paint
mode (the edit mode flag was always used). Also add back flag which was
accidentally removed in 16f5d51109.
Issue is caused by an off by one error which would map some edge loops to
the loops of some the next polygon in the list of polygon, which may not
be a topological neighbor.
Previously the attribute name was only stored in the request for curves.
Instead, pass it as part of the "add request" function, so that it is
always used. Since the whole attribute pipeline is name-based,
this can simplify code in a few places.
- Remove unnecessary braces in switch statements
- Move `default` to the end of other switch items
- Use camel case for type names
- Use `BLI_assert_unreachable()`
Instancing with geometry nodes uses just the evaluated Mesh, and ignores the
Object that it came from. That meant that it would try to look up the subsurf
modifier on the instancer object which does not have the subsurf modifier.
Instead of storing a session UUID and looking up the modifier data, store a
point to the subsurf modifier runtime data. Unlike the modifier data, this
runtime data is preserved across depsgraph CoW. It must be for the subdiv
descriptor contained in it to stay valid along with the draw cache.
As a bonus, this moves various Mesh_Runtime variables into the subsurf runtime
data, reducing memory usage for meshes not using subdivision surfaces.
Also fixes T98693, issues with subdivision level >= 8 due to integer overflow.
Differential Revision: https://developer.blender.org/D15184
The normals flags were not setup properly which made normals for all
elements (vertices, faces) to be drawn when using the normals overlay.
Also remove usage of uints for the flag in the APIs.
This patch adds support for PBVH drawing in EEVEE.
Notes:
# PBVH_FACES only. For Multires we'll need an API to get/cache attributes. DynTopo support will be merged in later with sculpt-dev's DynTopo implementation.
# Supports vertex color and UV attributes only; other types can be added fairly easily though.
# Workbench only sends the active vertex color and UV layers to the GPU.
# Added a new draw engine API method, DRW_cdlayer_attr_aliases_add. Please review.
# The vertex format object is now stored in the pbvh.
Reviewed By: Clément Foucault & Brecht Van Lommel & Jeroen Bakker
Differential Revision: https://developer.blender.org/D13897
Ref D13897
This was caused by the `copy_m4_m4` trying to copy the `object_to_texture`
from `drw_grid` which was `nullptr`.
Fixing this also exposed that rendering such volumes (without any valid
grid attributes) is not supported and we should follow what Cycles does.
Differential Revision: https://developer.blender.org/D15147
Viewport drawing does not support a per point radius attribute yet.
Instead, it has a fixed set of radius parameters that are used for all
curves in the same object. Now those radii are retrieved from the
radius attribute of the points on the first curve. This allows users
to control the radius of curves to some degree until proper per-point
radius is supported.
Good side effect of the change is that it makes it so that the
size of an array is more likely to be calculated at a compile time.
More ideally we'll be using bli::Array instead of the bare array,
but that is outside of the scope of this change.
After this commit, all mesh data extraction and drawing code is in C++,
including headers, making it possible to use improved types for future
performance improvements and simplifications.
The only non-trivial changes are in `draw_cache_impl_mesh.cc`,
where use of certain features and macros in C necessitated larger
changes.
Differential Revision: https://developer.blender.org/D15088
Also fix formating of `curves_attribute_element_id` which was copy pasted.
# Conflicts:
# source/blender/draw/engines/eevee_next/shaders/eevee_attributes_lib.glsl
Although reusing the same patch coordinate for all corner pointing the
same vertex works for interpolation vertices, it does work for
interpolation face varying attributes. So we need to keep the original
patch coordinates around for face varying interpolation. This was caused
by the previous fix (a5dcae0c64).
Also cleaned up the code a tad bit. Note that I
found two more bugs:
* GPU subdivision attribute interpolation
is producing visual artifacts.
* "Show on cage" mode for subdivision surface
just shows black colors.
Issues stems from the mesh not being watertight. This was caused by
floating point precision issues when evaluating patch coordinates at
patch boundaries (loops/corners in different patches pointing to the same
vertex). To fix this we ensure that all loops pointing to the same vertex
share the same patch coordinate. This keeps code simple, and does not
require to track precision issues in floating point math all over the
place.
