Naming of the "anonymous attribute" concept #91051

Open
opened 2021-08-30 11:34:02 +02:00 by Jacques Lucke · 10 comments
Member

"Anonymous attributes" are an important part of what makes the fields proposal so much easier to use compared to what we currently have in master. We have not made a formal decision on what we want to call them in Blender 3.0 yet.
Also, when choosing how to call "anonymous attributes" we should also think about how to call "non-anonymous attributes".

Possible names for "anonymous attributes":

  • Anonymous attributes: Highlights the fact that one does not have to name these attributes manually.
  • Static attributes: Highlights the fact that they are only propagated when the geometry changes. Besides propagation they are read-only.
  • Temporary attributes: Highlights the fact that they are automatically deleted when they are not used anymore.
  • Scoped attributes: Similar to "temporary attributes".
  • Internal attributes: Highlights the fact that they will be gone after the current geometry nodes context ends. They cannot be used when sending data to other software.
  • Unnamed attributes.
  • Transient attributes.
  • Local attributes.
  • Nameless attributes.

Possible names for "non-anonymous attributes":

  • Named attributes: Highlights the fact that they have to be named explicitly.
  • Persistent attributes: Highlights the fact that they are not automatically removed.
  • Dynamic attributes: Highlights the fact that these attributes can be modified by the user at any point.
  • Interface attributes: Highlights the fact that they can be used to retrieve data from and send data to other systems.
"Anonymous attributes" are an important part of what makes the fields proposal so much easier to use compared to what we currently have in master. We have not made a formal decision on what we want to call them in Blender 3.0 yet. Also, when choosing how to call "anonymous attributes" we should also think about how to call "non-anonymous attributes". Possible names for "anonymous attributes": * Anonymous attributes: Highlights the fact that one does not have to name these attributes manually. * Static attributes: Highlights the fact that they are only propagated when the geometry changes. Besides propagation they are read-only. * Temporary attributes: Highlights the fact that they are automatically deleted when they are not used anymore. * Scoped attributes: Similar to "temporary attributes". * Internal attributes: Highlights the fact that they will be gone after the current geometry nodes context ends. They cannot be used when sending data to other software. * Unnamed attributes. * Transient attributes. * Local attributes. * Nameless attributes. Possible names for "non-anonymous attributes": * Named attributes: Highlights the fact that they have to be named explicitly. * Persistent attributes: Highlights the fact that they are not automatically removed. * Dynamic attributes: Highlights the fact that these attributes can be modified by the user at any point. * Interface attributes: Highlights the fact that they can be used to retrieve data from and send data to other systems.
Author
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

Those lists include all the options I've thought of. Personally I like the combination of "Anonymous Attributes" and "Named Attributes".

  • The fact that anonymous attributes don't propagate outside of the node tree is obvious, because you pass them with node links, which you can only use in the node editor.
  • The fact that they propagate as the geometry changes is already clear since you can plug them in later on in the node tree-- that's intuitive.
  • It uses the name-- which is an important step a user takes when creating a named attribute
  • It's an understandable difference, using words that are clearly understandable. This means the naming will stick, people won't start using shorter/easier names that make conversation less clear.
  • We've already been using these names, there's something to that!
Those lists include all the options I've thought of. Personally I like the combination of "Anonymous Attributes" and "Named Attributes". - The fact that anonymous attributes don't propagate outside of the node tree is obvious, because you pass them with node links, which you can only use in the node editor. - The fact that they propagate as the geometry changes is already clear since you can plug them in later on in the node tree-- that's intuitive. - It uses the name-- which is an important step a user takes when creating a named attribute - It's an understandable difference, using words that are clearly understandable. This means the naming will stick, people won't start using shorter/easier names that make conversation less clear. - We've already been using these names, there's something to that!

Added subscriber: @MadMinstrel

Added subscriber: @MadMinstrel

I suggest Transient Attributes. It has a similar meaning as temporary, but is two syllables less and rolls off the tongue much more easily.

I suggest Transient Attributes. It has a similar meaning as temporary, but is two syllables less and rolls off the tongue much more easily.
Contributor

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Contributor

My vote would go for Unnamed Attributes and Named Attributes. Majority of the reasoning listed after the names of options is something technical which only someone who understand the internals of geometry nodes will get.

The best way to name something that will be facing the end user in form of the user interface is to think about how would you explain it to someone with 0 prior experience. If someone asks "What does Anonymous Attribute mean?", it's highly likely most people will not use the word "anonymous" to describe their actual mechanism . It will probably be something along the lines "Those are the attributes you create by plugging a node or a tree of nodes inside of an attribute input slot, as opposed to typing the attribute name in it."

So to me, attributes without a name, therefore "unnamed" attributes seems to be the most straightforward term to call them, if you want as wide audience as possible to understand/infer what's being talked about.

That being said, @HooglyBoogly makes a good argument that Anonymous and Unnamed is the terms which are already being used, and they are close enough, so that'd be fine too.

The other names may end up very confusing to people unfamiliar with programming terminology, for example:

  • Static: May mean something that can not move/can not be animated.
  • Temporary: May mean something that will disappear at some point without user intervention, something that won't work after reopening file, or such.
  • Scoped: Someone who isn't familiar with programming may think of a rifle attachment :)
  • Internal: Something deep inside of the Blender, hidden away from the user, which can't be manipulated easily
  • Persistent: Something opposing the temporary, making it seem like it's what you want to use if you want to be sure your work is saved (The fake user datablock stigma)
  • Dynamic: Something opposing the static one, something that can move/can be animated
  • Interface: Something related to user interface. Sounds like special type of attribute for exposing attributes to the top level modifier UI.
My vote would go for Unnamed Attributes and Named Attributes. Majority of the reasoning listed after the names of options is something technical which only someone who understand the internals of geometry nodes will get. The best way to name something that will be facing the end user in form of the user interface is to think about how would you explain it to someone with 0 prior experience. If someone asks "What does Anonymous Attribute mean?", it's highly likely most people will not use the word "anonymous" to describe their actual mechanism . It will probably be something along the lines "Those are the attributes you create by plugging a node or a tree of nodes inside of an attribute input slot, as opposed to typing the attribute name in it." So to me, attributes without a name, therefore "unnamed" attributes seems to be the most straightforward term to call them, if you want as wide audience as possible to understand/infer what's being talked about. That being said, @HooglyBoogly makes a good argument that Anonymous and Unnamed is the terms which are already being used, and they are close enough, so that'd be fine too. The other names may end up very confusing to people unfamiliar with programming terminology, for example: - Static: May mean something that can not move/can not be animated. - Temporary: May mean something that will disappear at some point without user intervention, something that won't work after reopening file, or such. - Scoped: Someone who isn't familiar with programming may think of a rifle attachment :) - Internal: Something deep inside of the Blender, hidden away from the user, which can't be manipulated easily - Persistent: Something opposing the temporary, making it seem like it's what you want to use if you want to be sure your work is saved (The fake user datablock stigma) - Dynamic: Something opposing the static one, something that can move/can be animated - Interface: Something related to user interface. Sounds like special type of attribute for exposing attributes to the top level modifier UI.

If it's going to wind up as Unnamed, at least have pity on tutorial makers and pick Nameless. Easier to say.

If it's going to wind up as Unnamed, at least have pity on tutorial makers and pick Nameless. Easier to say.

Added subscriber: @Florian-10

Added subscriber: @Florian-10

I like "Persistent Attributes" because you can see on the Name what this is.

I like "Persistent Attributes" because you can see on the Name what this is.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#91051
No description provided.