I wonder.. if we wanted to have all Nodes support a z property (if not present then 0)..
would that be a VeRy Real possibility to have available?
It might help with.. Alternatives ways of looking at the Flows.
For folks who wear glasses (or visors..)
As a- frame of reference..
if I were just to add a z property to some nodes (in a JSON export) and import them backto the NodeRED editor, it should work.. but would I be creating a hazard that might conflict with existing plans?
I've been having a look at some of the newer more accessible ways of rendering VR - for purposes quite separate to NodeRED. Well it also occurred to me that sometimes NodeRED flows can get a bit knotty, and a VR way of visualizing them might actually have some use in helping untangle on occasion.
If there were such a viewer, it would just show structure.. but when you drag something in the VR-style z dimension, it should not change tabs (you'd be seeing jkust one tab at a time).. so maybe it would be a vr_z property.
I suppose if really bent on such a thing, the vr_z could just be remembered outside the Flow definition by the VR viewer and re-merged by nodeid when re-importing a fresh copy.
I would be interested to know how you see this working in practice? Since nodes don't generally overlap, what would be the specific benefit? What would it look like?
It came up as a byproduct from something else.. so no not a hotlt soughtafter bit of functionality
Clearly nodes don't tend to overlap but it's more the wires that do.
Outside of NodeRED, when 2D dependency graphs get knotty (too knotty for doTTY or Lefttty .. GraphViz or such) I tend to reach to a 3D representation.
I do realise that in NodeRED that it's not to hard to call up decendents and ancestors of a node. Also the Link property helps.
I don't think there's a driving need for it but I think it would be useful in some cases to be able to view in this manner. Either to resolve tangles or to just have nodes with different types of function separated a bit visually.