Raiko Texture Components Feedback Thread

[Hoshinova]

Hi everyone,

@Raiko and I have been developing a new Rounded Polygon Texture node, which we’d like to have some feedback on.

What can it do? Well a multitude of things, here are some examples:

Due to limitations of Devtalk threads I’ve put all the remaining information into the Pull Request.
So please have a look here: #127711 - WIP: Nodes: Add Rounded Polygon Node - blender - Blender Projects

Additionally a video was made to demonstrate the capabilities of the Raiko Texture components.
The video is linked here: https://youtu.be/RiIYcaRw6Mw

Here are some screenshots of that video:

PS: It’s actually @Raiko doing all the development. I’m only doing the announcement because Devtalk limits what new users can post.

[nickberckley]

If node needs 21 page .pdf just for the descriptions (without even going in explaining sockets and how to get each of the outcomes), maybe it shouldn’t exist?

Names “Raiko Texture” or even “Raiko Base” doesn’t say absolutely anything to user. There should be nodes “Hexagon”, “Grid”, “Herringbone”, etc. and I know what you might say: those will be added as node groups using those Raiko textures. But they’re already possible with node groups, so what is this providing exactly? If in the end we’re still waiting for online assets to ship those groups with Blender (which is the right decision) what does this provide then?

I do think that some helper functions for different types of “arrays” and randomization and etc. that are shown are helpful tho, but I don’t know if those new nodes are necessary for them and if they can be recreated without them (I have node groups myself, but haven’t tested exactly how much you can do with the ones provided here, I assume more).

And to anticipate one possible answer, which is that those tools probably have better performance than textures made as node groups: Instead of singular faster texture nodes I would prefer developers spend time on general optimizations of shading nodes, so that EVERYTHING is faster. This node will not cover every single node group we will have to create (although it seems to try that for some reason), we’ll still need faster noise/voronoi, faster math operations, we will need repeat zone in shading, so my intuition tells me that it would be much more beneficial to do those which will mean we can get all those textures AND everything else is faster too.

[Hadriscus]

@nickberckley

Names “Raiko Texture” or even “Raiko Base” doesn’t say absolutely anything to user.

I don’t think this particular argument has validity, texture and noise types are named after people too. Although those are historical staples of CGI, usually derive from published papers (Perlin, Gabor, Voronoi…) and appear more focused than this. It feels like they “earned their name”, so to say. Anyway, the naming probably shouldn’t be a concern for judging this particular proposal.

[Hoshinova]

I think the initial post from Raiko was a little unclear so let me clarify some things. The “Raiko Texture” with the 21 page pdf was only mentioned for historical reasons. Nothing from that pdf is actually in the Pull Request.

The actual Pull Request starts at: “Now to the main part”.
Raiko has already improved his post to avoid such misunderstandings.

[scopelma]

After playing with the proposal, I also see how this could be implemented as node groups. This is true, though, also for some basic nodes that are already part of shader nodes (i.e. Gradient Texture). For this reason, I could actually envision a simple, “Rounded Polygon” node akin to what here is called “Raiko Base Texture”. It could certainly save many nodes and it could be intuitive and useful. I think the Raiko Base Texture node could be made more similar to other nodes that are currently shipped in Blender and be renamed to Rounded Polygon. I’m sure it’d be useful in this format and it would be coherent with other nodes that are shipped in Blender.

Regarding the naming debate: it is true that Gabor, Perlin and Voronoi carry the names of their creators (from the previous century). However, I think that nowadays, in opensource projects, things tend to be seen more as a collective work and people tend to submit their work in this scope. Therefore, for example, Cycles is not the Brecht Path Tracer or EEVEE the Clement Foucault Engine

The Linear System Solver could be really useful. Not a dev, but I think you should decouple it from the Rounded Polygon proposal and send a PR on its own. I’m sure many technical artists would find it handy!

[AntoineP]

This post seems to contains three separate proposals that should each have their own submission:

1. The linear system solver.
   The vast majority of users (including me) won’t have the math background to use it. I don’t really have an opinion on the usefulness of such a specific node. But I would definitely use an “Array” node with a parallelogram sub-type.

2. The Raiko base texture
   I like the “Rounded Polygon” name suggestion, it clarifies this proposal massively. I think it’s a useful node but there are too many parameters on it, some of them which aren’t even used in any of the use case examples. I would rename “R-sphere field” to “Distance” and “R-gon parameter field” to “Factor”. I’m not sure what “Max unit parameter” would be used for. The inputs “Elliptical corners” and “Sphere convexity” don’t seem to do much from my testing, and “Base convexity” doesn’t behave quite as I expected.

3. Elliptical remap
   This is an interpolation method and IMO should only be considered as part of a bigger interpolation essential assets pack.

