A convexity parameter is a good idea. Though the important part is probably “in an intuitive way”, which the old Base Convexity input didn’t do.
1 Like
Played some more with nodes, now with Solver as well, I’m definitely won over. Spent some time today trying to recreate rounding but can’t do anything as good as provided by this node. I was particularly trying to create polygons with uneven number of sides and get clean connection and elliptical corners, but couldn’t. I can’t get the shape to “close” without even sides. That doesn’t mean it’s impossible, I’m not good with math and probably others can do it, but I think I’m good example of “average user”, not mathwiz, not beginner, and if I can’t recreate it (and can’t find anything in internet) it probably means that it’s gonna be difficult for other average users as well.
I’m won over, I like current state and hope they get merged.
I understand, but I would still create separate PRs. For your particular examples its true that Solver node is needed as well, but Rounded Polygon is immensely useful as a separate thing and we can demonstrate that without the solver. I can help with some practical examples if there will be lack of it.
Even if design in principle gets agreed, 5k lines of code will drag the review process, so I think going step by step and first implementing Polygon, and then Solver will be better. Will also help get more feedback after polygon is in main.
Besides, what does Jacques know about nodes anyway.
9 Likes
I’m glad you like it, Raiko has spent a lot of time developing the algorithm for the rounded corners so it’s great to see it being appreciated.
I’ll definitely keep that in mind. It’s just that I had a Pull Request in the past where I ultimately ended up splitting it up into multiple PRs. But that didn’t work well at all. Just like in this project, the separate PRs modified similar areas of code, which not only resulted in merge conflicts but also in the logic of the code conflicting with each other. In the end splitting up the PR into multiple smaller ones just ended up being much more work for everyone involved.
Therefore I try to avoid splitting up PRs in these cases whenever possible.
And also logically speaking the 5k lines of code need to be reviewed one way or the other and I don’t see how reviewing 2x 2.5k lines of code would be much easier compared to 1x 5k lines.
For code review I indeed would want a separate patch per node. However, we are not at the stage where I would do code review here yet. As I said in chat, I wanted you to create a single patch because that makes it easier for people to test the functionality to refine the design.
The overall approach here does seem a bit unconventional. Typically you’d start with a problem and then develop one or more nodes that solves it. Here a solution was provided first and now we’re trying to split it up to find the actual problems that it can solve for people. I’m not saying that it can’t solve problems, it’s just not a good sign to go about it that way.
The rounded polygon node may be worth including. I’d want to know from artists how they would design a node that allows creating such polygon textures from a users perspective. Then we can have some artists try to implement it with existing nodes and if that turns out to be impractical then we can look into creating a built-in node for that purpose. The node from the patch might solve that use case perfectly or it might not, I can’t say that yet.
A similar approach is necessary for the other nodes too. Our goal is to make things better for users, not to add the Raiko texture. These goals may have the same solution, but currently I see little indication of that being the case (besides the potential usefulness of individual nodes as mentioned above).
10 Likes
Adding the Raiko texture is not the goal of the Pull Request anymore after significant changes were made based on user feedback.
Apart from that the only “other nodes” is just the Linear System Solver node. The Elliptical Remap node groups are node groups and don’t have any code affiliated with them. The user feedback from those who tested them on the blenderartists thread New Procedural Textures in Blender! - #98 by Lumpengnom - Blender Development Discussion - Blender Artists Community is also largely positive and the goal here is just to include them into the essential assets bundle. I think they could also be used to test if shader nodes asset embedding works during development.
The rounded polygon node already went through many changes based on much user feedback and that’s what it concluded to. Is there anything you’d want to me to ask for more feedback on in particular?
I think @nickberckley already tried to do that. I know that @Raiko also started developing the node as a node group before switching over to a built-in solution because the mathematical complexity of the node group just ended up being too overwhelming.
The mathematical complexity would further increase if a vector scale input were to be implemented as described here: Raiko Texture Components Feedback Thread - #15 by nickberckley
Should I still ask other artists to try creating the rounded polygon node in a node group nevertheless?
I did indeed try to recreate it. I’m not quite Simon Thommes, but as I said representing average user here, I couldn’t find a way to get the result that Rounded Polygon node gives. For reference this is what my current polygon node looks like
Inputs and outputs are similar, except I have Outline and don’t have Perimeter.
What I found impossible to create are these:
This is how my node group (left) handles uneven number of sides and how this node (right) handles them. I can’t find a way to close the polygon and get proper shape. It only allows me to create simple 3,4,5+ sided polygons, while Rounded Polygon allows uneven sides to connect gives much much more shapes as a result that can be created and driven procedurally very easily.
I also can’t do rounding with a node group. I have rounding on Rectangle node (which is similar just hardcoded to 4 sides), but only thing I could achieve is having one rounded shape, one sharp, and mixing between them, which produces ugly pinching when you’re somewhere in the middle
While Rounded Polygon supports fully beveling corners and every value looks correct. It also allows much more range than I could do.
I’d love to see smarter people try their hand as well to recreate this node as a group. If it is doable I do prefer it to be a node group instead, I am in principle against merging new texture nodes in core Blender, but this one I think can’t be recreated as a group, and usefulness of this simple node is great enough to warrant being in core
1 Like
I think this is what you all want: Shader - Shadertoy BETA
This one uses mat2. How can I get that with math nodes?
aa * px + ab * py + ba * px + bb * py
Actually it’s not what the Rounded Polygon Texture outputs.
What the Shadertoy version does is compute a signed distance field of a rounded polygon.
Although it looks quite similar, the Rounded Polygon Texture does not output a signed distance field.
The problem with signed distance fields is that the polygon gets rounder the farther you go away from it.
You can easily see that in the Shadertoy demo when Roundness = 0. Going away from the polygon causes the edges to start to round even though the original polygon has perfectly sharp edges.
The Rounded Polygon Texture doesn’t have that problem.
And then there’s of course also the obvious issue that the Shadertoy version doesn’t support fractional side inputs.
5 Likes
I think part of the confusion also stems from the fact that the first output of the Rounded Polygon Texture is called Distance even though it’s not the distance of a signed distance field.
Calling it Radius would probably be better.
1 Like
Been a while since I tried recreating shadertoy in Blender. I gave it a go, but make mistakes probably somewhere and can’t find them without ruining my day. I’ll drop my attempt in case someone wants to take a look and do math for me.
The closest two math node groups I have collected that are similar in design idea to the proposed rounded polygon node both have extra line thickness, falloff options.
Erindale’s node group (I followed his 6 part Youtube Shape Generator tutorial) also has a rotation slider… perhaps not as important. 
David Cescatti’s free “Superbasicshape” nodegroup on gumroad. It has more complex circular array and round corner slider options than Erins one, but it looks a lot different in the way it attempts to round the corners than the proposed rounded polygon node.
As an artist, I’m a fan of the way of the new roundness nodes feels when testing and it improves on what i already have in node groups.
Line thickness or falloff might be useful to add to the rounded polygon node, in the same way the default brick texture in blender has options like bias to give more basic artistic possibilities.
1 Like
I’m not sure how exactly the node group from Erindale works, but I think you can get “line thickness” by using a math node in compare mode as described in section 2.2 of the user documentation here: https://projects.blender.org/attachments/8391ed00-018c-44f2-a49c-ddbd8770357c
I think you could probably also get “falloff” by adding math nodes after the “Distance” output.
1 Like
Yeah compare math nodes works 
I just liked Erin’s sliders because its smooth falloff. It’s ok not to have it inbuilt into the node I was just hoping to save some time on general workflow. This is Erins extra falloff settings if that makes sense.
I see. There’s a general push to convert most of the currently built-in node functionality into node groups, which is why adding features to built-in nodes that could already be achieved using the currently available nodes would go against the current design goals.
3 Likes
I’ve been collecting user feedback and changing the PR based on it for the past week.
Here’s a summary of it:
Rounded Polygon Texture node:
After many changes to the node, feedback on the Rounded Polygon Texture node was almost unanimously positive both here on Devtalk and blenderartists. There were neither successful attempts of implementing it as a node group nor were there any mentions of other scripts or addons that could replicate the output of the Rounded Polygon Texture node.
To my knowledge this is the first mathematically exact algorithm that has been found for this specific construction.
Further research into a possible vector Scale input as described in this post: Raiko Texture Components Feedback Thread - #15 by nickberckley is planned.
Elliptical Remap node groups:
There wasn’t a lot of feedback on the Elliptical Remap node groups however the users who did test it had very positive reactions to them.
Since it rather distracts from the main PR I plan to remove them from the PR and open a separate issue regarding them. As far as I know there still isn’t an official way of requesting to add assets to the essential assets bundle but we can figure that out in the separate issue.
Linear System Solver node:
I’ve found a way to implement the algorithm used by the Linear System Solver node as a node group. Moreover parts of the implementation can also be used to create a Matrix Determinant node and Matrix Inverse node. With an estimate of around 2-3k lines of code per built-in node, implementing these Linear Algebra related nodes as node groups would save an estimated 6-9k lines of code.
Therefore I plan to remove the Linear System Solver node from the PR and open a separate issue with the Linear Algebra suite of node groups.
The Linear System Solver node groups show some shortcomings of the current node system both performance and UI wise, so I think it could be used as a pilot project before more nodes get ported over to node groups.
9 Likes