I agree that this is much nicer. Do you plan on submitting a patch for that? 
This was also part of a reroute patch I worked on (D11209) but I’ve been quite busy since and that one still needs agreement in terms of the design and would also benefit from a new shader for the sockets. So it would probably worth it to make a separate patch for these small improvements.
I don’t think commenting out a few lines of code would quality as a patch. And I don’t even know how the patch submission process works. I talked to Jacques Lucke about node editor(s) UX issues and he said I should put together some summary document to put on GN meeting agenda, so I plan to do that first and leave code changes to someone competent enough to pull them off.
I did this mainly just to show off the difference visually
I also wholeheartedly agree that we need a way to move reroutes with just a mouse drag, so something like your patch is much needed.
I must say that for the reroutes I like the right side look better. But for the branches I actually like the left side better…
Though I don’t really care either way. It’s not really important to me. I’m gravitating more and more to straight lines with no curvature at all anyway.
Hello! I’ve found some strange behavior in the Realize Instances node. Then I use UV map, it is lost in Shaders in Texture coordinates node:
But still accessible through the attribute node:
I’ve tried to add UV map as attribute output, but where is no node to get from custom attribute such as UV map:
Adding UV as Input for GN is not work, because it is UV from distributor, not from the instances
Also, BTW, Rotation attribute is not exposed:
It seems to me (from the last meeting notes) that the map range node is kinda duplicated into the easing node and the mix node. Mix does different data types but only linear interpolation, easing does just float type but all kind of interpolation, and map range seems redundant now. It would be nice to keep things as tidy as possible and follow the recent mantra “don’t group by type, group by functionality”. I’d vote for a single node handling all types and interpolation options (not that I use them a lot, linear would be enough for me). Unless of course I am missing something there ?
Also did you consider extending the math node instead of making a separate integer math node ?
I am asking because of this statement :
Generally we want to move to an operation based workflow rather than a data type based workflow.
that I tend to agree with
Mix node, Map Range node, Easing node, Curve Map, Color Ramp are all types of interpolation node but with different options. These could all be put into a single node with multiple options or they can be split out into different nodes.
The idea of the Mix node was to provide simple linear interpolation in a single node, merging or adding this to the existing Mix RGB made sense when it was coded. This means that the default clamping for the Mix RGB can be removed. This node has been coded for GN and shaders.
Easing was initially a simple port of the existing Easing functions into a GN node. The questions of whether this is a map range or interpolation node came up during review. It is not finished yet. Personally I’m leaning to it being float only and then used to control factor/inputs of other nodes.
Integer Math is also not finished, currently it is only a GN node too so like the Boolean Math node it is likely to be a separate node but that decision still needs to be made.
There is also a design task for the Math Node here to look at how to extend it to support float2 in the future: T94899: ⚓ T94899 Float Math Functions in GN and Shaders.
Thanks for your reply. Frankly I’m not convinced… imho the existence of both float curve and color ramp side-by-side is justified because they use completely different paradigms to control interpolation : one uses a 2D graph, which is handy for visually mapping one value to the other (especially valuable with curve manipulation being such a staple in 3D animation) but can’t represent more than one dimension at a time -the other uses color stops, which is fit for making actual color gradients but can’t work with vectors since you can’t represent negative vectors with RGB colors. Finally both are limited in the range they can represent, but map range, at the cost of having a somewhat simpler interpolation (linear, smooth, etc. but no custom stops or handles) allows the user to remap to a widely different range.
So this is where my remark comes from. I look at those and I see three nodes that do pretty much the same thing, bar a couple details, in more or less the same non-visual way, and it’s not obvious to me which one I should be using in a given situation. Maybe that will come with working with them.
Instinctively I’d go for a unique mix node that handles floats, colors and vectors, has all the interpolation options from the interpolate node, an input range and an output range. Not to mention it would be nice being able to explicitly remap other types as well (especially vectors), right now map range works with floats only and I don’t think the other two proposed nodes cover that?
See I find it makes much more sense to keep boolean math separate since it’s so conceptually different. But maybe I’m reasoning about it the wrong way ?
Map Range works with Vectors since quite recently, it will be in the next release.
I remember when shading nodes only had the Transform node with a single input and output. That’s changed over time and you now have options now to use Scale and Rotate in different nodes. I see Map Range in a similar way. I just want access to the individual parts, Inverse Lerp for the first part, use my own nodes to change the factor and then finally use Mix for the output.
Honestly, to me, the existence of both float curve and color ramp just indicates we are missing color curve and float ramp 
I feel very awkward when I want to remap some float field using a ramp and I am (implicitly) converting floats to RGBs and then back to floats just because of the ramp It’s probably not that expensive but probably not free either.
I am not sure how much would RGB/Vector curves be really useful in GN though. So in the end, I guess I’d just expect the Color Ramp to become Ramp with data type UI selector, or dynamically change depending on inputs (the don’t group by type, group by functionality you’ve mentioned).
Yes that was not an argument against curve and ramp supporting other types ! They are still different ways to interact with data, that cater to different types of users, I think. I personally don’t like using ramps that much, I like the straightforwardness of a curve, maybe because I’m initially an animator. It’s mostly about the way they present themselves to the user.
Now that’s really cool.
Yes, and we had to make our own group nodes for transformations if we wanted input sockets. Uphill both ways !!
I’m not sure I follow you. Do you mean you see the functionality of map range being split up in an interpolation part and a remapping part ?
Just to have the flexibility to roll your own interpolations. Map Range is two operations. Inverse Lerp and then a Lerp/Mix depending on your preferred naming. The Smoothstep and Step options just manipulate the factor in between the two operations differently. So a separate Mix node is a great addition.
It is a limitation of current GN.
Related issue here: ⚓ T85962 Many Nodes (Join geometry, Boolean, Object Info?) and realizing instances remove UVs (output float2, not MLoopUV).
I am waiting for this to be resolved as well.
I think I understand, inverse lerp returns the factor of the input value between A and B, then you pipe it into some other interpolation node (such as interpolate), finally pipe it into mix. So these nodes are a way to break down the map range functionality into chunks ? That makes a bit more sense now, they have a very specific intended usage. Maybe that should be communicated ? I know I was pretty clueless.
Silly question but I really can’t find the solution -
It’s easy to manipulate the position of many polygons by their normal. But is there a way to simultaneously rotate every polygon by it’s local normal? There is “Set Position” but there’s no equivalent “Set rotation”
The capture attribute node is helpful in this case. You can capture the normal and position of each polygon and use that in the vector rotate node.
Or am I missing something?
I am unfortunately running into a situation where GN become unusable in production due to this issue:
https://developer.blender.org/T94609
What is worse is that if you actually use any attribute generated by GN in the shader editor, then even not touching anything, just navigating the viewport freezes Blender UI after each operation for multiple seconds. So it’s just not possible to work with the software at all.
I really don’t know how to use geometry nodes for anything that has more than like 1000 polygons and still be able to use Blender when I am displaying the GN generated UVs in the viewport 
https://developer.blender.org/D13838
Do I understand it correctly, that instead of making Geometry Nodes work with classic mesh data (UV maps, vertex colors, etc.), we are asking to wait and hope all the exporters and other tools will learn to work with attributes?
Yes, that’s it. Short term it might be more difficult, but in the long run it’s definitely the better decision.