Regarding the ambition of shipping node groups instead of simple nodes, shouldn’t there be a discussion about performance? Both for execution time and compilation time. I love the idea of being able to explore the insides of every node, but shaders have a high performance requirement.

[nickberckley]

I was told that .pdf which I commented on above is no longer the design of this project, so I will do my feedback on individual nodes. I played with Raiko Base Texture node (haven’t touched other one yet).

I do agree that N-gon or Rounded N-gon would be better name for this node (R-gon isn’t a word in CG as far as I’m aware, not to talk about Raiko anymore). But, having played with it for a while, I have mixed feelings even about that. Generating N-sided shapes is obviously extremely beneficial for procedural shading, that’s why I have N-gon node group myself (as well as ellipsis and rectangle ones), but lot of things about the node doesn’t make sense to me.
Inputs of the node just doesn’t make any sense. Node can produce numerous different results (I’ll touch that in a moment) and every time I would achieve one shape, lets say star or rectangle, and tweak settings and think “ah, so that’s what this input controls” I would then move on to next shape and those inputs behaved completely differently. It seems like all inputs act very differently based on all other inputs (that is always a problem with node groups build from math nodes as well, and this is what it feels like)

This is what 2.4 sides look like with Roundness of 1 (shape emphasized with color ramp)

And this is what 2.4 sides look like with Roundness of 0

So, what is Roundness doing there? What even is being rounded?
W and Scale both do same thing in most of the cases, I would expect W to be time value, or seed as we commonly call it, as it is with other textures.
One truly good purpose of this node I can see is as “random blob/shape generator”, it really exceed at that (this is not a dig, it really can produce some weird interesting shapes), but besides that, for more controlled shapes it can basically produce three things:

1. Rectangular/circular shapes when Base and Space Convexity are at the same value (2), with custom roundness
2. Star shapes with controllable “thickness”, or convex
3. Rounded N-gons

I have node groups for first two, with (what I believe) much easier controls and better outputs (outline for example). I do have N-gon node group, but without rounding, and that’s definitely something I’ll have to spend some time on, it is very nice to have rounding for them.

All of that is for first output (R-sphere Field), second output (R-gon Parameter Field) is basically ‘Gradient → Multiply → Fraction → Subtract’, so definitely can be a node group as well. Third output I can’t understand what does. Examples would be useful.

So, my impression is that Raiko Base Texture isn’t really providing anything that isn’t possible as node group, and is more unpredictable and harder to control, but that being said I wouldn’t be against it being in Blender (given that horrible names for sockets/outputs changes to something more artistic) as it doesn’t add kernels and bloats download size and all that. It is pretty unharmful node. I would personally not use it (and tbh I don’t see either professionals who can assemble better node groups, or beginners who’ll have hard time controlling it using it either), but I have “why not” approach to it, maybe somebody will surprise me and find better uses for it that I could find.

But on UI/UX side, which is what I’m mostly interested in, I would much prefer if there was separate node groups for N-gon, Star, Rectangle, and Ellipsoid, like I have now. It makes search easier and you can add shape without having to remember exact values you need to input in general node to get that shape. I think once asset extensions are done that’s what people will use anyway, regardless of this node being there or not, so again, just not seeing too much value.

[Hoshinova]

The naming will be improved. Generally the main point of the texture is the rounded polygons it can produce.

Regarding

@nickberckley

second output (R-gon Parameter Field) is basically ‘Gradient → Multiply → Fraction → Subtract’

This is not true. You can set up the node tree you described and see that the output is different as long as Roundness isn’t 0.0.

@nickberckley

Third output I can’t understand what does. Examples would be useful.

I’ll refer to the user documentation section 2.6.
(Or documentation section 2.5 in Version 2.)

[Hoshinova]

@AntoineP

Regarding the ambition of shipping node groups instead of simple nodes, shouldn’t there be a discussion about performance? Both for execution time and compilation time. I love the idea of being able to explore the insides of every node, but shaders have a high performance requirement.

There is a push to generally replace the built in nodes with node groups shipped in the essential assets bundle. This decision was made by the Node and Physics module.

[modmoderVAAAA]

Just imagine such conversation for Gradient Texture or for White Noise settings.

[Raiko]

Update: Due to some general confusions and user feedback the Base Convexity and Sphere Convexity inputs will be removed.

The node will be renamed into the Rounded Polygon node to more clearly communicate it’s usage.

[Joze]

I tested the Raiko Base Texture node from the patch build, and i like it. It seems to be just as useful as the other texture nodes. Good for lots of stuff. Renaming to Rounded Polygon like you mentioned in your update seems good from an artist perspective.

[nickberckley]

Now we’re talking. Looking at new screenshots it looks very good. Didn’t want to wait for new build, and wanted to look at it from new perspective, so I tried to recreate every example shader in provided .blend file with either my node groups, or from scratch with vector math/coordinates. I only used inputs that are left in new version.

