A clearer mechanism to indicate when a dragged component will fit into a cell of another node. Quite often when you drag the highlighted drop area is obscured by the node you are dragging.
pow(a,b) and abs(b), max(a,b), min(a,b) nodes would add a lot of functionality.
Then you could do something like.
(((1 / abs((((0 - (y-0.5)) * 6) - ((sin(((((x-0.5) * 6) + time) * ((cos(time) / 3) + 2))) / 4) + pow(((x-0.5) * 2), 3))))) / 9) + (0 - pow((1 - min(abs((x-0.5), abs((y-0.5))), pow(9, 9))))
as seen at https://c50.fingswotidun.com/show/?code=10v-6*u6*t%2Btc3%2F2...
(note - in my thing u and v are shorthand values for 0.5-x and 0.5-y respectively)
A perlin noise can add a lot too but not as trivial to add. I have a compact perlin generator in the first few lines of https://c50.fingswotidun.com/fastStackie.js which uses hashing to generate indexed random numbers, rather than a lookup table that sometimes gets used for Perlin. Feel free to use the code if you understand any of it.
A single suggestion:
Try using "the critique sandwich" when commenting on people's hard work - can help them appreciate the effort you've put in rather than feeling too defensive
Lerc was providing thoughtful suggestions for features to add. That’s not a criticism of what’s already in the project.
I agree the feedback was thoughtful (as acknowledged in my reply) and read no ill-will in it and meant none myself
At risk of flogging a dead horse, it can be nerve wrecking to share things (or raise your first real PR, whatever) so I try to respond with that in mind - especially since text-only comms can come off as harsher than intended.
It's because you didn't finish it with a positive.
I certainly didn't want to send the message 'Your thing sucks', I appreciate all these weird projects that people do.
And I meant what I said; epically thoughtful and cool feedback that I hope the creator sees
This is gold :chefkiss:
# chaiNNer
Fully node-based image processing.
https://github.com/chaiNNer-org/chaiNNer
# vkdt
Node-based raw and video editor. Sort of the evolution of darktable, by the original developer.
https://jo.dreggn.org/vkdt/readme.html
# darktable
The graph is strictly linear (single input, single output), but you can change the order of the processing and insert new nodes as you want.
Pretty sure there are some others, but those are the three I can remember right now.
[1]: https://cables.gl/
That said, we've been building our engine so far with a focus mostly on vector editing. There are some raster nodes but they're pretty limited right now (no GPU support yet, more engineering to do until that's production-ready). The raster compositing and image manipulation nodes + tools + infrastructure will be a big part of the focus for next year on the roadmap (https://graphite.rs/features/#roadmap).
[0]: https://observablehq.com/@dleeftink/svg-workbench#options
Node-based systems are used in music for synthesis and effects extensively and have been so since it was feasible to process digital audio in real time. In the 60s electronic music pioneers put together analog oscillators on a patchboard. Today musicians do the same in a screen with digital operators that are accurate and stable enough to build systems (like the Yamaha DX7) that couldn’t really be built from analog parts.
It is clear how to write a compiler for that kind of graph and probably less struggle than manually writing a “shader function”
int16 amplitude(int32 time)
The dominant paradigm in graphics is still shader programs, however.
https://github.com/derkork/openscad-graph-editor
which allows programmatic 3D modeling using nodes/wires. It exposes _all_ of OpenSCAD (last I checked) and is quite extensible (I use it to control a Python-enabled version of OpenSCAD https://pythonscad.org/ in an effort to make DXFs and G-code: https://github.com/WillAdams/gcodepreview )
Houdini also allows vex shaders out of nodes, which is basically a more polished version of this interface where you can manipulation pixels more directly and make your own nodes.
Outside of batch jobs, image editing tasks are generally one offs with image-specific actions and building a change pipeline is unnecessary work.
At the end of the day, both workflows are different tools, like hammer vs. mallet.
Blender geometry nodes take this approach for modeling. The rest of blender is destructive in that any operation permanently changes the state.
I'm still butthurt about when Blender introduced a node editor and confused me, I lost all my Blender expertise at that point. (The persistence of a vestigial old way of doing things only makes it worse, because of course I want to try to do everything without nodes, and then I don't have any guidance because all up-to-date docs and tutorials talk about nodes all the time. Nodes! Ruining everything!)
But none of these is doing it all using shaders.
I move blocks around. Some blocks I can attach to the bottom of "run this program" block and they clearly run. But I was unable to add any more blocks that did anything.
The screen is two dimensional so I was expecting to be able to put processing blocks anywhere. Sure I can but they do nothing.
What's missing (for me at least) is an explanation of the user interface.
> Some blocks I can attach to the bottom of "run this program" block and they clearly run.
The blocks with a square side are commands you can attach to each other to make a program. The round blocks go in the round slots on other blocks.
> The screen is two dimensional so I was expecting to be able to put processing blocks anywhere. Sure I can but they do nothing.
You can click on them to run them without them being connected to a "run this" block. Whatever has a yellow outline is running.
I suppose there's a reason node editors use a block and line interface mainly.
I'd actually prefer a tree-structured approach, where you could turn a subgraph into a single block, allowing you to structure appropriately.
Otherwise though it is most of the way there to being a really fun tablet app!