View in #code on Slack
@dhruv: Recommend people check out that TAO link above. the project looks really well defined, plus MIT licensed code
@ambrosiussen: Im sure @Adnan_Chaumette would want to see
Looks a bit like like what you’re doing, no?
@Adnan_Chaumette: Thanks for the ping! That looks really neat, but I’m particularly impressed by how well their presentation video is made 
Reminds me a bit of PyFlow, actually. Just like most python node graphs, it doesn’t seem to be tailored towards artists like Substance Designer is to some extent, which is the main target of GraphN.
Tech stack seems really good though, no doubt.
@Frieder_Erdmann: just started watching their video series - not sure i like the annotation of the attributes (${name}) and the fact that it immediately resolves inside the code editor
and yeah - like Adnan just pointed out - very similar to PyFlow 
@ambrosiussen: Haven’t seen that before, thanks!
Those nodes look very :unreal: 
@Adnan_Chaumette: The PyFlow dev guy is amazing though, he’s been the main dev on GraphN (alongside a former fabric engine dev and this guy) and it’s crazy to see such tools take form this fast.
@dhruv: Yeah workflow node graphs are a dime a dozen. The devil’s in the details and the general system.
Major issues with pyflow and a lot of other graph systems is lack of workflow integration and heavy opinions.
@Adnan_Chaumette: Not open source, but this one seems to have put much more effort in the UI/UX compared to most node graphs: https://vimeo.com/303979958
Vimeo Video: Visual Programming Tool created with PySide
@dhruv: yeesh that’s ugly imho
@Adnan_Chaumette: too many colors? 
@Frieder_Erdmann: too many gradients and patterns
@dhruv: super garrish. and i hate very thick connections in graphs. they never scale well with larger graphs
@Frieder_Erdmann: but looks awesome in its own way
@Adnan_Chaumette: yeah thick lines are a nono
@instinct-vfx: Agreed
@Frieder_Erdmann: its the winamp styling of nodegraphs
@instinct-vfx: The simple things work better when at scale
Nuke took a huge nosedive when they made the graph prettier with v5
It threw a lot of our scripts back into the stoneage
(and that were WAY less complex times then now). They did make up a little though
@dhruv: One other big issue with most graph projects is that they assume central project/pipelines and don’t have good hooks for runtime node providers.
Also heavy dependencies between UI, graph structures and executors
@instinct-vfx: That’s an important point. Graph traversal and execution needs to be separate and actual processing too
@dhruv: In terms of UI, my favorite grid design so far is The Grid in Bitwig.
https://www.bitwig.com/the-grid/
It’s more UI heavy than most, but I think in the context of a DAW it exposes things really well. plus in use the grid UX is really good, with connections going out of the way when needed etc
@instinct-vfx: For a DAW i can see how it might appeal. Not a fan of controls in the graph myself
I really like the properties bin approach of nuke
@ambrosiussen: Houdini networks FTW
@Adnan_Chaumette: 
Houdini’s node graphs have been getting prettier and prettier over the last few years
@dhruv: Houdini is nice, but almost too minimalist imho
@Adnan_Chaumette: And that interactivity is something you just can’t get with python node graphs unless you build a LOT of foundational stuff to change the behavior of the language
@dhruv: for all its flaws Maya/Bifrost/UE4/Bolt are the best node graph designs imho
exposed ports, easy collapsibility, quick navigation
@ambrosiussen: Its minimalist by default. You can modify it any way you want
Its all exposed
@instinct-vfx: I think it depends a lot on how low-level your graph is. (If you are chaining operators on a higher level like nuke or lower level with parameter wiring in the graph etc
@ambrosiussen: https://youtu.be/Up97rAuXBwU
Take a look at this 9:57
Having a colorful node network would just distract, especially if working with multiple apps at once
@dhruv: no my point is more the lack of port labels and port connections between nodes
@ambrosiussen: (Imagine all Houdini shelves etc are gone… I just forgot to remove em)
@dhruv: Houdini/Katana take the modify the world approach of nodes.
Maya/Bifrost/UE4 take the approach of pass specific data blocks down.
Both are valid and I’m trivializing them a lot. i just am more a fan of data vs world.
the VOP graph is more my kind of graph
@bob.w: Agree on that one. I like having the defined input/output blocks. Makes it easier to reason about
@instinct-vfx: Nuke would be in the world camp i reckon?
I would say it is a matter of the type of work and size of scripts
Specific types of data only make sense if you have a minimum amount of different data (nuke does just image data) and only work to a certain amount of complexity for me
@dhruv: stepping into a massive katana graph is my worst nightmare. the only sane way to debug is graph bisection.
Houdini is better than Katana because it encourages breaking graphs down into types at least, but still hard to reason.
Nuke is world, but your world is more limited. no complex hierarchies etc
unless you’re working in 3D in nuke…but by then, you probably hate yourself already
@instinct-vfx: yes. I am not even considering 3D in nuke
We have a VERY high complexity in the graph with very low complexity in the data (a LOT of data, but it’s all just images)
@dhruv: everytime i hit tab and go into 3d in nuke, i wanna hurt myself.
@instinct-vfx: You already did when you went into 3d
@Shadowjonny: funny how I find myself avoiding graphs more now, and that how I first started learning about data in UE4. That NXT python graph tho looks nice
@instinct-vfx: I think there are valid use cases for different approaches. The modifier Stack in Max is really nice as a stack. For many other things Graphs are also a good idea. And for some things writing plain code does the trick for me
@Shadowjonny: Agree
@bob.w: Bah, there is clearly one true workflow that works for all things, we just haven’t built a system that responds accurately to my incoherent yelling of “Work damn you!”
@dhruv: IMHO you can actually model all graph types in a data driven graph since it’s the most atomic and then have progressive disclosure to expose that graph as any of the other representations
Hey, nxt dev here. We’ve definitely been wrangling with some of what @instinct-vfx refers to regarding when graphs make sense versus plain code. With nxt we’re doing our best to expose both, because every node ruins arbitrary python, we expose a node that’s designed to run another graph.