Large Nodegraphs

Hey all,

I’m looking to gather some feedback relating to some of the larger project files we’ve seen out in the wild, and trying to identify any gaps in the tool that lead to nodegraphs ballooning in scope.

If any of the below are relevant to any real-world project you’ve worked on, we’d love to hear about it:

  • What’s an example of a Nodegraph that got really huge for you?
  • What was your initial project, and what were you trying to achieve?
  • What’s a case where the current setup has lead to actual projects becoming unnecessarily complicated to wire up in the nodegraph?

If you could email with a description, relevant screenshots and any feedback you may have, that would be greatly appreciated.

– Ryan


I’ve had (and continue to have) many, many giant nodegraphs. Here are the main situations that create giant nodegraphs: (I can send dfx’s to support)

  1. A realtime 3d vj system with video input and effects. This required a giant nodegraph on one single layer because all of my looks needed to exist in the same 3d space and receive input from other effects/parameters in the same layer.
  2. Basically every project i’ve worked on with UV cam reprojection rigs and previs systems. Since the rig is complicated and needs to be updated frequently (as the pixmap, stage layout and overall creative needs change), its extremely impractical to keep everything in a separate layer. Whenever the rig needs updates, I need to go through and integrate the updates into every separate layer instead of just updating it once in one layer.
  3. Animated sequences with complicated, integrated transitions (Katy Perry Daisies XR project)

Precomps and groups should solve these problems, but they come up short. These large projects could’ve been split up into multiple layers and avoided if:

  • A. it was possible to send values / video textures to precomp’ed layers (preferably before the frame is rendered, but still extremely useful if its 1 frame late)
  • B. Nodes could be properly encapsulated/grouped such that they can be reused and updated globally through all the layers. Ideally we could import a Bin and have it appear in the resource browser, so we can Replace or Reload it in all layers at once.
  • C. Groups were fully fleshed out and bug-free
    1. Currently they do not preserve connections when being duplicated (very old bug). They are also instable in network editing sessions (specifically when grouping and ungrouping). These two bugs make them deal-breakers for most projects.
    2. Group properties need to be fleshed out (the G button on grouped node properties). We need to be able to connect modifiers to them and name them (with the ‘?’ pop up).
    3. Would be great to have proper inputs and outputs that could be configured, and have groups act as a video node, geometry node, procedural etc… it should be able to work to encapsulate any node in these systems and preserve functionality.

These are IMO, the biggest growing pains when building bigger systems in Notch.

There is one more thing though, that contributes to a ton of clutter in the nodegraph: Materials. Notch needs material instancing! For every object that needs a certain material, I need to drag out a connection to it and it gets ridiculous pretty fast. Then, when you need a slight adjustment to one material (like a tweak to roughness) you need to create a totally new material and add another set of draw calls into the mix. Having these materials all over the place creates a lot of clutter and is a huge pain to reconnect when assets change. It would be amazing if we just had a few master materials off to the side and each object could have some wireless reference to it.


For me, I always run into a limit on the RTX 3090 really hard to make things move to the music
and I could share proxy cam and use pre-comps and all that so I could bounce out layer and put them in as notch codec. but then I lose the data in the procedural network

I started to use the g buffer and render to texture to run out those maps that I used to affect objects with, to pull them into other layers
or maps for comping later down the line. But if something changes in the music or other places in the project I have to start over

So the best solution would be to be able to store state data across the whole system, kinda like the proxy cam just with all data(could be the extractor just for all across all layers and attributes) + also the ability to have a way to A-B things like what happens if I tweak this color and move this cam chance this noise " store " compare to, etc.

Hope this just makes a slight bit of sense :slight_smile:


This is all really great feedback - if you could copy it all with some relevant dfxs and send it to, that would be perfect.

– Ryan