Sorry about offtop, but mentioning matrix’es and stuff going faster reminded me about that video of making general matrix-matrix multiplication (so basicaly what Multiply Matrices does) going 120x faster by rearranging order of operations/SIMD/multithread.
Looks like Gizmos were quietly killed off 
Can anyone explain what Iliya Katushenock, I think he is one of the geometry nodes dev means by better field calculations for udim texture support to be possible in geometry nodes?
How we currently execute field nodes:
(int a, int b) { return a + b; } assembly line for each elements.In general, only way to optimize some thing, is to make them more non-trivial.
But we’re limited there. For example, we can’t execute something for geometry, if there is no geometry. For instance, for just single value, Accumulate Field node can not work, same for Field on Domain or Blur Attribute and so… .
Now sampling nodes. Sample Index, Sample UV, Wave Texture, Image Texture and so. All of this nodes is not just assembly line for each element. There is some state (usually just node settings).
This nodes can be used in multiple fields, and node itself will be computed once.
For Raycast node, node executing is BVHTree building, for Image Texture node this is image texture upload in RAM.
Why UDIM is complicated? Short: reason is the same as for Frame field…
Ways to support this features:
This can be improved, but for now this is known issue.
@Jacques_Lucke , main developer of geometry nodes, said this can be solved by using cache, but i am not sure if cache will be the most optimized solution in case of a lot of randomly distributed different frames and a lot of load-unloads. Even for just one geometry capturing for image data, without a lot of such nodes in all blender project.
Thanks for explaining, mod1. I wonder how Houdini is doing theirs though I know Houdini and Geometry nodes in Blender are different in so many ways.
I am the one who opened that ticket, as far as I can tell there is no solution to it yet. We really need UDIM support in the node graph. Currently the users still need to use displacement modifier for anything UDIM for displacing meshes.
the only solution I can think of - is a megatexture style cache where there is a cache that sections of it are replaced over time and uv are remapped to where there section is
so when baking - it would need to make a log per frame of what tiles are needed - and then at the end - make a sort codex that tells what to load over time.
Thanks for opening it. Displacement using udims is definitely of importance when using geometry nodes. I was surprised you could blur your maps as well using the blur attribute node (doesn’t exist in material nodes).
I think geometry nodes gives you more flexibility when it comes to displacement than what we have with the modifier. Or maybe they can add the ability to plug material setups to the Displacement modifier in Blender.
You can do this in 3dsmax, you can link any material nodes setup to your displacement modifier. This is a feature 3dsmax has since the beginning.
Expensive operations like blurring are more suitable for Geometry Nodes because it is not per-pixel, and it is done before the information is sent to the render engine (so there is no added shading cost). Doing such operations is viable now because unlike classic baking with vertex colors, it is all automated and non-destructive.
We definetely need it, however Blender is insanely inefficient with UDIMs both in the viewport and in the render. As far as I can tell Blender will load the whole UDIM set regardless of if any part of the UV is overlapping in any of those areas. So if you have 100 piece UDIM set and if your model is just using the tile 0, Blender will still load all those 100 images. In theory Blender should not load the rest of the 99 images.
One might wonder why one would create 100 UDIM images and not use them, the reason is that another model might be needing other areas, so there are many reasons why that could be the case.
That’s definitely a huge plus for geometry nodes then. Thanks for the info.
That’s a huge issue. Hopefully the devs find a way to fix this and optimize things. 100 udims is nothing for most movies, some use 1000 udims or even more.
Hey @Hadriscus hope you’re doing well!
Well, a few months later, my addon is now finally released 
and among many things, it adds an improved UI for using the attribute system that I teased all the way back in November. Let me know what you think 
Key Ops: Toolkit
Fantastic, thanks for delivering. Looks like a feature-packed addon ! I will test this.
For those not keeping track, Hans has been making a number of commits to bring back SDF modeling with nodes after the original experiment was removed (based on the devtalk design thread).
The next patch coming up introduces boolean operations for SDF.
#118879 - Geometry Nodes: Add SDF Grid Boolean Node - blender - Blender Projects
Much faster boolean modeling, step 1 (not in master yet though).
#119294 - WIP: Add float solver to geo boolean node - blender - Blender Projects
This is not the new exact solver, but the standard ‘fast’ solver that is already in Blender (which does have its limitations, but in many cases it is not an issue). The new solver will likely not replace this one, but more likely will lead to the old exact solver being retired.
ah so this means all the Blender 3.6 SDF modeling tuts don’t work because they never implemented the SDF tools?
I actually built that node setup back when the video was new. Don’t know what I did wrong, but performance wise it never worked as well as in that demo despite having very good PC hardware. I opened that same file in 4.2 and noticed that some nodes were removed and didn’t work anymore.
I’d personally wait for the Conjure SDF add-on. Looks very promising!
Yep it never went into master.
ConsureSDF looks indeed promising - but it think you cannot use custom mesh and that was my hope to emulate something like that hyper fusion thing from Moro many years back.
The current remesh workflow has way to many issues with nasty geometry creation.
I am on a quest to create a lecture exploring rapid prototype design with polygons instead of using cad.
One of the changes I hope to see to existing nodes is Selection input on many more of them. So many need it, not just subdivision which can be hard to implement, but for stuff like Domain Size too. Would require much less hacks to work in geonodes, especially now that we have tools and use viewport selection. Hope some dev can take that task
A potentially big performance boost for nearly every use case is now in main.
BLI: speedup memory bandwidth bound tasks by reducing threading · b99c1abc3a - blender - Blender Projects
In short, it turns out that throwing every thread you can at every problem can actually slow things down (as they will interfere with each other as work is done). Now, you will have many instances where there are limits to thread use depending on what is optimal (so this is another thing to consider when it is time for a PC upgrade).