Geometry Nodes: Set Position node uses implicit position for "Offset" mode, causing unintended displacement #92348

Closed
opened 2021-10-19 18:37:40 +02:00 by RoyTheKoi · 20 comments

System Information
Operating system: macOS Big Sur 11.2.3
Graphics card: AMD Radeon Pro 5500M 8 GB

Blender Version
Broken: 3.0 Alpha, 4a00faca1a, master, 2021-10-16
Worked: Unkown

Short description of error
Currently the "Set Position" node uses the point position as an implicit input when nothing is connected. This is desirable when not using the "Offset" mode, as it prevents the geometry from all being instantly moved to the origin.

However this implicit position remains even when the "Offset" toggle is enabled, causing each point to be displaced outwards by its own position, effectively scaling the entire object by 2x. The effect is worsened when using selections, as some points default to their own position and others default to a displaced position.

I assume the intended behaviour is to use (0,0,0) instead when "Offset" is enabled, such that no changes to the geometry occur by default, regardless of the mode.

Set_position_offset_off.png
Set_position_offset_on.png

Exact steps for others to reproduce the error

  1. Add a geometry nodes modifier to the default cube
  2. Insert a "Set Position" node between the group input and output.
  3. Toggle the "Offset" checkbox on, notice the cube scales up by 2.
