for my more … “finished” node groups, i do put limiters on the inputs, forcing them to useable parameters… for instance, hard to have a grid with just one point on either axis… so i make sure that’s at least 2, regardless of what the user (which is still me ) tries to force in.
given that, if i did a switch, so if the number is in range, do the thing… and if it’s not, output geometry that says “yo, this number be wrong” with a string → geometry thing.
so, there is a .way. of doing it now, just not as pretty of an error that would be nice to have.
Well, there is no point in building that setup each time you need it, but rather once you made something useful like that you might want to make a group and add that to your personal library, so it’s always at hand :
And if building such setup really annoys you, it’s always possible to get one in minutes. But as other said, it’s more clever in the long run to take the time to learn to build these tools so you can come up with your own special solutions for a project when it’s too specific for being in blender by default…
Patches by Jaques have a tendency to get in main quickly, so we very well might see this as a feature for Blender 4.1.
I do not know if this will be a built-in node group, as Geometry Nodes does not yet have a lot of tools that can outright build geometry like the Extrude Node does.
I tried first to do them in krita thinking it would be simpler but it turns out to be quite tedious in the long run…
The camera move though the grid so each frame is one icon, then a script uses the timeline markers to assign proper names to images.
Finally another script read the rendered .png and assign the correct icon when a matching name is found…
After a while I just realized that I can use a mix of 3D and grease pencil to add some bits of artistry to them even tho I try to make them effective first and the look/design/style is much lower on the priority list…
ATM I don’t sell my work, it’s something I had in the back of my head for a while but I’m waiting for the right moment…
All that said, a lot from my library is either taken from external resources, like tutorial or other’s library, or it’s basic functionalities that are not that difficult to recreate. Most of the time it’s some shortcut that I use often when building bigger setups…
I just found out that writing multiple attributes with the Group Output node is considerably faster than doing it with individual Store Attribute nodes.
Here’s my node for writing mesh curvature information to attributes. The 1st one has 3 Store Attribute nodes inside that do the writing. The 2nd one just outputs the 3 attrubutes and they’re stored on the mash by the Group Output. You can see the numbers.
I didn’t test it, but I’m guessing the Sample or Capture nodes are the same. If we wanted to Sample Nearest Surface and get the position, normal, and maybe a few custom made attributes, then the perfomance is going to tank ;(
It is logical that if you use a node 3 times, you will get 3x the timings, but I wish these kind of nodes had a “dynamic” socket amount, so that we could sample multiple attributes with one node.
I was able to make a world and a physics engine using geometry nodes - only a curve and ‘preobjects’ exist on this scene - everything is generated from noise. (also a ‘wall’ and ‘door’ mesh)
I think next we need a ‘list attribute’ - and a way to gather a list of physics contacts -
we do instance on points (physics actor origins) - physics types - (sphere-box-bvh etc)
this can be used with sim nodes to get contacts per vertex - and we can apply impulse
per contact / emit sparks etc / trigger noises.
here is a vehicle using ‘apply impulse’ in bullet
(we can do the same in geometry nodes with a little bit more work!)
Seriously, performance improvements are always needed in GN. Since you have working example, making a bug report for this would help all of us, if it gets fixed
It’s not really a bug, more of a limitation. So what I should probably do is a feature request
Also I think I made a mistake, because the number above the Group Output node isn’t actually the time it takes to write those attributes, it’s just the curvature calculations that my node does.
The attribute writing process of a Group Output node isn’t included in the timings displayed. I tried writing a random value to 1mil+ verts, and the timing just showed - ms, while the same for a Store Attribute did show a value of 10ms.
So I can’t really measure which process is faster. The Group Output version of my curvature node did feel faster, but that’s not the best way to measure stuff.
I realized today that attributes aren’t propagated by mesh to volume. Perhaps this hinges on the future work on volume grids ? at the moment, going from mesh → to volume → back to mesh loses any attribute. For instance I’d like to color these building parts differently in the shader but the attribute isn’t preserved. I guess I could transfer it from the original but it gets complicated and heavy.
I believe its the expected behavior. It’s the exact same way in Houdini. You need to transfer your attributes back from before you made your mesh volume.
It somewhat works by capturing the attributes with a “sample nearest surface” node, with the original mesh being the source.
I’ve used this method to sample the mesh island ID of the bricks in a wall, so that the bricks could be volume-meshed separately (moving them apart by ID, meshing them, sampling the ID, and moving them back to their original positions). While it does work, it requires a much higher meshing density, depending on how far all pieces get pushed apart.
I don’t assume there’s a more elegant way to have mesh → volume → mesh conversion respect mesh islands?
so i make sure that’s at least 2, regardless of what the user (which is still me 
