Nodes logic, it is viable?


#1

Should Haxe coding be the priority and let down nodes logic ?

This is from using logic nodes some days.

  • Many functions are only available in haxe and missing on nodes

  • Node variables can’t get a name and use references from other nodes.
    This makes the nodes logic like spaghetti without references.

  • When you define a new vector variable the input is X,Y,Z , there is no input to store an existing vector into the variable with a connection only.

  • Many nodes are not working or incomplete
    LookAt doesn’t work, it would need some axis as parameter to specify the angle we need. GetRotation and SetRotation doesn’t work, they should be quaternions instead of vector3.There is no CreateTransform from position and quaternion rotation vectors

  • Many nodes need rework
    For example the node separateXYZ , should not exist , all vector3 should have as available outputs : Vector 3, X,Y,Z
    Like transform should have as outputs : transform, location, rotation,scale

  • Lot of nodes are not in Nodes documentation, nodes documenation lacks details (for example degrees or radians usage).

Well, for me it’s a no go using nodes in Armory 3D, it’s only good for toying :joy:

I think Lubos would benefit a lot from letting down nodes and focusing on Haxe only, this would avoid to do double work on haxe and nodes.


#2

What good an integrated game engine, when you can’t work with nodes?
I think node framework is going to be the #1 designer tilt option, when it comes to choose among the Game engines.
I work in unity3d , have worked a bit in unreal engine too. For me, scripting for game isn’t something uncommon, but for majority of developers / designers having a good node based framework is essential, since the put more work towards design then scripting.


#3

Nodes shouldn’t be abdomed, it can be real usefull for non-programmer and can also be useful for prototyping.
Lubos should work more on haxe and less on nodes and should depend on community to build more nodes.
About node documentation, I am working on it. I created pull request for LOGIC node documentation(need to be accepted by lubos), only Inverse, switch, To Bool, left in Logic Nodes doc. Then i will move to other nodes doc.
Here my pull request -> https://github.com/armory3d/armory_docs/pull/22


#4

Don’t get me wrong , i like nodes scripting, its what i use with Unreal 4.
But it is lot of time and effort trying to get nodes up to date to Haxen, and getting better nodes (see my explanations above).
It would diminish a lot Lubos work focusing only on one programming language instead.


#5

It’s more about nodes needs a full redesign than documentation (variables reference names, vector outputs for example , rotation and transform) or some nodes not working.


#6

Give him some break. Armory3d is very far away from being a proper game engine, it’s only on 0.5 version, not even on 1. Lot’s of stuff is needed. I feel frustrated working with it, and to be honest, Haxe is like learning another language (i don’t know anything about python, but c#,java are quite different).
But i would suggest Lubos to put more work on logic nodes, instead of Haxe, since majority will be using the logic nodes.


#7

Yes. I agree with you. Documentation is a must. I tried reading some of the code of nodes, and to be very fair, it looks like spaghetti code.
Most nodes don’t work. Node colors are not consistent, nor they provide information about what type of input is their.


#8

Perhaps you are right, perhaps nodes should get some priority.

I mean most Blender users are artists, most are not coders and will use nodes.


#9

biggest problem for me is the spaghettiying with bigger setups. As time goes on there needs to be a way to have a value somewhere without a cable connecting it from 3 miles away.


#10

Nodes are an essential part of armory. They are the thing that lets artistts become interactive content creator. I have done all my work in nodes for over 20 video tutorials. Is it perfect ? Hell no. But I can make a lot work and am still getting more to work all the time. And as stated we are still in alpha or beta. With lots of work to do yet.
I have been looking into Lumberyard and Godot visual scripting and there are completely different from each other. It is so awesome that this was even part of this project from the beginning. With the caliber of the people on this forum we should be able to help built all kinds of nodes and add abilities to them like passing information. I was under the impression that we were here to learn and help improve the engine.
I suck at coding but have been able to figure most of it out and even sort of help in the development of a couple new nodes. Together we can do that.


#11

It would be great to figure out how to do groups for the logic nodes like you can for the material nodes.


#12

Lot of spaghetti would disappear with better nodes, variable name references for example that does not need to connect to the original variable node.


#13

A reflexion about a model near the MVC one could improve this spaghettis problem too.


#14

I still like how Sverchok avoids some node spagetti with the poorly named wifi in/out nodes. Its really just kind of hiding some of the noise but every little bit helps! https://sverchok.readthedocs.io/en/latest/nodes/layout/wifi_in.html


#15

You can already do it with array and index …
I would prefer to have something like a named point like what is used in PCB design tools.

For your info a post was about meta nodes too … "Meta" Nodes

But really I think that if you have a spaghetti problem, it is more due to an architecture software design problem than to the nodes capabilities.


#16

Nodes are incomplete.

Each node variable should have a name and could be referenced anywhere

This would decrease the connections to variables.


#17

Hey I created whole new thread regarding Improving nodes.
Maybe you can put your answer there can all can understand what i am talking about in third point.


#18

@MagicLord
if I may, you have already that with Set Property and Get Property ?


#19

It’s not the same.Property is for object properties.
While variables you create in the graph doesn’t have a name.


#20

@MagicLord If really necessary, you can set a property on an Empty that you call “my variables” and Set/Get Property that do the job ?
Otherwise with Array and Index you can simulate a Bus like on an eletronic card.