Question: Render many nodes?

[mmes]

Apologies in advance for the beginner question...

I would like to render 10k+ nodes and execution of NodeEditor::Begin()/NodeEditor::End() code blocks with that many nodes is prohibitively expensive. Is it possible to retain state via the NodeEditor::EditorContext between frames?

[thedmd]

Hello. Currently node editor does not support retaining nodes.

I'm thinking how such feature could be added. There are some challanges for the API to work with retained and immediate modes. I'm sure such mode would require user code to adopt, because API usage will change. How exactly I coudn't tell yet in details. I will look into it.

---

To improve performance on large blueprints in my editor I'm using level-of-detail approach and to reduce amount of details node have. Texts and pins are smoothly faded out, depending on zoom level. This drastilcally reduced amount of generated
geometry.

For your use case, when you push 10k nodes every frame level-of-detail gains can be easily outshadowed by the amount of work need to be done.

[mmes]

Thanks for the response. I expected to use LODs since I want a minimap, but as you said, even the min LOD is too expensive.
I was thinking about tile rendering by rendering to texture once, then updating only tiles per frame that are touched but that brings into question all kinds of boundary issues.

I am not familiar with the code. I'll poke around and see what I can come up with.

[thedmd]

Internally every object (node/pin/link) does have m_IsLive flag. In the ed::Begin(), they're all set to false simply by iterating over list of the objects.

Retaining would have to prevent that from happening. Only nodes/pin/links that are not retained should be have the flag reset.

That's the basic idea.

---

Content of the nodes is not retained, editor remember only node size and placement. This would still have to be done every frame. ed::BeginNode() could return 'true' when retained node is visible and should be redrawn, false if it is off-screen.

Iterating over all nodes, calling ed::BeginNode() and drawing only those returning true will still take some time. Rejection will be faster than drawing. Shear amount of data could still make this a performance bottleneck. On the other hand it does required a minor tweak on the user side to handle node retaining.

10k of nodes would probably require some quadtree like structure to quickly pick visible ones. With this scenario visible nodes should be reported in a loop similar to one for deleting a node.

---

In my use case node editor is used to represent blueprints, where functions can be defined. Every function does have own instance of editor which reduce complexity, maybe similar apprach will be viable for you too.

---

Out of curiosity, what kind of data your node represent?

[mmes]

The m_IsLive flags are cool, it looks like I am half way there. One good thing is that there are a small set of unique generic nodes with only differing names. There will be a lot of opportunities for caching. I'll try and share my dev branch if I make progress.

| probably require some quadtree like structure
We are thinking along the same lines.

| Out of curiosity, what kind of data your node represent?
I would love to go into details, but I am not sure what is/isn't under NDA. (They make us take classes on how not to leak IP in places like this. :)) Ultimately, each node will represent a very low-level hardware operation, so as you can imagine, any reasonable user-level input will explode into many tasks.

As an aside, this level of performance is what I am going for: https://github.com/alelievr/NodeGraphProcessor. Unfortunately Unity's corporate licensing structure is a showstopper.