Some time ago it was announced that Blender is going to get an interactive mode, which can be used by integrated game engines to let the user create his own logic with nodes. The letter said that they will hire someone to design it, but now already in the latest development log the are showing are tease for it.
You can see 4 nodes that translate an object with keyboard controls, and cubes that rotate “On Update”.
So yes, Lubos already said that Armory is going to take advantage of this system so all logic nodes are going to change completely. I think that is a good thing since they are hiring an actual designer for this and the current Logic Nodes have a couple flaws, for example that it is very hard to create something like functions that can be called again with different parameters. I just hope it won’t be similar to BGEs Logic Bricks in any way which were extremely restricting imo.
But does that mean the old Logic Nodes will only be available in (in the future) old versions of Armory? It would be nice to see a “Legacy mode” for them, but I think throwing them out is justifiable since Armory is still in early access. That also means all current Logic Nodes tutorials are going to be obsolete.
But certainly all Haxe definitions for the nodes will have to be changed, and some things that work in the Blender viewport probably won’t in Armory right now. So a lot of work will have to be done, once the time comes around I will try my best to get the easier nodes working but I will have to pass on a lot to someone else who is more familiar with that stuff than I am. I hope that others in out community can help Lubos as well so he doesn’t need to waste time on this when he could do more important stuff (ähem fix bugs).
I was wondering how this would effect Armory. For myself I will continue to produce tutorials because i believe the more you understand the logic behind the nodes and way you “think out” a node tree won’t change. The specific nodes might or maybe they will even adopt some of the work that is already done and place it into Blender. Also right in the interview Jaques said this would be at least a couple months away and the logic stuff seemed to be lower on the list then say particles and other systems in blender. I could be wrong on this.
Also if you are able to build everything in blender you should have a much easier time updating your projects in the future. We are all going to have to move to 2.8 if you haven’t already and that in itself is a change and will require some slight updated of current projects.
All and all this is a good thing. The more support for all these systems the better they will probably work in Armory in the future. But I totally agree that what ever help people can give would be great. Programing is not my forte but I am trying to work though creating some simple games and see what is and is not possible at this time within the Blender/Armory Universe.
Perhaps Armory could use an external node editor for visual scripting.
Somewhat like Haxe code editor.
Armory should keep Blender mainly as level editor, and what is related to coding gameplay should be out of Blender, because Blender features could change any time.
I don’t think that blender changing is such a problem. I think using blender to the fullest is strength of Armory,
as this allows to concentrate on engine more. Armory changes, Blender changes, these projects are alive and that is great.
@MagicLord - part of the point of armory was to be able to create everything inside of one program as much as possible. There is no reason to move the logic nodes outside of blender. @slapin is right Things are going to change but that is because both Armory and Blender are in high development.
Why they spend time in 2.8 creating again gameplay nodes ( that would translate to other 3D engines ) ?
Unity users will stay with Visual Studio Unity or a Visual Scripting plugin , while UE4 people will prefer to create Blueprints directly in UE4 the editor.
Did they really asked to active game developers what they think ?
Again, Part of this is so you never have to leave blender to do these things.
Interesting… BUT… in the video he does state that the person working there is only there for a week and then might be back. I worry of the lack of focus that could be had by a dedicated developer (armory 3D). Wasn’t that a problem with the BGE? That it was basically pieced together haphazardly over the years by multiple coders?I don’t know much about it… it’s just something I think I have in the memory banks.
It’s the old “Dabler in all, Master of none” problem.
The designer I meant was “Benoit Bolsee”, here the announcement from Ton on that topic:
The outcome is that Benoit accepted a grant to work as designer and lead developer for one year on bringing back a good real-time interactive 3D system in Blender. He will do this part-time, in average 1.5 days per week, starting July 1st.
Obviously all work and further discussions will be done in public; using our regular channels (mailing lists, code.blender.org, developer.b.o, devtalk.b.o). Help from other Blender developers is very welcome. This will be further announced when Benoit starts.
To summarise, work will first be done in two areas;
- Implement a high quality real-time viewport with physics/event handling.
This should result in a pleasant & usable environment to setup and bake simulations.
- Design and prototype a new nodal logic system.
Related to this work is also to enable good support (export or some kind of integration) for external game engines such as Godot, Armory, Blend4Web, Unreal, Unity, etc.
I especially invite the first three (open source) projects to connect with us to find ways to keep a high level of compatibility.
@morbott I believe you are refering to Jaques Lucke, He the the creator of animation nodes and is helping with the “All Nodes” project. While the two project obviously work together they are not the same thing. One if specifically about working with real time and the other changing much of blender functionality to use nodes as the interface.
Thanks for the clarification. Fingers crossed.