That’s like saying “I find getting radiation poisoning very useful if I have cancer.” Sure there’s a saying that every cloud has a silver lining, but no software should ever default to bad behavior in hopes it will become useful.
Honestly, what you are saying just makes no sense. The problem here is that this is just straight up faulty prediction of user intention. If the software doesn’t know what user intends to do in a given situation, it should not decide for them. So in this case, it would make sense if the reconnect was separate operator that was triggered by some keyboard shortcut. But it should not be like it is currently, that when it actually does something you want it’s the 1 in 100 luck.
I agree. I simply meant that I didn’t want the feature to be removed completely, because it can be very useful.
You seemed to imply in your earlier posts that you wanted it completely gone.
hi i want to give give little feedback what is super annoying still.
the connecting line in geometry nodes gets invisible if you watching on middle . soi need to zoom out to able to connect the node.
when draging node the window still doesn pan view auto like if you drag the connection of node… why not still ? this is super annoying? and why cant have whole dragoong that you can scroill mouse wheel and so it zooms without need to stop , zoom out, then try to connect again…
if adding new node then need constantly scroll up and down. : ( would be good if no need to scroll up , i mean there anouth space to see all the nodes…
could be connected so know from what section you choosing like in nodes…
Anyone else frustrated by always having to make a garbage geometry node datablock everytime you just want to use existing GN network on another object?
There is currently simply no way to just use GN node network on another object without creating unintended new datablock, and it’s beyond infuriating that just after a mere minutes of using blender, your datablock selector UI looks like this:
The response on the bug tracker is along the lines “But you can just close the file and reopen it and they will be gone.”, which is hardly a solution
The argument for it was originally that it makes easier for new users to get get started using GN, but if any user doesn’t have mental capacity to recognize they have to click a GIANT +NEW BUTTON which is right in their face:
…then they certainly won’t have a mental capacity to do anything meaningful with the geometry nodes.
Right now, this poor design is yet another example of unrealiable user intention prediction. It always predicts user wants to create a new GN network, while in substantial amount of cases, users want to add GN modifier to use existing GN network, because adding the modifier first is the only possible way.
I have been working on generating trees in geonodes lately -simple ones, but damn that’s a difficult task. Aside from the inability to sample attributes on splines by proximity -which I know is in the works- I have some questions and suggestions.
to start off, a UI thing : the auto-connect feature when you drop down a node onto an existing connection really needs to be optional. Although it is handy sometimes, it becomes a hindrance when fiddling around in dense node trees.
Why not use the alt key to toggle it during transform ? it would make sense since it’s already used for drag-disconnecting nodes.
I created a node group that outputs a tree branch, with a few exposed properties to control orientation, crookedness, radius, and so on. One of those properties is a vector field, that inside the group gets multiplied with a noise texture and create some randomness in the branch’s trajectory. I tried to feed the normal output of the distribute points on faces node to this vector field, hoping that every branch would get its own variation, dependent on the surface normal from which it was generated.
Understandably this didn’t work… I assume because the node generates instances, instead of unique geometry. Any chance we could have this work -maybe through a copy on points node that would make hard copies instead of instances ? or am I missing a way this is already possible ?
I didn’t find an angle function in the vector math node, it could be useful. It is pretty simple to build but would probably be faster as a builtin function. I use it to measure the angle each curve point makes with its neighbouring vertices, generating a sort of crookedness attribute, which can come in handy on plants & trees.
It doesn’t work as well as a curvature attribute would, because it’s resolution-dependent, but it’s better than nothing.
I’d like to be able to work in “branch space”, ie work with coordinates that are aligned to the tree branches, and I don’t know how to do that. I thought maybe matrix nodes would help, but maybe there’s a way right now ? Basically space conversions.
regarding the expand/contract selection node (⚙ D13560 Geometry Nodes: Selection Expand / Contract), providing an actual “distance” float property may be useful as well ? it could use geodesic distance, as an alternative to topological distance.
does the team consider adding presets to the modifier interface ? I would love to make presets for different types of trees.
any plans to change the string nodes to accept string fields ? so that we can pass them geometry info to display around the object.
Now I use 3.0 release so I may have missed some recent changes, bear with me…
Not really a solution, but if you dig about in the preferences, you can find this handy setting that allows you to set how much the nodes get offset after placing a node on a link:
He did not mean auto offset but auto connect. When you move the node around, if you move it over the existing wire, it will automatically connect through the wire. It gets really annoying when you have too many wires and can’t find a place where to place the node without unintentionally connecting it to anything.
It’s yet another case of the long list of unreliable user prediction, where Blender assumes that the user always wants to connect the node through the existing wire if they place the node over the wire.
Thanks, but unfortunately that does not really help. The dropped node still connects, and those connections I have to undo by hand… OR drop the nodes in some distant places, connect them there, and finally move them into place (which is ridiculous).
Unfortunately there are a few definitions of discrete curvature and they all have their limitations, so there’s no one silver bullet here.
I’d be wary of going to far in this direction too quickly, but the next step in that direction is this task to make rotations more intuitive/useful: T92967: Add rotation data type
Geodesic distances would be great! There’s no task for that at the moment. Maybe a geodesic distance node could have a selection input, and outputs for the nearest selected index and the distance to it.
This is really more tied to the asset project. Node groups can be assets in the future, and there will likely end up being a preset system for assets. Which is great I think, since it makes sense to solve that problem in a generic way.
The string nodes do currently support fields, they’re just made to look like they don’t, because there aren’t yet any areas that can use string fields. String attributes will eventually be supported, but currently we only have a very inefficient way of storing them (hard-coded at 256 bytes per element), and we want to have a better way first.
If you sense a trend in my answers, yes, there are so many plans, and so many opportunities, but a limited supply of developers!
