Geometry Nodes: Initial tool-specific nodes #109517
No reviewers
Labels
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
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#109517
Loading…
Reference in New Issue
No description provided.
Delete Branch "HooglyBoogly/blender:operator-selection-node"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add three new nodes for operations and inputs specific to
node group operators.
face, or curve domains
in the local space of the modified object.
and whether the attribute exists.
In the add menu and search, the nodes are only visible in the
"Operator" context of the geometry node editor. They also give
errors when executed by a modifier.
Geometry Nodes: Add input nodes for node group operatorsto WIP: Geometry Nodes: Add input nodes for node group operatorsWIP: Geometry Nodes: Add input nodes for node group operatorsto WIP: Geometry Nodes: Initial operator-specific nodesHans Goudey referenced this pull request2023-06-29 19:18:59 +02:00
WIP: Geometry Nodes: Initial operator-specific nodesto Geometry Nodes: Initial operator-specific nodesWouldn't it make more sense to have Face Set nodes in Mesh - Read or Mesh - Topology (and Set Face Set in Operations)? They can be used in regular node setups and they're specifically mesh attributes
They can only be used in operator node groups. That's because sculpt face sets are with the ".sculpt_face_set" naming convention is UI data, not meant to be used procedurally. Anyway, in regular geometry nodes any face domain integer attribute can be used to serve the same purpose. The thing we're missing is copying face sets to a non-UI attribute, but that is trivial do do with this PR.
Thanks for the clarification. If sculpt_face_sets are to be used procedurally (please), and they'll use the same nodes, I think it makes sense to do that before/alongside this PR, so that nodes won't have to be moved in Add menu categories in the future, but I guess that's quite trivial as well.
That's my point though, the sculpt face sets attribute isn't meant to be used procedurally, and we wouldn't have specific access nodes for them if it was different. The reason to have the access nodes in this PR is that
.sculpt_face_set
is not treated as a regular attribute for geometry nodes.Two things I'll do before committing:
Geometry Nodes: Initial operator-specific nodesto Geometry Nodes: Initial tool-specific nodes@ -0,0 +12,4 @@
static void node_declare(NodeDeclarationBuilder &b)
{
b.add_output<decl::Vector>("Location").subtype(PROP_DISTANCE);
PROP_XYZ
Seems
PROP_TRANSLATION
is the proper subtype here actually (from the set position node)hm, makes sense too I guess
@ -0,0 +27,4 @@
if (!check_tool_context_and_error(params)) {
return;
}
const float4x4 world_to_object(params.user_data()->operator_data->self_object->world_to_object);
Arguably there should be the option to choose between world and object space, a bit similar to the Object Info node. If not, then it should at least be mentioned somewhere what space we're in.
I guess I'd probably save that for later, to keep things simpler for now.
Then add proper descriptions. In the node and in the PR.
@ -0,0 +32,4 @@
const float3 location_global(cursor.location);
const math::Quaternion rotation_global(float4(cursor.rotation_quaternion));
params.set_output("Location", math::transform_point(world_to_object, location_global));
params.set_output("Rotation", math::to_quaternion(world_to_object) * rotation_global);
Only output rotation when it's available, otherwise this hits an assert in debug build.
@ -0,0 +32,4 @@
case GeometryComponent::Type::Mesh:
switch (domain) {
case ATTR_DOMAIN_POINT:
return *attributes.lookup_or_default<bool>(".select_vert", domain, false);
Are all these selection attributes always up to date or do we only keep one of them up to date depending on the selection mode?
The three should always be up to date. When we set one, we interpolate the values to the others to make them consistent too.
Thanks, I fixed the select mode issue in main:
85bac9d292
Using the side selection works now.
Seems to work well in my tests now.
@ -73,6 +74,7 @@ class GatherLinkSearchOpParams {
/** The current node type. */
const bNodeType &node_type_;
const SpaceNode &snode_;
It's probably fine and more future proof to just store the context in here, but either way is fine with me.
Yeah, next time I need something from the context there I'll just do that. For now I think this is a bit clearer.