 I think I'm ready. Oh, the one with the red light, if that makes sense. Hi. So I'm going to give another talk about nodes in a very different context, I think. This is not laid out live. It's not live at all, or at least the node stuff. It's not meant to be real time. So over the last many years, node systems seem to be popping up more and more in all kinds of different applications, including open source. There's some proprietary stuff that at least deserves a mention, even though this is the Libre graphics meeting. There's nodes like praxis. And the Godot game engine has a node system that seems to operate very similar to what praxis is doing. Blender is probably the most widely known one for the node system that it has. Blender seems like praxis and Blender are both quite good, because it's very extensible. It's very easy to add extensions. If you have a node system that doesn't quite do what you want, then you can construct other nodes that do do what you want. I have a lot of friends who are artists who don't think like programmers and vice versa. And nodes are kind of the middle grounds that let artists mess around with stuff that's normally the domain of programmers. And programmers get access to much more immediate visual presentation. So it's kind of an uneasy middle ground. So sometimes you end up just messing around with little boxes, spending too much time messing around with boxes. So for instance, there's one site called Blueprints from Hell that gives great examples of misuse of nodes. These are from the Unreal game engine, where nodes are called Blueprints. Then you can browse the Blueprints from Hell for many examples, gigantic messes like this, or things that sometimes there is a box connected to 50 things, and then it's connected to another 50 things. So if you're going to make node systems like that, you might as well just program. So it kind of comes back to the uneasy ground. Artists might not really understand programming, so they take these tricks and then end up with stuff like this that could be much simpler if you use code. Another system that's at least as I mentioned is Substance Painter, which has a very extensive node system. It's proprietary, but just as an example of what you can do with nodes with enough node bases. Many of the stuff you can do in Blender too, but it's kind of a little more fiddly. So just with some node systems, you can take one source and then divide it into different aspects of a surface, and then do more stuff to it and do some branching, and then the nodes kind of come back together. And ultimately, you end up with just a surface that you can apply to any model. So you know, and here's just a flash of how nodes look in ghetto game engine, which looks remarkably like practice in many ways. So it's not just for like 3D animation. I've been trying to figure out how to use nodes in a more two-dimensional context. So for instance, this is basically two dimensions. There's just a plane in the background. This was made in Blender. I forgot to pack the actual file, so I can't show you the node setup. It's basically just what's called a flow map. So you have some nodes that take, it's like if you use the IWARP plugin in GIMP, you define a field and you're just shifting pixels around. That's basically what this is doing. You define a flow field and then sample it at two different points in time, then sort of blend it together and you get a more or less continuous looking motion. And the nodes for this, there's maybe about 10, 15 nodes or so. It's not a very complicated node setup, but you can end up with some moderately nice-looking stuff. Let's see. The core of Blender is not so adaptable in some ways. For nodes, you can use nodes to make textures and you can use nodes to make compositing. And then compositing is more the traditional two-dimensional image creation methods. And the materials are more pertaining to like the substance examples, three-dimensional models and basically skinning those things. Let's see. However, since Blender's nodes are very extensible, there's systems that people have developed to do some pretty sophisticated stuff. For instance, this is by JocLoop animation nodes which extends Blender to be able to manipulate geometries and sets of points and repeat things along points. You can do some pretty interesting stuff with that. Another node system that also works in Blender that does similar things is called Sperchock. You can do lots of strange geometry and that's a little more tailored to kind of architectural applications and procedural like structure deformations and things like that. And this is an example of something done with animation nodes. I figure if you're gonna destroy a big building you might as well do it with a giant insect. So the nodes for these, I did pack that. I wanted to do a comparison. So if you try to make a building, you have a lot of repeated elements and computers are supposed to be able to do tedious things pretty easily. So I wanted to compare. Okay, so if I'm gonna do this with a script, how does that compare to a node setup? So this was the node setup to do all of those, all the building creations. So you're starting from a couple of window objects and then all of these nodes are taking that wall and repeating it along one facade and then moving it around so you get four sides of the building. The actual exploding part is just a few nodes at the end so animation nodes makes it very easy to do some operations that it's a little more difficult to do other operations. So all of this stuff is just a big massive of complicated stuff that's much easier to do with coding. So which is more complex? I think it's kind of debatable maybe. So the equivalent of that is about 500 lines of Python. It's probably unoptimized Python so you could probably do it faster if my version was 500 lines of Python or this, which is really more complicated, I don't know. In terms of maintainability, it kind of depends on who's coming back to maintain it later. If you have people who are maybe less interested in learning obscure syntax rules, maybe they can dig into this, assuming that it's like properly documented. Blender has these frames that you can put around things to add extra documentation. Let's see. So even though like in Blender, most nodes are geared for three-dimensional use, in terms of two-dimensional image production, it's an easy way for artists to create something and then cycle through a bunch of different variations and then pick something that they want or they can save node systems to define kind of a general style that they want. Then like if you're making a comic book, you have 100 different scenes, but you might want a slightly different weather or a slightly different building materials or something in it as backgrounds. So it's much easier just to have just a library of stuff you can immediately apply to it and then kind of squash it down. So there are applications that aren't quite live geared for two-dimensional production. That's kind of where I'm coming from. I've done a lot of comics, but over time it just takes so long for me to draw. I keep looking for ways to make it faster for me to produce work. I end up spending a lot more time programming than actually making artwork, so I'm not sure what I feel about that. It's kind of, there are trade-offs. So in my own software called Layout, I've been trying to implement something that takes the best node practices from other stuff and tries to put them all into one place. And hopefully, since nodes are becoming more popular, figure out ways to use different node systems and be able to use them across applications. So for instance, here's another animation nodes example. It's the same sort of node setup, just like taking some pieces and just the simple transformation makes things kind of bug out. All right, so I've been working on this over the last couple of days, so I never quite know if these live demos are gonna be quite what I expect them to be. And part of the backbone I'm using for this node tool is using Gaggle nodes. Gaggle nodes internally are node-based. It's basically a C library. And it was shockingly easy to map the Gaggle nodes into an interface, because you can query each property and that usually has documentation. So it's pretty straightforward to map things together. So one thing about nodes, like whenever you investigate node systems, oftentimes there are these big masses of mathematical nodes, like just simple things like adding and multiplying. When you write it, it's just like a number and another number and you put like a slash or an asterisk between it. And it takes very little space, but in nodes it takes a massive amount of space, just kind of irritating. One thing in Blender that's missing is an expression node that would simplify these massive things of math. It would be nice to have like a compiler to take expressions and then map it out into nodes so that you can take it that way and then compile them down into expressions if that would be easier. I haven't quite implemented that yet, but that's kind of on my to-do list. So one thing, another thing, when you download stuff off the internet node systems and you try to figure out what's going on, like in that slide before, it's often just a gigantic tangle of wires and connections and it's hard to really tell what's connected to what. So I implemented something that lets you just click on a string and then it automatically kind of follows it around. So it doesn't make nodes necessarily easier to use, but it makes it easier to figure out. And sometimes, like I mentioned before, maintainability can be a factor for reusability. So this node setup lets you change one value and it calls some Gaggle nodes and does a chunk of math below. And then this would be a very simple way to do animation using Gaggle nodes from a node environment. And so I have threads sort of implemented. It's like fake threading as soon as my menu comes up. So instead of being tied to a single value, so now if you have this loop thing, it just can automatically process through Gaggle nodes and you can get some stuff out of the end. One thing with Gaggle nodes is that sometimes the operations take a lot of time to do. So if the connections are secured, there are some nodes that save to files, for instance, the Gaggle save. So if you change one value, it updates this whole node system and then automatically saves to a file. That's kind of irritating. Some nodes I put on extra properties to control whether something gets executed or not. So now if I run this loop, it constructs a file name. Come on, let me drag that out. Let me drag that out. I fixed one bug this morning. It wasn't collapsing with the proper width. And I think I accidentally broke being able to expand the width of these nodes. And anyway, so now if I run this loop all the way, it creates a whole bunch of, so it's now created on disk. So did I get all those? Let's see if this works. So it's relatively easy to use these Gaggle nodes to make simple stuff like this. It seems like maybe it's just because I'm not familiar with Gaggle nodes enough, but the built-in Gaggle nodes are very basic for if you want more complicated gradients, you have to do something on top of the base Gaggle nodes. So in late out, I'm still trying to figure out how to make these nodes more extensible. You can, however, import existing XML. Gaggle can save and load XML files, and I wrote an importer to grab these XML files, which I would show you when I tried it this morning and somehow I broke that too. But this is very much a work in progress here with late out. Oh, another thing about nodes that's often kind of irritating, in terms of making two-dimensional images, it's important to be able to preview things step by step. So it's just kind of the visual way of debugging things, but oftentimes you can't really get at what the nodes are. So being able to preview things at different resolutions becomes quite important. With Gaggle nodes, each Gaggle node kind of does a process on an image, and some of them expect a certain rectangular image to operate in, and some of them don't. So sometimes if you connect Gaggle nodes here, it'll hang because it assumes a gigantic two billion wide rectangle. So sometimes you have to be careful about what area you're actually sampling. So you can kind of change, like this, the radial gradient creates something, but it's not technically bounded. You have to use another crop node to bound. So some of these nodes, instead of resizing the preview like that, if you hold down just modifiers, you can get a different view of what area in this image space you're sampling. So Gaggle nodes for one area external to laid out that I'm trying to integrate. I've also been working on SVG filters. So this, for instance, is all of the Inkscape SVG filters that you can import, and then work on a node basis. So I wrote a very simple untangler, but as you can see, it's not really untangling anything. It's just kind of, it's making it not overlap, but still doesn't necessarily make rational sense. And another feature that's, I seem to have broken over the weekend, is I wrote a Python extension for Inkscape so that within Inkscape you can make something with a filter in it. Let's try to have it still running. And then you call this extension, and then that relays that SVG file to the laid out node editor specifically. So you don't have to deal with the rest of laid out, just the node interface. The processes, so you can take the SVG filters that you might make in the filter editor in Inkscape, but then manipulate it as nodes and then export the file back out. So it gets sent back to Inkscape, so it's potentially possible after some debugging to manipulate SVG filters with nodes. I'm still trying to figure out how to map SVG filters to Gaggle nodes, and then you could be able to have a live preview of what you're doing. That's not quite there yet. My to-do list keeps steadily growing. So I keep not making cartoons and instead hack away on this thing. So a couple of years ago, Peter Sikking gave a talk about node interfaces, and he suggested one thing that's, he was trying to simplify the node setup, which I'm not sure is quite what you wanna cut off, but one thing that is kind of along those lines is being able to select specific properties within the nodes. Like oftentimes you'll have 50 nodes or whatever, but you only care about a few different properties. So I have plans to make separate panels that you can hover off to the side or use in other parts of the program. And so you just manipulate those properties in a separate panel, and that relates to the whole node system, which updates and then updates whatever objects you're working on. And another integration with nodes is I'm trying to bridge the gap between like specific interface controls and node setups. So like there's an affine transformation to transform objects, but if you have other node-based stuff attached to it, this would be, it's almost a linear list. So if there were like a string of 10 node operations that are known to have specific tools associated with like little widgets you can drag around, it would appear in this list up here. And it's not quite working yet, but you'd be able to like mute if a filter is operating or not. So this is just kind of a shortcut to get at different interfaces. You're not actually seeing a live transform because I couldn't get that debug before today. So many things to do. But so this would be the node setup for that. It's just a very simple linear list. But since it's in a node arena, you could tie it to all kinds of other values to kind of drive different aspects to it. I had one that was just an affine transformation unless I broke it in the last half an hour. So if I get rid of these other ones. So now I can manipulate nodes here and have it be kind of a live update. Then I could later on put in other nodes, other filter nodes. And then those would show up up here. And so you'd be able to get at the interfaces to manipulate stuff that's sort of controlled by nodes and sort of controlled by more traditional artist manipulations. And so I have a workshop tomorrow. And if you're interested in talking about node interfaces, what you like and what you don't like, I'll have some examples of blender texture creation and playing around with this stuff. A little bit of debugging session perhaps. And I have a final slide here. Oh, it's more things on my to-do list is to take Gmic and create nodes out of them. It's compared to Gaggle. Gmic is considerably harder to figure out individual pieces. I've looked at the GIMP implementation and the CRETA implementation. They're both equally dense to figure out what's actually going on there. So in time, I'll figure it out somehow. I also want to implement graphics, magic nodes, any system that has basically isolated operations that can be chained together. I'd like to be able to have some system that can more or less seamlessly translate between them. And sometimes when you crunch nodes down onto a screen, it's difficult to figure out what's really going on. So the obvious solution to that is to get rid of the screen entirely and do everything in virtual reality. Virtual reality comes with its own problems there. You have to deal with the natives there. And that's it. I don't know if there's questions. Any questions? Just a remark. Is Q what was being asked in for SMG benchmarks or in GIGL nodes, SPG nodes, or what was it? Oh, so there are some GIGL nodes that are specifically named SVG, this or that. But I haven't figured out a way to represent all the different SVG filters with GIGL nodes. So once I had that, then I could be able to live preview stuff within the node editor, all the SVG filters. But some of them, there don't seem to be a clean map between the filters and GIGL nodes, I can see. Yeah, the SVG purposes are blending modes. I think the SVG is best in mode, basically, so. Does the input in RSVG, something like that, but does the input in RSVG or something like that? And if there is no other questions, I guess that's it.