Make Visual Nodes Great Again


#1

This thread will be about how we can improve Visual Nodes. Add your opinion here and what we can do to improve it. And yeah we need to start doing it now, because for christ’s sake we are near 0.6 build and we will reach 1.0 build in a blink. Here are what features need to be added, feel free to add your opinion.

  1. Improve Documentation for it.
  2. Add and improve colour for nodes.
  3. Variable nodes should have reference of its variable, i.e., We can declare variable x as float and we can get variable x reference without having to declare variable everywhere.
  4. add ==, != in math nodes.

#2

I think we can start step by step.

Variables :

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

This would decrease the connections to variables.


#3

About Nodes Colour:
String-> White
Integer-> Green
Float-> Slight Light Green
Bool->Red
Vector->Purple
Object reference -> Blue


#4

Nodes can already be re-named

It doesn’t do anything with references but it is something


#5

:smile: That’s label.
However, it serves the purpose.


#6

Maybe a ways to do it would be to set a global property with the name of the nodes label to its value (no idea how to get the node’s label in Haxe, and how to distinguish it form the users other properties which may have the same name) on frame 0 and in the “Set Variable” node.

But also, 2.8 "interactive mode" will be coming, with totally different nodes all together. Armory should probably adapt to these when the time comes, and hopefully they will be designed with these problems in mind.


#7

I think Armory should focus on Blender 2.8 and already let down 2.7.
There is so many changes to come, i don’t think it will be possible to maintain two Blender versions for Armory. What we are using with 2.7 is obsolete already.

Better focus on the latest.


#8

More nodes that tie to the Canvas giving visual control over the elements in the Canvas.


#9

Who gonna help me with completing documentation?
Lubos said that we can change the order to this->


Logic is finished(will be tomorrow).
Other needed to be completed.


#10

Remember that 2.8 will change a lot. It will only go into Beta at the blender conference and there will be months of testing. Not sure how smart it is to focus on something that can change at anytime. Also, since 2.8 will have daily builds that mean something how will we keep both armory and 2.8 updated with out building it yourself everyday. blender doesn’t have an auto updater like armory to the best of my knowledge.


#11

Alright, we will stay at 2.79 for now and then we will start for 2.8 when it about like a week or two away.
how about that?


#12

Yeah, I agree. I don’t think trying to keep up with moving versions of Blender, Kha, and Armory is not a good idea. Once Blender get’s their stuff more finalized, then we can focus more on that.


#13

That can become annoying for Amory to get Blender changing a lot, because Armory relies entirely on Blender interface and changes :face_with_raised_eyebrow:

There is advantage to have 3D engines separate from modeling or texturing applications.

Should Armory 3D become like ArmorPaint, a separate product ?
There is advantages :

  • Armory not dependent on Blender changes
  • Better interface like most 3D engines focused on the game instead of getting too much things from Blender
  • While Armory would keep 100% compatibility with Blender files

Blender file synchronization ? You work on some Blender file, Armory 3D engines updates the scene when you modify in Blender the scene.

It’s only an idea but i would see many benefits and better Armory interface and organization to be a separate product.

Most of the time for high quality production you will not do the entire work in Blender , you’ll use highly specialized tools like Zbrush, Substance Designer, MegaScan.
So separate 3D engine is not an issue.

Perhaps too much work, and it’s more easy to follow Blender 2.8 changes ?


#14

For me, one of the most amazing and advantageous things to Armory is its Blender integration. I think it is still a good idea.

If you did the Armory UI separate what would it be for? Assuming you are doing all of the scene building in Blender, what would constitute the Armory UI? Maybe nodes? Either way, I think that Armory’s dependence on Blender is actually not that significant assuming that you do still want to have a fully fledged Armory exporter built into Blender.

Granted, if you did find some way to do a synchronization of some sort there wouldn’t be a huge advantage to keep it embedded in Blender, but you would have to provide a really good integration if you want to keep up with how awesome it is right now.

