A Way to Make Variables More Intuitive? 🤔


#1

Continuing the discussion from Multiply texture UV:

So I was working on variable nodes, but it seems like, due to a limitation of the Blender API, I am unable to dynamically hide/show socket inputs and outputs of a node based on the GUI elements in the node. You can only show/hide the sockets based on a button click, not a checkbox or an enum field. I think this kind of defeats the purpose of the variable node, but I also think that variables need to be more intuitive. Anybody have any ideas?

This was my WIP string variable node:
image

The design above was the attempt to combine the get, set, and variable name into one node ( with these features being inherited for every value node ). The In and Out sockets were only supposed to appear when you were in Set Variable mode, but I couldn’t get that to work. Maybe I’m over thinking this…:thinking:


#2

The node could be a generic variable instead of String, you choose variable type on a list ?
No need checkbox, some connection to input or some value means Set, while only output connection means get. I’m not sure the node needs In and Out.


#3

It needs In and Out if you are setting the variable because it is an action and the In and Out nodes control when the action is executed.

The problem with a list is that values like Vector have the X, Y, and Z inputs to set them, and we can’t change the inputs based on a dropdown selection ( as far as I can see in the Blender API, might just need to wait for somebody who knows the Blender API better ).

Unless maybe we don’t need to change inputs. Maybe we just make it a dynamic type. So you have a variable that has a Name field and a type output. Maybe we want a Variable node and keep the Set Variable node. The Variable node doesn’t have any input at all and just has a name field. That would make it intuitive. So it would be pretty much the same except that you can use the Variable node instead of the String, Vector, Float, etc. nodes, and that variable node can be used for any value type.


#4

The actual variable works, it’s just confusing how it is used.
Perhaps we should distinguish variable and constant ?
A constant never changes, while a variable can change, this could simplify things.


#5

I guess I don’t understand the confusion. The get set properties does all the variable stuff and the constants are handled by the variable nodes themselves. The naming is a bit funky but once you get that it all works for me. With the ability to give the same variable name to any object you get a slow but very workable version of tags too. As I have said it would be cool to have all of it in one node but that may be us trying to put too much coding knowledge into how we would use the nodes.


#6

Properties are actually different than variables. I think properties in Blender can only be floats. Variables can be vectors, floats, bools, objects, or anything else. Variables are set with the set variable node, and can be read from by creating a value node with an ID that is set in a section of the properties panel in the node editor. I did some explaining of how it worked in this post.

It is kind of confusing to use because of the mysterious ID property in the right sidebar, and the fact that when you get a variable value, the values shown in the node don’t actually have anything to do with the value that you are getting. I can give a better explanation later if you need clarification.


#7

the set property and set properties are Variables as far as nodes are concerned in Armory. You can store any of the various types in them and attach them to any object or a global object. You are “confusing” what is being used internally in blender with what most of us (I think) are speaking of in terms of nodes. I have used them many times with out the id as a way to track information across a node tree just as you would in a script. There is a crossover if you are trying to change a setting that blender uses and that actually get translated into Armory as far as graphics or physics.

You might be diving a little beyond what is needed there ( not really sure ) depending on what you are trying to accomplish. Your String picture at the very top is just the get property and set property nodes combined and limited to strings. The ones already in the node system can handle any type of variable( float, string, integer). So just trying to make sure you are not trying to reinvent the wheel because of a difference in name. If you already knew all this and assumed I was talking about I apologize. It’s just that these terms are all being used for very different things depending on the context of Nodes, Blender values, Coding and probably more.


#8

OK, so I wasn’t aware that properties were that complete. Because of the presence of variables and properties, I had mistakenly assumed that Properties were specific to values tied to Blender’s custom properties and that variables were equivalent to variables you would define in code. I had seen the logic_pong example and it used the ID field to create the variables; that very well could have been before the existence of the property nodes, I don’t know, but if properties handle getting and setting across the node tree with any type, I don’t see any reason to “fix” it.

Very good to know, thanks! :smile:


#9

Yeah I think that Variables were named so because they are the Types of variables in a node. Properties are any storage of those types of information. I can see how coders especially would get “confused” since variables are both within all the coding I have ever scene. I really don’t know why they are named as they are. I do wonder if Static properties are more tied to blender information or if they are something else altogether. I haven’t figured them out.