Page MenuHome

Attribute spreadsheet for attribute debugging
Needs Triage, NormalPublicDESIGN


We need a design for the editor/region where users will inspect their "node-tree" data.

  • Needs inspection, not necessarily editing, but it would be nice to edit it.
  • It could support non-node data as well. (e.g., to inspect a whole mesh).
  • It should be able to inspect not only the end of the node-tree, but a snapshot of it (a socket or link).
  • Instances are to be shown as instance- meaning, the user can use that editor to find which part of the tree is forcing the instances to be made real (e.g., by inspecting one socket at a time).

Note: There is already an experimental implementation, but it uses the outliner: D8637.


It still needs a mockup.

This is a new editor that allows users to inspect the (geometry) data of the active object/node. It focus on showing one data set at a time, so there is no mixing of volume and mesh data, or even face and vertices data. It supports different filters, both to slice the spreadsheet table "horizontally" or "vertically".

Complete Specifications

Those are options based on the use case where we are looking only at geometry data. In the future this can also support multiple objects (e.g., to edit the power of different lights).

  • Spreadsheet Editor - pinning supported
  • Context Data - which data to show
    • Object - The active object fully evaluated (with all its modifiers).
    • Modifier - The active modifier of the active object.
    • Original object - The active object original data.
    • Node - The active node of the active modifier of the active object.
  • Domain
    • Mesh → Vertex
    • Mesh → Edge
    • Mesh → Face
    • Mesh → Corner
    • Volume Grid → Voxels
    • Point Cloud → Points
    • Hair → Strand
  • Vertical Filter
    • Attribute Names (bonus if it supports wildcards: MyAttri*)
    • Category (Built-in, User, Nodes)
    • Data-Type (Float, Vector) [not sure we need this]
  • Horizontal Filter
    • Selected mesh
    • Attribute value (for instance a range)
    • Geometry Tag (e.g., vertex groups, but also eventually more limited boolean only tags T85369
  • Decoration
    • Units
    • Color as floats
    • Vector as floats

Minimum Viable Product

What is the initial target to make this useful and master-ready:

  • New Editor - "Spreadsheet".
  • Read-only - no way to edit values.
  • Only working for the active object fully evaluated - no active node, no active modifier.
  • Only mesh data, only vertices
  • Row filter: "(edit mesh) selected"
  • Editor icon

Event Timeline

Mockup for the MVP


Note: seam is just an example of a boolean value. It is not supported by vertices.

in addition to those stats (colums/rows total/visible), i suggest to add attributes count total/visible

On the topic of the header row for vector attributes

This is the original prototype from Brecht. I don't have a strong feeling about the black background, but I think the way the attribute name isn't repeated for every axis is really nice

Does anyone using the spreadsheet editor not understand the implicit XYZ order of vectors? I don't think we have to include it, and this provides the benefits:

  • Attributes with long names don't take up way too much space
  • There are fewer vertical lines, making the editor less noisy
  • The only lines are between attributes, making it easier to make the distinction further down in the sheet
  • We don't have the ugly capital X Y Z after the lowercase attribute name : P

One thing I can't see on any of the designs is that I'd expect to be able to click a header to sort a column.

Another nice-to-have would be the ability to drag columns to reorder them horizontally. Use case might be if you've created some burner attributes during a calculation and really you just want to focus on your final attributes. Or checking between two calculations and you want to check two specific columns against each other.

I agree with the implicit XYZ too. I think showing "Position X" would lead some people to try calling it as an attribute rather than knowing to separate the Position vector.
Maybe keep all entries to 3 decimal places as well for floats.

I agree with the implicit XYZ too. I think showing "Position X" would lead some people to try calling it as an attribute rather than knowing to separate the Position vector.

If it becomes necessary to do so however you could do: "position.x" or "position[x]".

Drag and drop would obviously be nice here, but you can probably also understand why it's not a priority for the initial version.

The sorting thing might not have been mentioned yet, but we will definitely have a triangle for sorting a column, just also not in the initial version.