To your point about specialized tools, that is what ArmorPaint and some other tools that Lubos is designing kind of does and I think that it makes sense, but the Blender integration for scene building is still extremely useful and user friendly.


#15

To your point about specialized tools, that is what ArmorPaint and some other tools that Lubos is designing kind of does and I think that it makes sense, but the Blender integration for scene building is still extremely useful and user friendly.

Those tools have years developement, entire teams, while it’s possible to bring essential features the most usefull, one man can’t compete and make the exact same features.

If you did the Armory UI separate what would it be for? Assuming you are doing all of the scene building in Blender, what would constitute the Armory UI? Maybe nodes?

All Armory related stuff could be some independant window launched from Blender, like some game preview Window with :

  • all rendering options
  • it’s own node system independant from Blender changes
    -Haxe would remain a separate window
  • Armory would create it’s own scene view from Blender file , with more functionality
  • better presentation and more clear way to add haxe nor nodes to objects.
  • it’s own scene setup
  • it’s own object properties, with physics directly included in properties as components stack.

I don’t like a lot Armory stuff mixed with Blender stuff on the render tab for example, there is too much things mixed in.

Or Keep Blender nodes ,scene, object properties and physics,
but move all Armory stuff to a new game preview window with it’s own interface , only related to Armory game setup and preview.

I think all Armory related should be independant from Blender interface and changes. Like Haxe coding is not dependant on Blender changes.


#16

Yes, maybe it isn’t the greatest use of time to build out these tools separately when there are other tools that do the job, but if there aren’t free and Open Source alternatives, then it makes sense to have them. ( I don’t actually know whether or not there are at the moment )

That is a good point. It is also going to be a thing as we move on that there are more features that are implemented in Armory and UI elements in Blender that will not move over to Armory because one reason or another. This can generate confusion because you are not entirely sure as a designer which checkboxes and settings in Blender ( like physics and particles, for example ) will end up exported to your game.

It is definitely worth thinking about how we could produce a still very integrated and helpful solution, that doesn’t struggle at the seams with features and implementations. Something along the lines of what you are saying might be a good idea.

PS: I love that ( :face_with_raised_eyebrow: ) emoji. :grin:


#17

Yes, maybe it isn’t the greatest use of time to build out these tools separately when there are other tools that do the job, but if there aren’t free and Open Source alternatives, then it makes sense to have them. ( I don’t actually know whether or not there are at the moment )

Open source alternative are great, for example Blender and Maya.

Tools are separate because you don’t mix the work you do.
When you sculpt on Zbrush you do that only, you need the best tool.
When you create textures in Substance you only do that, you can’t sculpt at same time.

3D coat is a all in one tool, it’s a too big code base i think, with many things too much dependant.
It has never ending bugs, each time i use it i’m happy with the progress, while there is issues appearing like messed baking or textures or voxel screwed up , for some things i can’t get back if i don’t have save a previous separate version.
3D coat is good for small work, while in Zbrush it’s fully stable and bug free for bigger work

.It is definitely worth thinking about how we could produce a still very integrated and helpful solution, that doesn’t struggle at the seams with features and implementations. Something along the lines of what you are saying might be a good idea.

I agree, physics should stay independant, it’s not Blender physics.
Like Kha window coding, Armory UI should not be mixed with Blender things, some times you don’t know what is what.
There should be an independant game preview for Armory, no more need to select the 3D engine or shaders in Blender, all Armory in a separate window.
It would gain a lot about clarity and usability.:sweat_smile:


#18

Ooh, I’m on the fence about the shaders. :upside_down_face: It is really cool to be able to bake the Cycles scene straight to an Armory scene. Not that I wouldn’t want an Armory shader preview as well.


#19

Or Armory as central application window.
You select a Blender file in Armory and there is options to :

Armory is not released, Blender 2.8 is also changing a lot, perhaps some work could be done to change a little Armory and Blender integration.


#20

I don’t mind if Armory stays integrated as it is, getting Armory a release lot more later without issues is the most important.