Number of sharp edges connected to a vertex [Geometry Nodes]

I’m stumbled by what I’m doing wrong in my node setup here. I honestly thought this was the right direction towards accumulating the total amount of sharp edges connected to any vertex and marking it as sharp if it has more than 2 of them, since it’s a sharp corner then.

But the accumulate field is taking into account all the edges of the object not just the ones connected to the index in question, therefore all vertices are marked as sharp. I’m hopeful that this can actually be done without the need of using the repeat zone as I’m definitely doing something wrong. Up until this point I was pretty confident I understood fields solidly(pun intended) in geometry nodes but not anymore.

Not sure if I should be confident that’s it’s 100% doable this way due to the fact that the nodes already know how many edges are connected to it (verifiable by Edges of Vertices node)?

GN setup:

The results via geometry nodes:

Base mesh with sharp edges

Correct results achieved strictly via python scripting (note that the number one just means that there’s more than 2 sharp edges comprising the vert):

Hello!

I could think of how to count “sharp” Face Corners:

…but no luck with edges so far :thinking:

Thank you for your assistance, because believe it or not by simply changing the input attribute from ‘vertex of corner’ to ‘index’ I get the exact result I wanted. I don’t even need to compare the accumulated number to anything as it’s automatically fixed to 1 as soon as the number connected sharp edges exceeds that of 2.

I’m not yet gonna label this as an answer as I’m waiting for someone more knowledgeable (i.e. @zeroskilz ) who can probably either find another solution (that actually counts number of sharp edges) or even explain to us why this particular solution works.

Hi,
i think this here could work:


It checks if any edge of a corner is “sharp” and accumulates that. If an edge has two or more neighbouring faces, the attribute will be counted twice - hence why we have to divide the final result by 2. However if the edge only has one neighbouring face, we have to count the “sharp” attribute twice then.

Edit: Damn, it fails on this example here (should be 3 instead of 4)…

lol… stray is easily more knowledgeable than me.

Hm, I think it would be the same if you simply run sharp_edges through “Evaluate on Domain” with Face Corners, as “Accumulate Field” doesn’t seem to serve a purpose in your example (it accumulates on each individual corner, so it’s the same as simply reading the attribute). I think.

But you’re the one with all the solutions usually :slight_smile:

@Zebrahead, wow, nice job navigating the topology nodes! :face_with_spiral_eyes: I am so confused

Thanks :sweat_smile: but it seems to fail on a particular scenario (see my updated post above). Would need to invest some more brain power into that :sweat_smile:

Nevermind, this here seems to work!


The trick was to divide the “sharp” attribute by the edge neighbours so it gets properly weighted:

Bad news guys, even the first and more elegant solution fails when one decides to add additional non-sharp edges to a corner with three sharp ones.

Before:

After:

[s]After wasting the whole day on this at least I kinda feel a lot better now after seeing that even GN veterans struggle with this, which is understandable.[s]But it’s still strange to see that ‘Edge of Vertices’ has the knowledge of the amount of edges connected to it, that lead one to naively believe that there should be an access to all the edges in a way that doesn’t incorporate ‘repeat zone’ or stacking fixed number of nodes that shift through the node’s sort index, if that makes sense.

Edit:
Nevermind, @Zebrahead has found the solution and I thank you for that. I consider this as the solution as it works for all cases and is 100% identical to the one generated by the script.

Seems fine to me :man_shrugging:

I was referring to the first solution by @stray, I didn’t see your answer that is now the final solution while posting that comment, hope that clears up the misunderstanding.

A nice reliable setup :+1: GG

Accessing arbitrary number of indices from single point seems like a whole different animal from simply getting a single number that is associated with that point. One of those peculiarities of working with fields, I suppose.