| Age | Commit message (Collapse) | Author |
|---|
|
This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
|
|
|
|
Many ui features for geometry nodes need access to information generated
during evaluation:
* Node warnings.
* Attribute search.
* Viewer node.
* Socket inspection (not in master yet).
The way we logged the required information before had some disadvantages:
* Viewer node used a completely separate system from node warnings and
attribute search.
* Most of the context of logged information is lost when e.g. the same node
group is used multiple times.
* A global lock was needed every time something is logged.
This new implementation solves these problems:
* All four mentioned ui features use the same underlying logging system.
* All context information for logged values is kept intact.
* Every thread has its own local logger. The logged informatiton is combined
in the end.
Differential Revision: https://developer.blender.org/D11785
|
|
|
|
|
|
This adds a viewer node similar to the one in the compositor.
The icon in the headers of nodes is removed because it served
the same purpose and is not necessary anymore.
Node outputs can be connected to the active viewer using
ctrl+shift+LMB, just like in the compositor. Right now this collides
with the shortcut used in the node wrangler addon, which will
be changed separately.
As of now, the viewed geometry is only visible in the spreadsheet.
Viewport visualization will be added separately.
There are a couple of benefits of using a viewer node compared
to the old approach with the icon in the node header:
* Better support for nodes that have more than one geometry output.
* It's more consistent with the compositor.
* If attributes become decoupled from geometry in the future,
the viewer can have a separate input for the attribute to visualize.
* The viewer node could potentially have visualization settings.
* Allows to keep "visualization points" around by having multiple
viewer nodes.
* Less visual clutter in node headers.
Differential Revision: https://developer.blender.org/D11470
|
|
|
|
|
|
|
|
editor dataset region always showed 0. This was caused by a conditional
statement that needed a domain to be set, which is not the case for
Instances component type.
Reviewer: Hans Goudey (Hoogly Boogly)
Differential Revision: https://developer.blender.org/D11710
|
|
This patch adds a left aligned sidebar to the spreadsheet editor. This
Sidebar can be used to navigate the geometry component types and
attribute domains. It also provides a quick overview of domain sizes.
It replaces the two dropdowns in the regions header.
Next step will be to add the domain cycling shortcut
using the CTRL + mouse wheel.
Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin),
Hans Goudey (HooglyBoogly).
Differential Revision: https://developer.blender.org/D11046
|
|
|
|
The spreadsheet filter tried to apply the mesh selection filter on non-
mesh geometry components. Add a check for the component type,
and also refactor the function to be more easily readable.
|
|
|
|
This patch adds support for filtering rows based on rules and values.
Filters will work for any attribute data source, they are a property
of the spreadsheet rather than of the attribute system. The properties
displayed in the row filter can depend on data type of the currently
visible column with that name. If the name is no longer visible, the
row filter filter is grayed out, but it will remember the value until
a column with its name is visible again.
Note: The comments in `screen.c` combined with tagging the sidebar
for redraw after the main region point to a lack of understanding
or technical debt, that is a point to improve in the future.
**Future Improvements**
* T89272: A search menu for visible columns when adding a new filter.
* T89273: Possibly a "Range" operation.
Differential Revision: https://developer.blender.org/D10959
|
|
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
|
|
This reverts commit fd94e033446c72fb92048a9864c1d539fccde59a.
does not compile against latest master.
|
|
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
|
|
The little chevron tab to open a hidden region wouldn't show up in the
Spreadsheet editor. Cause was an incorrect GPU-scissor usage:
While drawing regions, the scissors should be kept enabled, just the
scissor rectangle should be updated - and afterwards reset to what it
was before.
|
|
The main goal of this refactor is to not store Object/Collection
pointers for every individual instance. Instead instances now
store a handle for the referenced data. The actual Object/Collection
pointers are stored in a new `InstanceReference` class.
This refactor also allows for some better optimizations further down
the line, because one does not have to search through all instances
anymore to find what data is instanced.
Furthermore, this refactor makes it easier to support instancing
`GeometrySet` or any other data that has to be owned by the
`InstancesComponent`.
Differential Revision: https://developer.blender.org/D11125
|
|
Mostly the interesting information about the instances IDs whether they
are -1 or not, but it's still worth displaying them in the editor.
In the future when we can hide or show colums, we could decide to hide
this one by default.
Differential Revision: https://developer.blender.org/D11104
|
|
|
|
Differential Revision: https://developer.blender.org/D11108
|
|
|
|
Differential Revision: https://developer.blender.org/D11056
|
|
Differential Revision: https://developer.blender.org/D11011
|
|
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
|
|
|
|
Internally we use the name "context (path)" instead of "breadcrumb".
This was missing from a rename in the original patch.
|
|
This introduces a context path to the spreadsheet editor, which contains
information about what data is shown in the spreadsheet. The context
path (breadcrumbs) can reference a specific node in a node group
hierarchy. During object evaluation, the geometry nodes modifier checks
what data is currently requested by visible spreadsheets and stores
the corresponding geometry sets separately for later access.
The context path can be updated by the user explicitely, by clicking
on the new icon in the header of nodes. Under some circumstances,
the context path is updated automatically based on Blender's context.
This patch also consolidates the "Node" and "Final" object evaluation
mode to just "Evaluated". Based on the current context path, either
the final geometry set of an object will be displayed, or the data at
a specific node.
The new preview icon in geometry nodes now behaves more like
a toggle. It can be clicked again to clear the context path in an
open spreadsheet editor.
Previously, only an object could be pinned in the spreadsheet editor.
Now it is possible to pin the entire context path. That allows two
different spreadsheets to display geometry data from two different
nodes.
The breadcrumbs in the spreadsheet header can be collapsed by
clicking on the arrow icons. It's not ideal but works well for now.
This might be changed again, if we get a data set region on the left.
Differential Revision: https://developer.blender.org/D10931
|
|
|
|
|
|
This also fixes the issue that the width of the "Name" column
when viewing instances does not resize correctly.
Differential Revision: https://developer.blender.org/D10926
|
|
|
|
|
|
A `DataSource` provides columns for the spreadsheet to display.
Every column has a SpreadsheetColumnID as identifier. Columns
are not generated eagerly anymore, instead the main spreadsheet
code can request a column from a data source with an column
identifier. The column identifiers can be stored in DNA and allow us
to store persistent data per column.
On the user level the only thing that changes is that columns are
not shown in alphabetical order anymore. Instead, new columns
are always added on the left. The behavior can be changed,
however I'd prefer not to automate this too much currently. I think
we should just add operators to hide/reorder/resize columns soonish.
Differential Revision: https://developer.blender.org/D10901
|
|
Previously, the spreadsheet editor could only show data of the original
and of the final evaluated object. Now it is possible to show the data
at some intermediate stages too.
For that the mode has to be set to "Node" in the spreadsheet editor.
Furthermore, the preview of a specific node has to be activated by
clicking the new icon in the header of geometry nodes.
The exact ui of this feature might be refined in upcoming commits.
It is already very useful for debugging node groups in it's current
state though.
Differential Revision: https://developer.blender.org/D10875
|
|
Aligning spreadsheet Booleans to the middle of their cells.
Differential Revision: https://developer.blender.org/D10882
Reviewed by Hans Goudey
|
|
Aligning spreadsheet cell numbers to the right to aid readability.
Differential Revision: https://developer.blender.org/D10871
Reviewed by Hans Goudey
|
|
Differential Revision: https://developer.blender.org/D10857
|
|
|
|
Replacing a hard-coded font size with font style widget size so it can be set by user.
Differential Revision: https://developer.blender.org/D10819
Reviewed by Dalai Felinto
|
|
This patch renames two domains:
* `Polygon` -> `Face`
* `Corner` -> `Face Corner`
For the change from `polygon` to `face` I did a "deep rename" where I updated
all (most?) cases where we refere to the attribute domain in code as well.
The change from `corner` to `face corner` is only a ui change. I did not see
a real need to update all code the code for that. It does not seem to improve
the code, more on the contrary.
Ref T86818.
Differential Revision: https://developer.blender.org/D10803
|
|
|
|
We cannot use `std::variant` yet, because not all of the compilers
we support have a working version of it yet. For now, I just replaced
it with multiple `std::option` which is good enough, because currently
`CellValue` is only used for the cells that are actually drawn in
the spreadsheet.
|
|
|
|
This patch adds data about instances generated by geometry nodes
to the spreadsheet. The transform data is decomposed into position,
rotation, and scale, and there is a name column to display the name
of the instanced object or collection.
This data is implemented specifically for the spreadsheet, because
we're not sure that we want to expose this data as attributes for the
use elsewhere.
Differential Revision: https://developer.blender.org/D10770
|
|
|
|
`std::get` does not seem to be available. Using `std::get_if` might work instead.
(Found the error on the buildbot.)
|
|
This is a refactor and no functional changes are expected.
The goal is to make it simpler to add other data sources without having
to repeat the drawing code everywhere. Also, having the `CellValue` class
allows us to implement filtering and sorting in a more generic way.
|
