I also did tree before the new year
I abandoned the use of curves and did all the abstractions of building on a grid
Oh sorry i was thinking you talked about the auto offset 
Thanks. Would be nice if it could be done from the extrude mesh side output to save on extra nodes.
We’ve talked about that before a few times. A couple related tasks:
Yes, we’ve done some design explorations on that topic here: Loops in Geometry Nodes [Proposal]
More patches!
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!
I am having a bunch of fun in the tesselate branch,
one thing I find myself needing is edge slide,
and another is flip normals,
Fantastic ! thanks for the thorough reply.
Didn’t think of it this way… several birds with one stone, it’s probably the wisest approach. I was thinking more of the same preset system that’s used in render properties : a dropdown and a list of presets. This allows the user to apply a preset to a set of properties of an existing asset, without having to re-import/append it to the scene. Think having a generated tree in your scene and changing all of its exposed geonodes properties with one click, turning it eg from mango to cedar. If the asset browser allows for that, all the better
I looked up the paper linked in the task and it seems the subject is indeed more complex than I thought.
Yes, I hope my questions don’t put pressure on you. They are really just questions, out of curiosity and to help determine users’ needs more precisely.
Cheers,
Hadrien
@Jacob_Merrill real cool !
I have found the piece of code responsible for an exception in the way bezier node connections are drawn for reroute nodes. After commenting it out, it looks much better in pretty much every case.
Here’s side by side comparison:
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 ?
