The rise of Topological Data Analysis and In-Situ computation has led to more complex pipelines and the need for better tools to manipulate them.
We are currently investigating how we could improve the use experience concerning the Pipeline in ParaView and we think adding a Node editor could be a good way.
The node editor is an important feature of the InViWo platform (https://inviwo.org/) and is a must-have feature to manipulate complex pipelines.
Additionally, this feature has already been proposed here: Node Editor.
We remind here the two existing projects aimed at bringing a node editor to ParaView:
I’m fairly neutral on including a node-level editor. Having taught a visualization course to non-computer graphics specialists using both ParaView’s pipeline browser and the node-editor style in VisTrails, it was far easier for most students to use ParaView’s simpler pipeline browser, and I suspect that will be true of most casual and even advanced ParaView users.
Technically, I’m not too concerned of having two ways to manipulate the pipeline - we already have two ways to edit a pipeline via the Pipeline browser and Python scripting. I would make it a dock widget, not visible by default, so that we don’t make the initial GUI any busier.
My main concern is ongoing maintenance of such a feature. It looks like it will be fairly complex to implement, and hence we can expect bugs going forward. Is it reasonable to expect that there will be resources to address those bugs going into the future?
I agree the current pipeline is simple and so it is nice for a lot of users that manipulate a linear pipeline. I think however that more and more user are have fairly complex pipelines for their analysis and may find easier to change the way filters are connected using such node editor. I have also hear people saying that this kind of view is more convenient to understand a complex pipeline that you did not make yourself (shared using a state file) and to inspect the parameters of several filters simultaneously.
I agree the dock widget needs to be hidden by default as the already existing pipeline is certainly better for new users.
From what I know, there are corporations interested in this feature. I also think this may help the TDA community stay with ParaView as their main tool (and TDA is more and more use by large corporations).
The node editor design as such is excellent for typical workflows in ParaView with big autogenerated pipelines. But I’m not sure using QGraphicsView framework is “the” best way.
Sure, Qt graphics view can handle 40000 chips and what not but that’s not true for embedded QWidgets. With about 40-50 nodes, as soon as I zoom out, I notice ParaView starts to crawl. This defeats the purpose of having a node editor in the first place. (To analyze complex pipelines)
For alternatives, I sure do not want to advocate for bringing in QML/QtQuick since it would complicate things with pqWidgets. Neither is drawing every widget with VTK/OpenGL/QGraphicsItem a better way.
You are absolutely right, the reason the node editor uses the QGraphicsFramework was to support the existing widgets and just embed them as a node. A more modern solution would be Qt Quick (see Should you still be using QGraphicsView?), but I do not have enough experience with that framework so I opted to what just worked.
For massive pipelines the question becomes: “Do we need to show all widgets anyway?”. There is already an option that collapses all nodes (hides the widgets). This should be performant even for large graphs. Nodes that need to be interacted with can then be expanded. In the future I think it would also be neat to filter nodes by name, and summarize nodes in groups (like in Blender).
First of all, congratulations, good work on the node editor. Nice to see modern tools get accepted into ParaView
I was just about to link that page for the downsides of QtQuick. (See comments) I do not understand how one would show existing QWidgets within QtQuick.
“Do we need to show all widgets anyway?”
I find it is often necessary to get a bigger picture as the pipeline browser cannot give this perspective (limited to scroll in vertical direction)
I think it would also be neat to filter nodes by name, and summarize nodes in groups (like in Blender).
Interesting, but note that you neither have the comfortability nor the performance observed in node editors from blender or unreal engine blueprint editor, since those have custom UI frameworks instead of Qt. This is very difficult to overcome when attempting to extend ParaView. I’ve been trying to get a camera gizmo (like blender) working in ParaView for a long long long time.
How about implementing custom line edit, spin box, combo box, check box, etc as derived instances of QGraphicsItem? Here you control painting, but it’s a big effort to proxy and link every such widget from pqWidget.
there’s issues already logged in the repo at https://gitlab.kitware.com/paraview/paraview/-/issues/20726 so everyone is aware of what the current limitations are. Feel free to add/resolve/comment stuff on this issue if you’re interested in improving the current node editor
Not necessarily but it would not be too difficult to create such application using trame+simput and something like VueFlow. So far we are working on an updated version of Visualizer which already have most support for any proxy editing UI using the simput infrastructure. That repo is still work-in-progress but you can see some automatically generated panels as example that could be embedded into those flow box.
I mean any Web based library doing flow chart will be fine but if it is based on Vue.js it will integrate nicely with trame which is the nice layer on top of ParaViewWeb for creating full features web apps on top of VTK or ParaView.
