With the development of the simulation part of geometry nodes, would it be a good time to reconsider adding some warnings or safeguards against situations that will risk taking down Blender? Simply dropping a subdivision surface node in a simulation will hang or crash Blender within a few seconds.
So far this is an early experimental feature.
I’ve been thinking about this for a while, it’s not an easy problem to solve. Adding generic warnings is cheap of course, but won’t help with actual situations where node inputs are the result of a math operation (divide by small number), where nodes are hidden inside a group or linked from another blend file, when users make a simple mistake (type one more zero than you wanted).
There would have to be a way for users to interrupt node execution somewhat reliably. The only way to actually force a process to stop is, afaik, through the operating system and it would have to run as a separate process. That would be a major headache and comes with all sorts of implications regarding inter-process communication, cleanup, etc.
The better alternative, and IMO the only viable solution, would be to stop node execution cooperatively. That means setting a “cancellation token” and then expecting functions to check this periodically and abort within a reasonable time frame. Another problem is how to do this with 3rd party libraries that don’t make it easy to inject such cancellation code, but at least for Blender’s own functions it may be possible. Still a lot of work, so i wouldn’t expect it to happen over night.
6 Likes
Maybe if you place a node that alters enough things (maybe even have certain conditions be evaluated when placing such a node) it will trigger a popup telling you that “The following node could trigger unexpected results, your node has been placed in a muted state”, your new node is added to the tree but in a muted state which would help in stopping you from accidentally killing the tree with a node,
This would be nice because sometime if you have lots of nodes you could miss certain nodes or forget about them and placing a new one which could potentially cause issues kind of stops is from completely either crashing blender or freezing the app forever.
Ofc, this could be on/off in the menu if you don’t like it
Is there a plan for letting users make custom nodes? Like Houdini’s “Point Wrangler”.
I understand: 1) writing custom nodes in python might be too non-performant. 2) Blender has C++ API for custom nodes.
But it’s just… way, way too tedious. It’s in the developers’ realm, not the users’. No matter how advanced a Blender user is, modifying C++ and building/maintaining their own version of Blender is still crazy amount of work.
In Houdini it’s this easy:
[image removed]
Just add a point wrangler node and write some VEX code, all without leaving Houdini. And the performance is unbelievably good.
If Blender is serious about procedural modeling, it really needs something similar. It doesn’t have to be Python, it doesn’t have to be VEX, but it has to be something.
5 Likes
- This is the task of groups of nodes. So far, deeper ways of defining logic are only experimental.
- Please remove the picture. It is forbidden to upload other paid programs on blender resources.
Copyright guidelines for devtalk
Please don’t post screenshots of proprietary software, thank you.
The problem in blender is add node… and again… and again … and again also some node can be compiled in one node with some checkbox for activate the function area…
Yes it’s called node groups as either assets or in your startup file.
2 Likes
Hi, I’ve been hoping for one of the nodes in limbo, grouped statistics, to be merged soon. I have found no workaround for a particular case I’m trying to crack, and reading the task I understand lists are holding it off.
https://developer.blender.org/D13547
Are lists just about to get implemented? if not, and they’re still some time away, could grouped statistics be considered for inclusion in the meantime? I assume several nodes are likely to be changed to use lists whenever these come, yet they’re useful in their current state, without lists : join geometry, switch, etc. I’m sure it would also be the case for statistics.
I apologize for this looks kind of a request,
cheers,
Hadrien
3 Likes
There was an idea to add a group to the calculation design. That is, it will be something more fundamental than just transferring all nodes to another socket …
I’m sorry, I’m probably not totally up to speed on the code side. What do you mean by vulnerabilities ?
1 Like
I think this would be worth adding in the meantime too. It would save quite a few hacks that people do with the accumulate node.
6 Likes
Not really a bug, and not a feature request but rather a bit of a complaint from my side.
I found “Curves to points” in “Length” mode gives annoying jumps in point distribution.
From my user perspective, I expect this node in this mode would place points in exact intervals starting from the beginning of the curve. If the curve’s length is longer than an integer number of points, I expect that this node just quit sampling rather than trying to put another point at the end.
We already have “Endpoint Selection” node if we need points exactly at the ends of the curve.
On the other hand, I think, having more atomic subset of this node would be very handy.
I mean, split this node into two: 1. Curve to points by length. 2. Distribute points along curve.
I see that node №1. is placing the whole number of points in exact intervals, and №2. is distributing the whole number of points along a curve from end to end with approximate intervals between them based on the user’s interval input.
I know now there is a hack around to use “Curve to points” node with “Trim curve” together, but it wasn’t obvious to me before I learned this trick. Besides! “Curves to point”+“Trim curve” sometimes produces jumps and artifacts in some corer cases which is also annoying =(
I have realized that unexpected behavior when modeling procedural bridges.
Thanks for listening, feel much better now! 
1 Like
To be pedantic, this is the ‘official’ method to handle that scenario as explicitly mentioned in the manual for both Curve to Points and Resample Curve nodes so it’s not a “hack”, but I do find it unintuitive too. I was very confused when I first came across the behaviour and still find it annoying. Perhaps imitating the already established setup Image Texture node has and presenting two sub-options in the dropdown (rather than separate nodes), “Length—Fit/Extend” and “Length—Clip” would be nice, for instance?
2 Likes
That would be a good solution!
@HooglyBoogly Towards my very previous message about the “Curve to point” node.
I think the documentation should be updated in “Curve to point”+“Trim curve” to develop this solution a bit further, providing a few examples.
I believe it’ll help beginners to avoid unexpected behavior.
Just a suggestion.
Hello @Hadriscus , may i ask what you are trying to do? Have you seen or even may tried my attribute group statistics node groups.
1 Like
I had not seen that, looks great ! I’ll have to try it, hopefully this weekend. My use case is finding the mean point position (any attribute really) for each face set in a mesh. Thanks a bunch, will report back
Hadrien
1 Like
I updated to 3.4 recently, which made another step towards “attributizing” Blender. Any mesh with multiple materials now has material_index attribute, the deletion of which will result in loss of any multi-slot material assignments.
Couple of thoughts:
-
There definitely needs to be some way in the UI to distinguish Blender’s built in internal attributes from the user ones, to prevent users from wrecking their work by accident by deleting built in attributes. I initially thought the “material_index” was just some bloat that got in as I imported an FBX file, but I was surprised that removing it deleted all my material slot assignments.
-
It’s starting to get very confusing why is there a “Color Attributes” panel and then also “Attributes” panel. If you create any new attribute, it shows up in the Attributes panel list, except if the attribute is of a color type, in which case it shows in both panels at once. This separation is becoming quite pointless, especially given that the attribute lists themselves give the user information about both the attribute type as well as the domain, for example “Face Corner → Color”
The confusion is only going to grow after the next release, where there will be “Color Attributes”, “Attributes” and “UV Maps” panels. All the attributes are going to show on the Attributes panel, except the attributes of a “Color” type, which will show in both “Color Attributes” as well as “Attributes” panel, and then on top of that, if the attribute will have a specific combination of a “2D Vector” data type and a “Face Corner” domain, it will show in both “Attributes” panel as well as “UV Maps” panel, which I am sure will not have a word “Attribute” anywhere in its name by the time moving UVs to generic attributes is done, further deepening the confusion.
I think it’s about time to start thinking about single list panel for all the attributes, with some functionality to filter and sort them based on the domain and data type. New users won’t care for excuses about legacy reasons as to why things are so confusing.
19 Likes