I made a rather complex animation in Armory. I’m happy with the result, but the node network has kind of exploded. This is partly due to insufficient control of animations.
I want to make a case for improved animation control.
Currently, all animation actions “auto-loop”. To stop that behavior, you either have to use a Pause Action node or use the Logic Pack (Play Action with Params node).
For simple animations, this is not so much an issue. However, when you do something complex, the number of “animation stops” required gets to be rather annoying. Check the attached image. The orange squares are regular Pause Action nodes, the blues are Play Action with Param nodes from the logic pack.
In my case, having animation control to prevent looping would have removed 77 nodes from the network. This is excluding the 56 blues.
In my case, some of the animations are the reverse of a previous animation. I had to copy/reverse the initial animation since I have no control over playback direction.
I’d like to suggest/request the following improvements:
animations do not loop by default. If looping is required, this is selectable
Lubos has previously denied that suggestion, but I think you make a good case. Lubos understandably wanted to keep the nodes focused and modular without making a bunch of different ways to do the same thing, but I think that this is a good case for a couple extra controls on the animation node.
If we need to it would be trivial to add those options to a custom node, but maybe you could post a link to this post on the GitHub issue asking @lubos to reconsider.
Let Lubos work on Armory, we could try duplicate the animation node and add new options and include that in the logic pack.
The logic pack is becoming a reference with great logic nodes.
Hi @zicklag, I had seen the earlier comment from Lubos. However, building node networks of this size scales up the issue, hence this case for more contol. I have raised issue #1048, referencing this post and issue #979 from @MagicLord.
@MagicLord: I’d like that . Note, though, that work on Krom/Iron may also be required. I noticed that the Play Action and Play Action with Params nodes (logic pack) currently behave differently, see issue #1018. Also, animated meshes and bones sometimes “flash” briefly to the last frame(s) of the previous action and playing an animation sequence multiple times shows different results, which both look like a “frame caching” (if such a thing exists) issues to me. I haven’t raised those issues because I can’t share the blend file as-is (work/copyright issues), I need to pair it down to show specific issues.
On the size of the network: it can be reduced. the pinkish parts are “functions” for camera movement, They could be reduced to one or two blocks if I can get the function nodes to work.
Does anyone have a working example of the function nodes? Either “base” nodes or those from the logic pack would greatly help.
You can create a stand alone small project with that bug, create a new issue on GitHub and add that project to help Lubos identify the issue. This is how i done for physics bugs.
I’ll take a look at Animation and see if i get parameters work.
The function nodes that are now included in Armory are only in the upcoming dev version of Armory. I have a couple examples of those in this post and a patch to apply the update to Armory 0.5 ( scroll down a little to see how to apply it ).
I haven’t used the function nodes from the node pack before, but you can find the original example of them here.
Hi @Monte_Drebenstedt, thx for the videos. It seems that functions are broken for me, though.
Using either:
B2.79-daily with Armory v0.6 ($Id: 0c89a8133cc6c3bf794a8bb34036788194138061 $)
Armory05-b27 with Armory v0.6 ($Id: 9f9d587d3c8cea42d96543b826e5c03fb086e9ea $)
(both on MacOS)
I get an error: “GL Error 1286”
/Users/lubos/Downloads/Krom/Kore/Backends/Graphics4/OpenGL/Sources/Kore/OpenGL.cpp 275
Uncaught exception: Unable to get property 'length' of undefined or null reference
while(_g2 < _g11.length) {
^
TypeError: Unable to get property 'length' of undefined or null reference
at run (krom.js:727:9)
at armory_logicnode_LogicNode.prototype.runOutput (krom.js:658:6)
at update (krom.js:842:4)
at iron_App.update (krom.js:2394:3)
at Anonymous function (krom.js:22403:3)
at kha_Scheduler.executeTimeTasks (krom.js:22287:4)
at kha_Scheduler.executeFrame (krom.js:22239:3)
at kha_SystemImpl.renderCallback (krom.js:23084:2)
The setup is like this: (function in same nodetree as function call)
I think you need to fill in the Trait/Any with the node tree that the function is located in. If that doesn’t work try reinstalling, I had some weird issues with other stuff that was fixed by that.
Also, the more I look at the error I am not sure it has to do with the function. Will armory work with out the node tree attached to anything, basically disabling it? the location of the error seems to be with the video information concerning OpenGL.
I think @Monte_Drebenstedt is on the right track. You can try using the Self Trait node to get the trait of the current Node Tree and plug that into the Trait/Any input of the Call Function node. Then the Call Function node will call the F_scene function of the current node tree.
I am having trouble making anything work with the new updates. I will take a look at all of it again when I can. I still think the error is something to do with graphics and not the nodes.
animated meshes and bones sometimes “flash” briefly to the last frame(s) of the previous action and playing an animation sequence multiple times shows different results, which both look like a “frame caching” (if such a thing exists) issues to me.
While working on the animation recently, I noticed that it doesn’t “flash” at random. When blend is set to something larger than 0, it repeats the corresponding number of frames from the previous animation. The reason it confused me is that the previous animation stopped 10 seconds before this one starts.
So, not a bug, albeit annoying. Setting the blend value to 0 fixes it.
. Note, though, that work on Krom/Iron may also be required. I noticed that the Play Action and Play Action with Params nodes (logic pack) currently behave differently, see 
