Armory: Redundant nodes shouldn't be removed?

[knowledgenude]

Having different nodes doing the same thing don't give any benefit. It can increase the size of nodes list and give extra work on documentation. I am trying all nodes to write its documentation, then i report everything i think is wrong. But I can't change nothing in Armory with what i know today.

I am reporting this just to avoid projects killing in the future.

A example is Get Rotation, Get Location and Get Scale nodes... why use them if we can get the three values from Separate Transform with less space in the UI?

[MoritzBrueckner]

There is an unused feature in Armory that automatically replaces deprecated nodes. When I get some more time in september, I'll try to reimplement it for some nodes, like Keyboard and OnKeyboard. This way, we can remove old nodes without destroying projects.

Off-topic:
Because we're talking about the nodes list: we should give the nodes more meaningful icons and think about what icon represents what category/node. Currently this is a mess since Blender now displays icons for nodes and some Armory nodes use them, some not.

Maybe we should also split some of the bigger categories into two or three smaller ones?

[knowledgenude]

I think that icons are not necessary as they are very small and hard to recognize. But i think that Armory need a pattern to follow, then all nodes should have icons or none of them.

The user will stop searching the node in the list and search by its name some time, but for a first impression of the engine, it is important to don't leave a large list of nodes. Spliting the nodes list would be a very good thing :)

Like a list for Canvas, Get Values, Set Values, Physics, Graphics, Operators, etc. Just other idea here: is possible to make Armory search for nodes in a directory? Example: Nodes/Physics/nodename, then the node is displayed inside Blender. This way each user can custom it in his personal taste.

About searching nodes, I think it is related to Blender and not Armory, but i suggest a way to don't consider space and words placement in the node search tab. This way is possible to search for getobject, getname, etc. without the need of space

[MoritzBrueckner]

Maybe we should start a list of redundant nodes in your first post in this issue to keep track of the progress (if there are a lot of nodes that need discussion)?

I think that icons are not necessary as they are very small and hard to recognize. But i think that Armory need a pattern to follow, then all nodes should have icons or none of them.

+1

Just other idea here: is possible to make Armory search for nodes in a directory? Example: Nodes/Physics/nodename, then the node is displayed inside Blender. This way each user can custom it in his personal taste.

You mean custom nodes? Custom categories are already possible for them. Or do you mean rearranging the node definition files in the SDK? I'm not sure if that's a good idea because the local configuration would be overridden by updates.

About searching nodes, I think it is related to Blender and not Armory, but i suggest a way to don't consider space and words placement in the node search tab. This way is possible to search for getobject, getname, etc. without the need of space

I really miss this feature too but it's indeed a limitation of Blender

[knowledgenude]

I found i lot of repetitive nodes, but some of then i never used before to know exactly what they do:

in green are the ones that can replace and red the ones i think should be removed

untitled.zip

There are a lot of nodes that could be mixed to get a better use of the UI space and reduce the clicks. Also having one node full of functionality should contribute to better developed nodes, focusing quality over quantity. But i don't know in terms of performance.

Also there is a small typo:

You can tell me better which node should stay in there, so i can make the list properly

[knowledgenude]

1. I've removed the icons from all nodes. After the list becomes ready and "static", we can set each icon according with the list name. I hope that i will learn to make a PR this time :)

2. Fixed the small typo

3. I will list all nodes to be removed and put some notes on each one.

4. What do you think about removing the ( ) from some labels? Like Array (Float), Array (Vector), etc. and remove some extra words like from 'Cast Physics Ray' to 'Physics Ray'

5. I don't know how to mention text, but about the Custom nodes, i can't get it working. Armory don't show my custom nodes in the list. I want it to do tests. But I will try it other time

I am trying to learn something to improve nodes, but i can't access the forum to clear doubts. There is some way i can go? For example i am trying to add more conditions to the gate node to get rid of nodes like branch, etc. and make some conditions related to positive and negative numbers.

[MoritzBrueckner]

I think this is something that needs to be well thought-out. Changing to much of Armory's nodes will potentially scare some users away but I agree that nodes require a big update to clean the current mess.

Before changing/removing too many nodes we should really thing about the small details for every node in question and if it's really an improvement. As far as I know Lubos' concept was to create more smaller nodes instead of few big nodes to be more beginner friendly. We should definitely wait until I get time to work on the node replacement system that replaces old and deprecated nodes automatically so that we can safely replace them without breaking the users projects.

What do you think about removing the ( ) from some labels? Like Array (Float), Array (Vector), etc. ...

Sounds good. It's important that we don't switch the word order like Float Array because that would destroy the alphabetic order of nodes in the menu. Maybe choosing the array type from a dropdown menu in the node would be the best from a user's perspective but it would lead to a really small overhead during runtime because for every execution the type would have to be checked and we would probably have to use dynamic types which are slower on static targets. If nodes would allow different haxe code for different settings that would be great but on the other side that would make things more complicated again.

... and remove some extra words like from 'Cast Physics Ray' to 'Physics Ray'

Different suggestion: what about Ray Cast? The physics part is implied by the node category.

but i can't access the forum to clear doubts. There is some way i can go?

As far as I know Lubos said that he will contact the forum admin (it's some other guy) about that issue but I don't know the current state of that.

Regarding your screenshot:

• The Self node might be unnecessary but I think we should keep it, it can make stuff much more easy especially if the node tree is used on different objects
• I don't know what global object is used for, but as long as we don't know it we should keep it or ask Lubos^^
• There is a difference between Translate Object and Translate On Local Axis, the first does a vector based translation whereas the second does a translation on one, local axis. But we should probably just combine them and merge the second into the first node.
• Append Transform and Set Transform are two different things. Transformations work via matrices and you can multiply multiple matrices to get another one. So Set Transform sets the "final" matrix whereas Append Transform just multiplies another matrix on top of the already existing transformations. Think of that as sequential execution: first apply transformation A (a rotation for example) and then transformation B (scaling e.g.).
• Regarding the gravity nodes: disabling the gravity makes it possible to suspend it without loosing the gravity values which might be helpful
• Transform nodes: I think this is a good example of nodes that are more beginner friendly although they could be combined. Many users will probably search for "Rotation" instead of "Transform", so keeping seperate nodes for that might be good.
• I don't know what the virtual button thing does but it definitely is something different as the canvas node (I think?)
• The same goes for the mouse coord nodes, I don't know if there is some difference.
• The replacement of the timer nodes looks good to me

Thanks for your work on that!

[knowledgenude]

I like the 'Ray Cast' name, but i don't have changed it in PR to keep the same reference as in .hx / .py files.

I also don't have changed the list organization for now because of the prefix in .py files names.

The On Timer node is good for some cases because it acts like an event different of Timer node. Sleep can be suitable because of its size.

About the sensor/mouse nodes, i think they are almost the same, because both are converted depending on platform.

So I think is better to keep all nodes in Armory to be more user friendly. Thank you for all the information about the work of nodes, it need to be in the Wiki :)