This renames `data` and `color` to `selection`. This is better because
it's actually what the corresponding buffers contain. Using this
more correct name makes sharing vertex buffers between different
gpu batches for different shaders easier.
In order to experiment with different storage types for `DRW_Attributes`
and for general cleanup (see #103343). Also move a curves header to C++.
Pull Request #104716
This changes how we access the points that correspond to each curve in a `CurvesGeometry`.
Previously, `CurvesGeometry::points_for_curve(int curve_index) -> IndexRange`
was called for every curve in many loops. Now one has to call
`CurvesGeometry::points_by_curve() -> OffsetIndices` before the
loop and use the returned value inside the loop.
While this is a little bit more verbose in general, it has some benefits:
* Better standardization of how "offset indices" are used. The new data
structure can be used independent of curves.
* Allows for better data oriented design. Generally, we want to retrieve
all the arrays we need for a loop first and then do the processing.
Accessing the old `CurvesGeometry::points_for_curve(...)` did not follow
that design because it hid the underlying offset array.
* Makes it easier to pass the offsets to a function without having to
pass the entire `CurvesGeometry`.
* Can improve performance in theory due to one less memory access
because `this` does not have to be dereferenced every time.
This likely doesn't have a noticable impact in practice.
Differential Revision: https://developer.blender.org/D17025
This refactors how devirtualization is done in general and how
multi-functions use it.
* The old `Devirtualizer` class has been removed in favor of a simpler
solution. It is also more general in the sense that it is not coupled
with `IndexMask` and `VArray`. Instead there is a function that has
inputs which control how different types are devirtualized. The
new implementation is currently less general with regard to the number
of parameters it supports. This can be changed in the future, but
does not seem necessary now and would make the code less obvious.
* Devirtualizers for different types are now defined in their respective
headers.
* The multi-function builder works with the `GVArray` stored in `MFParams`
directly now, instead of first converting it to a `VArray<T>`. This reduces
some constant overhead, which makes the multi-function slightly
faster. This is only noticable when very few elements are processed though.
No functional changes or performance regressions are expected.
Use the same `".selection"` attribute for both curve and point domains,
instead of a different name for each. The attribute can now have
either boolean or float type. Some tools create boolean selections.
Other tools create float selections. Some tools "upgrade" the attribute
from boolean to float.
Edit mode tools that create selections from scratch can create boolean
selections, but edit mode should generally be able to handle both
selection types. Sculpt mode should be able to read boolean selections,
but can also and write float values between zero and one.
Theoretically we could just always use floats to store selections,
but the type-agnosticism doesn't cost too much complexity given the
existing APIs for dealing with it, and being able to use booleans is
clearer in edit mode, and may allow future optimizations like more
efficient ways to store boolean attributes.
The attribute API is usually used directly for accessing the selection
attribute. We rely on implicit type conversion and domain interpolation
to simplify the rest of the code.
Differential Revision: https://developer.blender.org/D16057
Editmode should display the original (non-evaluated) points unless there
is something like an "On Cage" option of a modifier [which none of the
curves modifiers have].
This was not the case since the introduction in rBe15320568a29.
So we now draw the editpoints from the original curves. This also means
that original and evaluated curves might not have the same number of
points, so we have to get independent of `proc_point_buf` since that
would possibly create vertexbuffers of different sizes (compared to the
original curves) which is not allowed for a single batch.
- remove the "pos" alias from the vertex buffer format of proc_point_buf
- instead, create a new "edit_points_pos" vertex buffer
- fill that with the original (un-evaluated) curves positions
- dont request `proc_point_buf` anymore
- rename the editpoints flags buffer to be more consistent
And since original and evaluated points might also be in completely
different positions, we also need to draw connecting lines between those
editpoints to not have them float in thin air. For drawing these in
editmode, a simple polyline was chosen (instead of drawing lines in a
resolution that is take from the old particle system -- which is not
depending on points even but has a hardcoded resolution that can only be
upped by the hair_subdiv scene render setting)
- create appropriate batch and indexbuffer for this
- positions vertex buffer can be reused
- reuse particle edit shader (instead of curve edi shader) to get
segment highlighting
{F14055436}
NOTE: this also removes the broken depth handling and instead makes it
work (also XRay is properly taken into account) by binding the correct
overlay framebuffer.
NOTE: to further clarify the distinction between curves drawing (that is
based on the old partice system drawing) and drawing in editmode, the
corresponding vertexbuffers have been moved out of CurvesEvalCache into
CurvesBatchCache directly.
NOTE: drawing the lines in editmode could be improved (taking the "real"
resolution of splines into account, but since this should happen on the
GPU in a compute shader, this is for later)
Potentionally fixes T101889.
Maniphest Tasks: T101889
Differential Revision: https://developer.blender.org/D16281
Issue was the lifetime of GPUVertFormat & GPUVertAttr.
Both need to be static in the function to be persistent here (and
handled appropriately).
Was an error in rB319ee296fd0c.
Maniphest Tasks: T102966
Differential Revision: https://developer.blender.org/D16704
Points cannot be selected atm in editmode, this patch just shows the
selection from sculptmode in editmode.
Since the selection in sculptmode is a float, a point is considered
selected as soon as the float selection is above 0.0f.
Implementation: this piggy-back on the existing drawing via
overlay_edit_curve_point.glsl which requires a "data" VBO which holds
flags for selection (next to others such as "active" - which we also
have to take care of later).
Differential Revision: https://developer.blender.org/D16021
- Adding in compatibility paths to support minimum per-vertex strides for vertex formats. OpenGL supports a minimum stride of 1 byte, in Metal, this minimum stride is 4 bytes. Meaing a vertex format must be atleast 4-bytes in size.
- Replacing transform feedback compile-time check to conditional look-up, given TF is supported on macOS with Metal.
- 3D texture size safety check added as a general capability, rather than being in the gl backend only. Also required for Metal.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14510
Using geometry nodes with attributes on a curve object and changing the
output is crashing. This is because the `render_mutex` in the curve
drawing cache is cleared after changes in `curves_batch_cache_init` and
set to null. The cache isn't actually needed currently because all draw
updates are single-threaded, but the new `drw_attributes_merge` function
still tries to access it (this seems to be tolerated on Linux platforms
but crashes on Windows).
Make sure the render_mutex is always initialized after (re-)initializing
the cache.
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
This commit adds visualization to the selection in curves sculpt mode.
Previously it was only possible to see the selection when it was
connected to a material.
In order to obstruct the users vision as little as possible, the
selected areas of the curve are left as is, but a dark overlay
is drawn over unselected areas.
To make it work, the overlay requests the selection attribute and then
ensures that the evaluation is complete for curves. Then it retrieves
the evaluated selection GPU texture and passes that to the shader.
This reuses the existing generic attribute extraction system because
there currently wouldn't be any benefits to dealing with selection
separately, and because it avoids duplication of the logic that
extracts attributes from curves and evaluates them if necessary.
Differential Revision: https://developer.blender.org/D15219
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()`
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
This adds support to render Curves attributes in EEVEE.
Each attribute is stored in a texture derived from a VBO. As the
shading group needs the textures to be valid upon creation, the
attributes are created and setup during its very creation, instead
of doing it lazily via create_requested which we cannot rely on
anyway as contrary to the mesh batch, we do cannot really tell if
attributes need to be updated or else via some `DRW_batch_requested`.
Since point attributes need refinement, and since attributes are all
cast to vec4/float4 to account for differences in type conversions
between Blender and OpenGL, the refinement shader for points is
used as is. The point attributes are stored for each subdivision level
in CurvesEvalFinalCache. Each subdivision level also keeps track of the
attributes already in use so they are properly updated when needed.
Some basic garbage collection was added similar to what is done
for meshes: if the attributes used over time have been different
from the currently used attributes for too long, then the buffers
are freed, ensuring that stale attributesare removed.
This adds `CurvesInfos` to the shader creation info, which stores
the scope in which the attributes are defined. Scopes are stored
as booleans, in an array indexed by attribute loading order which
is also the order in which the attributes were added to the material.
A mapping is necessary between the indices used for the scoping, and
the ones used in the Curves cache, as this may contain stale
attributes which have not been garbage collected yet.
Common utilities with the mesh code for handling requested
attributes were moved to a separate file.
Differential Revision: https://developer.blender.org/D14916
Extends the changes started in f31c3f8114 to completely separate
much of the DRW curves code from the particle hair drawing. In the short
term this increases duplication, but the idea is to simplify development
by making it easier to do larger changes to the new code, and the new
system will replace the particle hair at some point.
After this, only the shaders themselves are shared.
Differential Revision: https://developer.blender.org/D14699
This adds support to show dots for the curves points when in edit mode,
using a specific overlay.
This also adds `DRW_curves_batch_cache_create_requested` which for now
only creates the point buffer for the newly added `edit_points` batch.
In the future, this will also handle other edit mode overlays, and
probably also replace the current curves batch cache creation.
Maniphest Tasks: T95770
Differential Revision: https://developer.blender.org/D14262
Rename "size" variables and functions to use "num" instead,
based on T85728 (though this doesn't apply to simple C++
containers, it applies here). Rename "range" to "points" in
some functions, so be more specific.
Differential Revision: https://developer.blender.org/D14431
This part has to be refactored soon anyway, because more types
curves have to be drawn for the new Curves object.
For now, 3 is a better default than 2, because that matches the
actual resolution of the curve currently.
The general idea here is to wrap the `CurvesGeometry` DNA struct
with a C++ class that can do most of the heavy lifting for the curve
geometry. Using a C++ class allows easier ways to group methods, easier
const correctness, and code that's more readable and faster to write.
This way, it works much more like a version of `CurveEval` that uses
more efficient attribute storage.
This commit adds the structure of some yet-to-be-implemented code,
the largest thing being mutexes and vectors meant to hold lazily
calculated evaluated positions, tangents, and normals. That part might
change slightly, but it's helpful to be able to see the direction this
commit is aiming in. In particular, the inherently single-threaded
accumulated lengths and Bezier evaluated point offsets might be cached.
Ref T95355
Differential Revision: https://developer.blender.org/D14054
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
