Only found the configuration options for the forward and deferred render path in the armory properties or the option to overwrite the render path via Haxe (as described in the manual).
Cannot find the render path node type in the node editor (even with a camera seleced and a render path created in the “Armory Render Path” section).
I moved the render-path construction to Haxe for higher versatility and to be able to get maximum performance out of it, especially as the complexity of render path gets higher with more and more options.
I can still expose nodes for this in the future if there is interest, but perhaps creating a more detailed documentation on the new system would be more desirable. In essence the construction is still mostly straightforward and much more powerful. This is also how the celshade driver is runs.
Thanks @lubos for the feedback! If the pre-provided render paths are all Haxe now much of the appeal of having the Node based system is gone anyways (which would have been that people who don’t want to dive into the Haxe world can easily modify the existing render paths).
What would imho be important though would be an option to keep a separation between global Armory extensions (that potentially can become part of new Armory versions via pull request) and project local additions that are stored with the project.
Otherwise we run into the situation that a project only works with a highly customized Armory3D version. With fun merging with new Armory versions, having to put the entire Armory sources under project specific version control etc.
A rendering path could be both - either it is generic, usable for many projects. Then it could become part of Armory. Or it would be highly project specific, then it would be better to store it with the project.
The node approach (presumably?) had the advantage that local rendering paths were stored in the local Blender file anyways and thus fulfilled this wish. But this should also be possible for a Haxe based approach(?)
Perhaps there could be project local folders that are first queried for custom render paths, logic nodes etc. (which might even be added to the Blend file as internal resources) and then corresponding global folders (which optimally would also be grouped together, so we know what is supposed to be cloned/extended/overwritten and what is considered internal (so changing this would risk breaking future Armory versions).
Perhaps it might even make sense to have three tiers - part of core Armory, 3rd party (shared in the community but too specific to become part of core-Armory) and project local?
For a user to have a node based compositor style interface to the render pipeline would be AMAZING - perhaps it could export a data file that is then used in the actual implementation?
