It would be nice if the Switch node displayed a check box when exposed in the modifier stack, instead of this bar field with 0 to 1. It would be more intuitive of what it does.
9 Likes
Uh, planned?
This patch is from October 11, 2021: ⚙ D12816 Geometry Nodes: Use checkbox for exposed boolean sockets
It is now November 1, 2022, more than a year later. What is such a big obstacle to implement this, that a patch, which is not over a year old is still not approved?
It’s not approved since the patch is not up for review, the submitter of the patch retracted it when they changed the state to “Changes Planned”
I know the devs are busy with a ton of stuff, but do they really rely on patches from contributors for such small features? I mean to fix this, wouldn’t it be the matter of a few lines of code? Probably takes less time for the reviewer to correct it by himself, instead of reviewing someone else’s patch…
1 Like
Perhaps, but last time we had a thread on small papercuts, it ballooned into a 4000+ post thread, the supply of “Ohh it’s just a few lines of code! you could do this one thing quickly! why are you not doing this?!” style issues is seemingly endless. (That sometimes turn out to be not just a few lines of code, but have rather large design issues attached to them)
Priorities have to be set, and currently they are set in a way where core devs spend more time on larger projects.
6 Likes
Well, that’s unfortunately just the official, bureaucratic answer. I was kinda hoping for a true answer, along the lines of “It was a temporary solution, but it was decided some more global, future proof solution is needed.”
The fact that relatively minor patches (the one linked literally adds just couple dozen lines of code) from the code standpoint, but major from the user experience standpoint, in a finished state, can be forgotten just because the phabricator task ended up stuck in some ambiguous “changes planned” state signifies some deeper organizational issues, if there’s no other proper explanation for it.
This also isn’t about priorities or time spent based on the size of the project. That patch seems finished, or at least it seems it that way to us, users. So if no explanation as to why it did not simply end up in master is given, it looks very confusing from the outside.
If you scroll down a bit below the comments you can find “Stack”, which shows the other patches that one depends on:
In this case it depends on actually adding the boolean custom data type, which is not trivial. Though I updated the patch today. Beyond that, the explanation usually isn’t too complicated, the many other things I’ve been working on took precedence until I got back to it. That applies to most other similar situations.
12 Likes
Yeah, this is the kind answer I was hoping for. It’s just a bit disappointing from the user point of view, as people may easily end up thinking that we could have had checkboxes instead of integers in the GN modifier UI for a whole year already, if the process did not get stuck.
I meant “devs know about this issue” let say 
It’s just a bit disappointing from the user point of view, as people may easily end up thinking that we could have had checkboxes instead of integers in the GN modifier UI for a whole year already, if the process did not get stuck.
All modifiers used to be drawn in python! It looks like the switch to C++ for the interface code has backlashed on them? 
I wonder why they stopped using python
If we compare to Houdini layout editor, this problem could be resolved with this trick:
( It has been proposed multiple times in this thread AFAIK )
5 Likes
I think it’s not really a ‘switch to C++ for the interface’. It’s more like ‘the interface is autogenerated from the geonodes modifier inputs’. A python UI layout doesn’t really help when the ui depends on what nodes the user decides to expose as input. All the other modifiers have a fixed UI which doesn’t change depending on a nodegroup.
You could do the autogeneration in python instead of C++. But i’m not sure that’s really easier per-se.
3 Likes
In Blender, being unable to edit material without having object which has the material selected never made sense. But now, with GN it’s even more problematic. When user has a GN object which uses some Set Material nodes, how is the user supposed to edit those materials? Placing temporary cubes into the scene and assigning the material to them to edit it is getting increasingly more embarrassing. Are there any plans to solve this in the near future?
5 Likes
It’s a bit clumsy indeed. Though why would you add random cubes instead of material slots to the object itself?
1 Like
I export most of what I create into Unreal Engine, where material slot material names as well as their order matters. Having unassigned materials on the object is a huge room for error once live GN object gets converted to static mesh. If I add a cube, I am not modifying the material slot assignment on the object I care about, so once I apply the GN modifier to a copied version, I don’t have to keep yet another one of dozen failsafe checks in my mind.
3 Likes
Funny, it’s possible via python
material_name = "Blue"
import bpy
#you'll exec this from the text editor area, we need to find node editor area
area = None
for a in bpy.context.window.screen.areas:
if (a.type =="NODE_EDITOR"):
area = a
break
#find header space
header = a.spaces[0]
#pin!
header.pin = True
#we are not longer dependent on the context object and we can define a datablock independently
header.node_tree = bpy.data.materials[material_name].node_tree
1 Like
Does anyone know if it is planned to add a label and a separator for the Geometry Nodes’ exposed parameters?
It would better help organize them when they start becoming too many…
5 Likes
I just noticed the tesselation node D13515 hasn’t been added to master yet. What’s up with it?
Also, I’m in desperate need of tesselation right now for a project 
. So… are they workarounds for distributing and deforming a geometry on the surface of another?
I have nodes @Astronet but I can’t share them here (.blend and .zip are not allowed?)
we can capture the face corner per face, and interpolate them for a quad,
however for triangle projection I need barycentric transform wrapped in a node.
I tagged you over at blender.chat* / everything nodes
1 Like
with barycentric transform wrapped, we have the new topology nodes,
should make this action ‘tesselate’ able to be a node group.
for the ‘merge’ we can use vertex on ‘edges with less than 2 faces’
and ‘compare only to other islands’ for merging.
‘merge with other island node’ could be a nice thing for many use cases beyond this
1 Like
That was fast! Thank you @Jacob_Merrill
I was just about to edit my comment that I found a solution here: (Higgsas) Geometry Nodes Groups Blender 3.1/3.0 - #50 by higgsas - Tutorials, Tips and Tricks - Blender Artists Community
I still don’t understand how this is even possible yet haha so thanks for the blend file. I’ll check it out as well