**System Information** Operating system: macOS Big Sur 11.2.3 Graphics card: AMD Radeon Pro 5500M 8 GB **Blender Version** Broken: 3.0 Alpha, 4a00faca1a5e, master, 2021-10-16 Worked: Unkown **Short description of error** Currently the "Set Position" node uses the point position as an implicit input when nothing is connected. This is desirable when not using the "Offset" mode, as it prevents the geometry from all being instantly moved to the origin. However this implicit position remains even when the "Offset" toggle is enabled, causing each point to be displaced outwards by its own position, effectively scaling the entire object by 2x. The effect is worsened when using selections, as some points default to their own position and others default to a displaced position. I assume the intended behaviour is to use (0,0,0) instead when "Offset" is enabled, such that no changes to the geometry occur by default, regardless of the mode. ![Set_position_offset_off.png](https://archive.blender.org/developer/F11289304/Set_position_offset_off.png) ![Set_position_offset_on.png](https://archive.blender.org/developer/F11289300/Set_position_offset_on.png) **Exact steps for others to reproduce the error** 1. Add a geometry nodes modifier to the default cube 2. Insert a "Set Position" node between the group input and output. 3. Toggle the "Offset" checkbox on, notice the cube scales up by 2.
Author

Added subscriber: @RoyTheKoi

Added subscriber: @RoyTheKoi
Member

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Member

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123
Contributor

Added subscriber: @Eary

Added subscriber: @Eary
Contributor

I actually liked this behaviour a lot though. Right now checking that check box will visually change the mesh and the user can understand straight up what's going on, Checking that box literally has a visual feedback of the mesh being offsetted. If checking the check box disables the implicit position field, then the user checking that box will not do anything visually, the user might have a harder time understanding what is going on

I actually liked this behaviour a lot though. Right now checking that check box will visually change the mesh and the user can understand straight up what's going on, Checking that box literally has a visual feedback of the mesh being offsetted. If checking the check box disables the implicit position field, then the user checking that box will not do anything visually, the user might have a harder time understanding what is going on
Author

At the moment, someone who doesn't know about implicit position being used would not know why the mesh scales up arbitrarily, despite nothing connected to the input port. One would think that if no offset vector is passed in, there should simply not be an offset. Offsetting each point by its own position by default is confusing and not very useful.

As far as I can tell, the implicit position input was added to the set position node specifically to prevent unexpected changes to the geometry when there is no explicit input (D12553). Right now there is no change by default when offset is off, I believe the same should be true even when offset is on.

If seeing feedback is the goal, all a user would have to do is to plug something into the position input. Changes to the geometry would then make intuitive sense.

At the moment, someone who doesn't know about implicit position being used would not know why the mesh scales up arbitrarily, despite nothing connected to the input port. One would think that if no offset vector is passed in, there should simply not be an offset. Offsetting each point by its own position by default is confusing and not very useful. As far as I can tell, the implicit position input was added to the set position node specifically to prevent unexpected changes to the geometry when there is no explicit input ([D12553](https://archive.blender.org/developer/D12553)). Right now there is no change by default when offset is off, I believe the same should be true even when offset is on. If seeing feedback is the goal, all a user would have to do is to plug something into the position input. Changes to the geometry would then make intuitive sense.
Contributor

I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default.

If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node.

It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off.

I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default. If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node. It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off.

Added subscriber: @erik85

Added subscriber: @erik85

In #92348#1238730, @Eary wrote:
I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default.

If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node.

It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off.

Why would anything change though? The user can see that nothing is connected to the "position"-input and therefore nothing should change regardless of the offset setting in my opinion.

> In #92348#1238730, @Eary wrote: > I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default. > > If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node. > > It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off. Why would anything change though? The user can see that nothing is connected to the "position"-input and therefore nothing should change regardless of the offset setting in my opinion.
Contributor

If that's the point then probably it should just not use implicit position field at all, So default would be collapsed into one point, checking that offset checkbox would turn the model back to normal.
In my opinion, either that or keep the current behavior

If that's the point then probably it should just not use implicit position field at all, So default would be collapsed into one point, checking that offset checkbox would turn the model back to normal. In my opinion, either that or keep the current behavior
Author

In #92348#1238730, @Eary wrote:
I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default.

I think having the geometry scale up by 2x is just as unwanted as collapsing everything to a point. If someone wanted that they could use a transform node instead.

If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node.

I imagine a new user might try to plug something into the position input before giving up on the node altogether. It makes more sense for the node not to change the geometry until an explicit input is given.

Also, if a new user is confused, they can easily check the documentation where the node should be clearly explained.

It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off.

Tutorial makers can explain that the node does nothing until an input is connected. This is a simple explanation and makes the most intuitive sense to me.

> In #92348#1238730, @Eary wrote: > I believe that is more because almost nobody wants to collapse your model on the one point, so they just trying to prevent the node from doing so by default. > I think having the geometry scale up by 2x is just as unwanted as collapsing everything to a point. If someone wanted that they could use a transform node instead. > If checking the offset checkbox doesn't really change how the mesh look, a new user doesn't know anything about implicit position field would just be confused about why this checkbox does not work at all, In many of them might just give up trying to figure out and just went on to the next node. I imagine a new user might try to plug something into the position input before giving up on the node altogether. It makes more sense for the node not to change the geometry until an explicit input is given. Also, if a new user is confused, they can easily check the documentation where the node should be clearly explained. > > It also makes more sense to keep the current behavior that way from a tutorial maker perspective. Explaining why this node is based on position by default is so much easier to explain why this checkbox does not change when you keep turn it on and off. Tutorial makers can explain that the node does nothing until an input is connected. This is a simple explanation and makes the most intuitive sense to me.
Contributor

Okay I see your point here, I think I am fine with this then

Okay I see your point here, I think I am fine with this then
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Member

I'd be fine with changing the behavior, but it's a bit tricky implementation wise. We could make it work by turning the Offset input socket into an enum on the node and having separate Position and Offset sockets.

I'd be fine with changing the behavior, but it's a bit tricky implementation wise. We could make it work by turning the Offset input socket into an enum on the node and having separate Position and Offset sockets.
Member

Hans had an idea for a good alternative. We could just have separate Position and Offset vector sockets that are always there. Will create a patch for that.

Hans had an idea for a good alternative. We could just have separate Position and Offset vector sockets that are always there. Will create a patch for that.
Author

Separate position and offset sockets sounds like a good solution. My only question is would the position and offset vectors both be evaluated before moving the geometry, or would they each be evaluated and applied one after the other?

Separate position and offset sockets sounds like a good solution. My only question is would the position and offset vectors both be evaluated before moving the geometry, or would they each be evaluated and applied one after the other?
Member

They will be evaluated at the same time, so before moving the geometry.

They will be evaluated at the same time, so before moving the geometry.
Author

Ok great. Thanks Jacques!

Ok great. Thanks Jacques!

This issue was referenced by b3ca926aa8

This issue was referenced by b3ca926aa8e1a2ea26dc5145cd361c211d786c63
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Jacques Lucke self-assigned this 2021-10-25 13:19:35 +02:00
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
6 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#92348
No description provided.