Various Node Group Ideas and Improvements

[dibli-goost]

Here's a some general things I found myself wanting as I've been testing out the new Node Groups branch, I might add more later when I think up some more.

1. ) I think it might be useful to add a reload operator to the actual Node Group node. So that you don't have to re-enter the node group or select the pre pass/main pass outputs to reload their properties. Perhaps a better solution entirely would be to add a reload operator to the material tab? Pretty sure most people just always have the properties window visible, and it'll probably be on the material tab if they're actively working in the Node Editor.

2. ) Min Max options for input properties would be useful as well. As already mentioned here: Node Group Input parameters lost their min max clamp #403.

3. ) I think float would make more sense as the default property type, rather than a boolean, I've personally used float the most.

4. ) An operator to create a new Node Tree (and automatically select them) on the Node Group node would be useful. Btw i'm getting crashes when attempting to use the edit Node Tree operator when no Node Tree is selected, I'll have to make an issue report after this.

5. ) Input properties should have the ability to be hidden, so that you have to plug something into them, similar to the Normal inputs on the various shader nodes for example.

6. ) I actually rather like to color code Node Groups, as well as relevant nodes to visually distinguish various parts of a node tree apart, and clearly denote relationships.

I think it might be a good idea to add the ability to automatically color a Node Group based on it's Node Tree, that way every time I load that VFX Node Group there it will always be red. Don't know where the setting would be, maybe the output properties in the node tree? There you could set the default color for the node, and override it if you'd like later as usual with property overrides in Malt.

7. ) Re-Ordering of Node Group properties would be nice, same goes for Material Properties too honestly.

8. ) What's the possibility of getting a similar render layers/screen pass functionality out of Node Groups? I'd like to be able to convert inputted colors to images via them, but on the mesh level rather than the screen level. I know that this isn't usually possible in rendering engines. But... is there a chance we could get that functionality? I'm a glitch artist first and foremost.. and let's just say there's a lot of fun to be had there 😎

I guess what I'm really asking for is some sort of live image baking solution? I think it could be neat. Btw, this is actually what brought me to Malt in the first place. I was looking for a solution to it since EEVEE and Cycles couldn't do it, people told me it might be possible here, so here I am 😄

---

So far really happy with the implementation, feels really nice to clean up my node trees. I plan on releasing some node group collections as well once it's in a more stable state.

[pragma37]

1. I don't get this one. Why would you need to reload the group if you aren't editing it?

2. Agree, but all these little "nice to have" features have an implementation and maintenance cost.
   I have to be realistic about the resources I have and draw the line somewhere.

3. Done!

4. Fixed the crash. The feature would be nice, but it's the same as (2).

5. But you don't "have to" plug anything into Normal inputs? They actually mean the opposite.

6. It's not a terrible idea or anything, but again, same as (2).

7. Done!

8. That's a really big feature. Implementation-wise, it doesn't really have anything to do with Node Groups.
   I know @Kolupsy wanted to look into implementing something like that for "pre-processing" textures, but it's far from trivial to implement.
   The cool thing about Malt is that if you have a very specific use case you can hack it as a custom plugin without too much effort.
   But implementing something like that as an easy-to-use general purpose functionality, fully customizable from the UI, requires A LOT of work.

[dibli-goost]

1. Sometimes old Node Group properties will stay linked to things after deleting them, so in order to remove them you have to first disconnect them, and then reload the Node Group. These properties are displayed as greyed out on the node, like so:
   

I think it's actually better workflow wise for those old links to persist, so that you can tell what was linked before after exiting the Node Group's node tree, and examining it's use in other trees, but it can be a bit annoying to have to re-enter the Node Group in order to reload and completely remove the old properties. You don't really need to re-enter it in order to reload it like I said before, as those reload operators exist on the main pass and pre pass output nodes. But in bigger node trees it can be a bit of a stroll to the closest of those two. It's a pretty minor issue anyhow.