I did succeed technically in it (only tried couple, there’s a lot), but working on your node on lower level, alongside vector math (instead of trying to create just rounded rectangles) did prove to be much easier and more pleasant experience. Looking at new node as low-level base for building custom shapes, instead of finished product opens up many possibilities.

Rounding works very nicely and looks good on every value, something I’m always struggling to achieve with my broken math skills. Elliptical corners toggle also is very nice. I also like weird shapes you can get with non-rounded side inputs, as I said in previous comment.

@Raiko @Hoshinova my remaining feedback on this particular node would be:

1. Instead of float scale, I would provide it as exposed vector, reason being that if you want to create rounded rectangle and try to use mapping it stretches rounded parts as well and looks bad. Instead, I want to be able to scale shape only on one axis and have corners keep their rounding perfectly.
2. Since this is very versatile node and can create endless shapes, rounded or not, name seems wrong to me (I know, I know, sorry about that). I would just call it “Polygon”, not even Texture in the name, but that’s my opinion. Rounded part in the name doesn’t tell you full range of what it can do.
3. There is no need for panel anymore in the node with so few inputs.

My biggest feedback would be to create separate PR just for that node. It is a low-level node which I believe fits into Blenders design nicely, while other parts of your proposal doesn’t yet and needs many discussions and back-and-forth in the modules. Also, from what I’ve seen reviewing giant PRs is always problematic and drags on.

This particular node is useful whether or not entire “Raiko Design” gets merged, it is useful regardless of Linear System Solver and remap node groups. It’s not dependant on anything, so it should be treated as separate sub-project I think to increase chances of approval.

[Hoshinova]

Ahh ok, now I know what you mean, nice idea!

The thing is although the algorithm for computing the rounded corners is actually much more complicated than the output suggests.
It’s definitely worth researching but Raiko probably will take some time to develop an algorithm for a vector scale input.

So I’d say it’s going to come in a future PR, not because it’s a bad idea but because it’s hard to develop.

[nickberckley]

Getting rounded rectangle isn’t easy, if I use mapping I get this

Rounded corners get stretch. Instead I want to get this:

scaling should happen before rounding is applied to avoid this, which I’m not sure how to do with nodes

[Hoshinova]

Ahh ok, now I know what you mean, nice idea!

The thing is although the algorithm for computing the rounded corners is actually much more complicated than the output suggests.
It’s definitely worth researching but Raiko probably will take some time to develop an algorithm for a vector scale input.

So I’d say it’s going to come in a future PR, not because it’s a bad idea but because it’s hard to develop.

[Hoshinova]

@nickberckley

Since this is very versatile node and can create endless shapes, rounded or not, name seems wrong to me (I know, I know, sorry about that). I would just call it “Polygon”, not even Texture in the name, but that’s my opinion. Rounded part in the name doesn’t tell you full range of what it can do.

Hmm, I’ll think about the name though just naming it “Polygon” also seems to be misleading to me since it’s not “just” a polygon… But that’s just a detail that can easily be changed.

@nickberckley

There is no need for panel anymore in the node with so few inputs.

Yep, I’ll remove it before the release. I just don’t want to ask for another packaged build again for a minor change.

@nickberckley

My biggest feedback would be to create separate PR just for that node. It is a low-level node which I believe fits into Blenders design nicely, while other parts of your proposal doesn’t yet and needs many discussions and back-and-forth in the modules. Also, from what I’ve seen reviewing giant PRs is always problematic and drags on.

I actually talked with Jacques about it and he recommended me to put it into a single PR.
There are some reasons for that:

1. Most examples from the demonstration .blend files wouldn’t work otherwise.
2. I was under the false impression that the Linear System Solver node and the Elliptical Remap node groups were already approved by Hans anyways, so the main thing to test was just the Rounded Polygon node.

[AntoineP]

The node looks very accessible now!

Maybe we misunderstood what the previous convexity parameters where controlling, but I think a general convexity parameter would still be really useful. One that simply curves the edges of polygons in an intuitive way.

[HooglyBoogly]

@Hoshinova

The Linear System Solver node and the Elliptical Remap node groups were already approved by Hans anyways, the main thing to test was just the Rounded Polygon node.

We had a brief discussion in chat where I was more positive about that than the rest of the plan. I didn’t “approve” them because there was no formal method to do that. Generally I find this process of talking to developers individually and playing telephone with those conversations a bit frustrating.

[Hoshinova]

@HooglyBoogly

I didn’t “approve” them because there was no formal method to do that.

Ok, sorry, I misinterpreted what you were saying. I sincerely apologize for my communication mistake, it wasn’t my intention to twist your words.

@HooglyBoogly

Generally I find this process of talking to developers individually and playing telephone with those conversations a bit frustrating.

In past projects I’ve been using both public forums and private Blender chats to communicate with other developers and artists. I can also not use private Blender chats if that’s to your liking.