Geometry Nodes: Is Edit Mode Node #106970

This patch adds a new "Is Edit Mode" node for evaluating if the self_object() is in edit mode. This is useful for GeometryNode creators to optimize their node tree when the node-group user is editing the base mesh.

This idea was requested by my collaborator Baga, his generator is heavy, and he would like to turn down some settings when his users are editing their base mesh.Example.

Status: Finished, Awaiting Design Approval

Two alternative design have been proposed:

Add new string output in the already existing object info node (mockup below)
replace "IsEditMode" with "IsObjectMode"

This patch adds a new "_Is Edit Mode_" node for evaluating if the `self_object()` is in edit mode. This is useful for GeometryNode creators to optimize their node tree when the node-group user is editing the base mesh. This idea was requested by my collaborator [Baga](https://twitter.com/BagattiniAntoi1/status/1646554445306556416), his generator is heavy, and he would like to turn down some settings when his users are editing their base mesh.[Example.](https://twitter.com/BagattiniAntoi1/status/1649413332988837888?s=20) ### Status: Finished, Awaiting Design Approval Two alternative design have been proposed: - Add new string output in the already existing object info node (mockup below) - replace "IsEditMode" with "IsObjectMode"

download.png

11 KiB

Hi, I hope this gets through. I have one concern though. Some Geometry Node systems depend on different objects. With this node you can only check for the object, where the modifier is on. For example the new hair system could not take advantage of this. Maybe add an Object as Input? Though this would make it similar to my approach, which was rejected #106305

Hi, I hope this gets through. I have one concern though. Some Geometry Node systems depend on different objects. With this node you can only check for the object, where the modifier is on. For example the new hair system could not take advantage of this. Maybe add an Object as Input? Though this would make it similar to my approach, which was rejected https://projects.blender.org/blender/blender/pulls/106305.

Hi, I agree it won't be able to cover standalone "empty" objects. Personally, I would much prefer to have a powerful flexible node that could access any data contained within the .blend the user could think of, such as 106989 or my Python Api node.

For example, here's a user optimizing his experience with some simple Python API call. Proposing flexibility is important, the users are not predictable.

But well, that's up to the design team.

PS: link is broken

> Hi, I hope this gets through. I have one concern though. Some Geometry Node systems depend on different objects. With this node you can only check for the object, where the modifier is on. For example the new hair system could not take advantage of this. Maybe add an Object as Input? Though this would make it similar to my approach, which was rejected [https://projects.blender.org/blender/blender/pulls/106305](url). Hi, I agree it won't be able to cover standalone "empty" objects. Personally, I would much prefer to have a powerful flexible node that could access any data contained within the .blend the user could think of, such as [106989](https://projects.blender.org/blender/blender/pulls/106989) or my [Python Api](https://devtalk.blender.org/t/extra-nodes-for-geometrynodes/20942) node. For example, here's a user optimizing his experience with some simple Python API call. ![users_optimizing_his_scene.mp4](https://projects.blender.org/blender/blender/issues/106970/attachments/6adb0d0a-30fc-4724-8470-26128695c865) Proposing flexibility is important, the users are **not** predictable. But well, that's up to the design team. PS: link is broken

2021-12-12 10-28-26.mp4

8.3 MiB

Hi, I hope this gets through. I have one concern though. Some Geometry Node systems depend on different objects. With this node you can only check for the object, where the modifier is on. For example the new hair system could not take advantage of this. Maybe add an Object as Input? Though this would make it similar to my approach, which was rejected https://projects.blender.org/blender/blender/pulls/106305.

Hi, I agree it won't be able to cover standalone "empty" objects. Personally, I would much prefer to have a powerful flexible node that could access any data contained within the .blend the user could think of, such as 106989 or my Python Api node. But well, that's up to the design team.

By the way, what if your patch outputted a string and not an enum int? Maybe that could get a pass
PS: link is broken

I agree, this would be amazing. Link should be fixed. It would be an option, but sadly i think it wasn't rejected because of the output type:

It's honestly a bit unlikely that we'll allow accessing the mode like this, because it's not really something that the procedural setup should depend on. For the time being I'd recommend people to just expose a "Fast Mode" boolean as group input that can be controlled from the modifier or so.

Originally posted by @JacquesLucke in /blender/blender/pulls/106305#issuecomment-911946

> > Hi, I hope this gets through. I have one concern though. Some Geometry Node systems depend on different objects. With this node you can only check for the object, where the modifier is on. For example the new hair system could not take advantage of this. Maybe add an Object as Input? Though this would make it similar to my approach, which was rejected [https://projects.blender.org/blender/blender/pulls/106305](url). > > Hi, I agree it won't be able to cover standalone "empty" objects. Personally, I would much prefer to have a powerful flexible node that could access any data contained within the .blend the user could think of, such as [106989](https://projects.blender.org/blender/blender/pulls/106989) or my [Python Api](https://devtalk.blender.org/t/extra-nodes-for-geometrynodes/20942) node. But well, that's up to the design team. > > By the way, what if your patch outputted a string and not an enum int? Maybe that could get a pass > PS: link is broken I agree, this would be amazing. Link should be fixed. It would be an option, but sadly i think it wasn't rejected because of the output type: > It's honestly a bit unlikely that we'll allow accessing the mode like this, because it's not really something that the procedural setup should depend on. For the time being I'd recommend people to just expose a "Fast Mode" boolean as group input that can be controlled from the modifier or so. _Originally posted by @JacquesLucke in /blender/blender/pulls/106305#issuecomment-911946_

Alternative proposal:

Extending object info mode with additional information.
Similar to #106305 but with a few new string outputs instead of an non-user friendly integer

@Hans The "name" field has come up a bunch of times, but it doesn't work with the depsgraph (yet), unless we want to reevaluate all modifiers when changing the name of any object

Note that the name is not currently supported by geonode depsgraph, but i don't see why it's a big deal to re-evaluate node on rename, rename operations arent't that common

### **Alternative proposal**: Extending object info mode with additional information. Similar to https://projects.blender.org/blender/blender/pulls/106305 but with a few new string outputs instead of an non-user friendly integer ![img](https://projects.blender.org/blender/blender/issues/106970/attachments/48ebcc37-42f1-4a97-bc39-45ee1b58f358) > @Hans The "name" field has come up a bunch of times, but it doesn't work with the depsgraph (yet), unless we want to reevaluate all modifiers when changing the name of any object Note that the name is not currently supported by geonode depsgraph, but i don't see why it's a big deal to re-evaluate node on rename, rename operations arent't that common

Screenshot 2023-04-19 212216.jpg

54 KiB

@dodododorian thanks for the proposal !

It will help optimize performance and enhance the user experience when editing base meshes, especially in large node trees that can be laggy.
Most criticisms directed at this proposal can also be applied to the existing "Is Viewport" node.

The alternative proposal is interesting, but an "Is Edit Mode" node is more consistent with the existing "Is Viewport" node.
An "Is Object Mode" node might be even more desirable, as it could take into account sculpt, edit mode, and other modes.

@dodododorian thanks for the proposal ! It will help optimize performance and enhance the user experience when editing base meshes, especially in large node trees that can be laggy. Most criticisms directed at this proposal can also be applied to the existing "Is Viewport" node. The alternative proposal is interesting, but an "Is Edit Mode" node is more consistent with the existing "Is Viewport" node. An "Is Object Mode" node might be even more desirable, as it could take into account sculpt, edit mode, and other modes.

@Antoine_Bagattini

Is it bad, when different nodes return similar things? Because then we could do a Is Object Mode Node. And maybe laiter add more properties to the object info node, like in the alternative proposial. This would keep it "beginner" friendly, but also give the option for more detailed settings. But I could also imagine, that this would make blender "bloated".

@Antoine_Bagattini Is it bad, when different nodes return similar things? Because then we could do a Is Object Mode Node. And maybe laiter add more properties to the object info node, like in the alternative proposial. This would keep it "beginner" friendly, but also give the option for more detailed settings. But I could also imagine, that this would make blender "bloated".

but also give the option for more detailed settings

The object-mode information as a string output in the object-info node proposal is more flexible & elegant than a simple boolean input IMO

Advantages:

Added behavior control on other modes
Added behavior control on the object source, where the initial proposal is only compatible with self object.
More compact solution ( there's already a lot of nodes )
The mode state is an object information, it makes sense to be shown in the object info node
Gives us the opportunity to propose more string information about the object, such as the name and object type

Inconvenience:

Users will need to conntect an extra self object node and an extra string compare node

> but also give the option for more detailed settings The object-mode information as a string output in the object-info node proposal is more flexible & elegant than a simple boolean input IMO Advantages: - Added behavior control on other modes - Added behavior control on the object source, where the initial proposal is only compatible with self object. - More compact solution ( there's already a lot of nodes ) - The mode state is an object information, it makes sense to be shown in the object info node - Gives us the opportunity to propose more string information about the object, such as the name and object type Inconvenience: - Users will need to conntect an extra self object node and an extra string compare node

Is it bad, when different nodes return similar things?

Not really. I believe that the 'Is Object Mode' node is the best solution.

Alternative proposal:

Extending object info mode with additional information.
Similar to #106305 but with a few new string outputs instead of an non-user friendly integer

It's really nice, but the 'Is Object Mode' is more consistent and easier to use.

> Is it bad, when different nodes return similar things? Not really. I believe that the 'Is Object Mode' node is the best solution. > ### **Alternative proposal**: > > Extending object info mode with additional information. > Similar to https://projects.blender.org/blender/blender/pulls/106305 but with a few new string outputs instead of an non-user friendly integer > > ![img](https://projects.blender.org/blender/blender/issues/106970/attachments/48ebcc37-42f1-4a97-bc39-45ee1b58f358) It's really nice, but the 'Is Object Mode' is more consistent and easier to use.

 @ -35,4 +35,4 @@ License
 Blender as a whole is licensed under the GNU General Public License, Version 3.
 Individual files may have a different, but compatible license.
 See [blender.org/about/license](https://www.blender.org/about/license) for details.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry Nodes: Is Edit Mode Node #106970

Status: Finished, Awaiting Design Approval

Alternative proposal:

Alternative proposal:

Reviewers