5. Well yeah. What I was getting at was that in order to change the value of the input you have to plug it in, you can't change it via an option on the node itself. But this does make me think.. Could be beneficial in the long run to create some sort of functionality that lets you set a default value for an input property much like normal inputs? Like "hey as long as something isn't plugged in here, use the surface normals instead". I guess that'd also apply to your resource cost issue from before, but it's something to think about 😅

6. Yeah, it is a pretty big ask I know... however I think it'd be pretty on the mark for Malt. A lot of the intent so far, at least to me, seems to be to align with design principles of 2D painting/image editing software. @Kolupsy did bring up using Node Groups to blur inputs somewhere before, live baking seems like the ideal solution for that. I suggested it along with the other ideas because I think that the ideal workflow for this "live image baking" deal would be through a Node Group-esque setup, input values, bake to image, process them as an image, return image output. A separate Node Tree type, called a filter tree perhaps? Focused upon image filtering of course. I think it'd go nuts for NPR stuff. There'd likely be a fairly significant amount of latency introduced but it would be extremely powerful for stills, or even just baking to real textures to use later in Malt in scenes requiring low latencies.

At that point, definitely out of the current scope of Malt. But on the immediate level, a more standard baking node in wouldn't be a bad idea for the near future. Drop the node somewhere in your node tree, input UV map as well as output texture settings, then it would bake to a texture to the mesh at that point in the node tree. While I haven't had first hand experience with it, I've heard that baking in blender by default is pretty bad... In fact Kolupsy themselves made a Baking Node addon for Blender.. I'm not sure how they'd feel about implementing something like that in Malt considering they're selling it though. Maybe they planned on creating a plugin for it in the future instead.

I was gonna put a whole spiel here about a bunch of stuff regarding my workflow, but it's not really suited for this thread (or Malt discussion in particular I guess). It's all very specific to me of course, and won't necessarily be pertinent to the general user. Irregardless of if that idea is implemented, Malt is already extremely powerful for Glitch Art anyways. It would just be the cherry on top.

[pragma37]

1. You can use the tree recompile button for that:
   

_

5. It's a good idea. I mean, if it's useful for regular nodes, why wouldn't it be for node groups? But it's not trivial to implement.
   For now, you could do something like this:
   
   It's not as nice, but it gets the job done.

6. I agree that there are many things that would be great to do in UV-space rather than Screen-space. It's just that, it's a lot of work to implement such a system.
   A regular baking system seems more feasible.
   Something that would be relatively easy to add is an option to render objects in UV-space. Like this:
   https://twitter.com/pragma37/status/1371165649872031750
   Just as a toggle button in the Material panel, then you can use regular AOVs for baking textures.
   It's far from perfect, but at least it would allow baking stuff even if the workflow ends up being a bit clunky.

That, portal(?) looks super nice. It's very different from what I usually see Malt used for.
I actually love to know about your use cases. And I always keep all your suggestions in mind.
Just be mindful that I work on this project almost for free, and that some seemingly "small" features can actually take hours or even days of work.

[DaylightIsJustABotanist]

Pardon me if I'm a bit late, but are there plans to allow for two different kinds of vec3 input for convenience reasons? From what I've seen so far node groups only have the vec3(color) socket, not the vec3(XYZ) socket.

In case my terminology is a bit of, what I mean is this

vs this

Also I am getting an error stating that SBNE facing, SBNE loc, and SBNE rot are conflicting with a previous declaration in autogenerated/nodegroup.mesh.glsl

[pragma37]

but are there plans to allow for two different kinds of vec3 input for convenience reasons?

I guess eventually, but not at the moment.
There's always one more "nice to have" UI feature and I'd rather focus on actual rendering features.

Also I am getting an error stating that SBNE facing, SBNE loc, and SBNE rot are conflicting with a previous declaration in autogenerated/nodegroup.mesh.glsl

Could you open a bug report?