-
VL.Fuse
A library for visually programming on the GPU, built to enable rapid workflows and modular approaches to accelerated graphics, logic and computation.
Check out Fuse[1/2]. It's an open source library for visually programming on the GPU. It is built for use in the visual programming environment vvvv[3].
VVVV itself is based on .Net and you can extend its functionality by either writing nodes in C# or import just about every existing .Net library just by referencing it or installing it as nuget. No need for wrappers[4]. For rendering vvvv uses the Stride [5] game engine which comes with a really neat shader system / language which is basically a superset of HLSL [6]. In vvvv those shaders are represented as nodes and you can open them in your favorite text editor directly from the vvvv evironment, edit the code, save and the changed result will instantly be loaded in vvvv[7].
[1]https://www.thefuselab.io
[2]https://github.com/TheFuseLab/VL.Fuse
[3]https://visualprogramming.net
[4]https://thegraybook.vvvv.org/reference/extending/overview.ht...
[5]https://www.stride3d.net
[6]https://doc.stride3d.net/latest/en/manual/graphics/effects-a...
[7]https://thegraybook.vvvv.org/reference/libraries/3d/shaders....
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
https://ossia.io does some of it, I've been working on a new release that also supports the whole QtQuick stack in the node graph items but you can already combine videos & shader effects
-
Although it's not quite the same, I do like what Enso[0] is bringing to the table, especially the 1:1 visual node/language interop. Whether this is generalisable to a fully decoupled interface remains to be seen, but there's definitely potential.
[0]: https://enso.org/
-
https://github.com/samuelmtimbo/unit recently, which at least uses some kind of hinted auto-layout (besides the more propriety fancy)
I really want to see more graphical coding for years, but node/graph-based and blockly seem to be the only approaches that got sone traction so far. So I like this thread and it seems at the right place.
I'd wish to see
-
What ImGui library did you use to create the node graph? https://github.com/Nelarius/imnodes?
-
Looks more like https://github.com/thedmd/imgui-node-editor/ to me - both are great libraries though.
-
vue-flow
A highly customizable Flowchart component for Vue 3. Features seamless zoom & pan 🔎, additional components like a Minimap 🗺 and utilities to interact with state and graph.
Several out there. Pick your poison https://vueflow.dev/ or https://reactflow.dev/
-
gcodepreview
OpenPythonSCAD library for moving a tool in lines and arcs so as to model how a part would be cut using G-Code or described as a DXF.
The problem here is that a fundamental question has not been answered, and as far as I can tell, has not been addressed by any of these visual environments:
What does an algorithm look like?
Herman Hesse alluded to this in his novel _The Glass Bead Game_, but despite decades of discussion and work, no one has made a convincing pysical representation of that system.
I love the concept, and have made some moderately complex attempts, e.g.,:
https://www.blockscad3d.com/community/projects/1430644
https://github.com/WillAdams/gcodepreview
it always devolves to screen size being out-paced by problem complexity --- one gets something of an inkling of this at:
https://scriptsofanotherdimension.tumblr.com/
Alternately, one can just break a project down into modules, but then the top-level view becomes the wall of text representation (albeit w/ nice lines or captured into pretty boxes) which one is ostensibly trying to escape.
I'd love to see someone succeed in this, and I've been using:
https://github.com/derkork/openscad-graph-editor
quite a bit, and put a bit of money towards:
http://nodezator.com/
-
The problem here is that a fundamental question has not been answered, and as far as I can tell, has not been addressed by any of these visual environments:
What does an algorithm look like?
Herman Hesse alluded to this in his novel _The Glass Bead Game_, but despite decades of discussion and work, no one has made a convincing pysical representation of that system.
I love the concept, and have made some moderately complex attempts, e.g.,:
https://www.blockscad3d.com/community/projects/1430644
https://github.com/WillAdams/gcodepreview
it always devolves to screen size being out-paced by problem complexity --- one gets something of an inkling of this at:
https://scriptsofanotherdimension.tumblr.com/
Alternately, one can just break a project down into modules, but then the top-level view becomes the wall of text representation (albeit w/ nice lines or captured into pretty boxes) which one is ostensibly trying to escape.
I'd love to see someone succeed in this, and I've been using:
https://github.com/derkork/openscad-graph-editor
quite a bit, and put a bit of money towards:
http://nodezator.com/
-
The problem here is that a fundamental question has not been answered, and as far as I can tell, has not been addressed by any of these visual environments:
What does an algorithm look like?
Herman Hesse alluded to this in his novel _The Glass Bead Game_, but despite decades of discussion and work, no one has made a convincing pysical representation of that system.
I love the concept, and have made some moderately complex attempts, e.g.,:
https://www.blockscad3d.com/community/projects/1430644
https://github.com/WillAdams/gcodepreview
it always devolves to screen size being out-paced by problem complexity --- one gets something of an inkling of this at:
https://scriptsofanotherdimension.tumblr.com/
Alternately, one can just break a project down into modules, but then the top-level view becomes the wall of text representation (albeit w/ nice lines or captured into pretty boxes) which one is ostensibly trying to escape.
I'd love to see someone succeed in this, and I've been using:
https://github.com/derkork/openscad-graph-editor
quite a bit, and put a bit of money towards:
http://nodezator.com/
-
Your requirements are a bit ambiguous, but Tooll checks all those boxes. I used the previous version (Tooll2) but ended up switching to Blender.
https://github.com/tooll3/t3
-
We've just released a new version of Nope Foundry yesterday: https://www.nope-foundry.org
You might want to have a look.
Video, Images, Rich Text and Animations are typically what we strive for. Check out maybe https://nopefoundry.github.io/nope.gl/usr/howto/renders.html and the other howtos.
-
WebGui
An example demo of IMGUI (Immediate Mode GUI) on the web. Using only WebGL, GLFW and ImGui. Suitable for being compiled to web assembly (WASM).
you could compile this with imgui to the web: https://github.com/jnmaloney/WebGui
but you'd have to write communication to your django app. I would do that in JS and then pass events to the WASM layer.
-
stride-website
This repository hosts the source code for the official Stride 3D engine website. Contributors can follow the build instructions provided to run the website locally.
Check out Fuse[1/2]. It's an open source library for visually programming on the GPU. It is built for use in the visual programming environment vvvv[3].
VVVV itself is based on .Net and you can extend its functionality by either writing nodes in C# or import just about every existing .Net library just by referencing it or installing it as nuget. No need for wrappers[4]. For rendering vvvv uses the Stride [5] game engine which comes with a really neat shader system / language which is basically a superset of HLSL [6]. In vvvv those shaders are represented as nodes and you can open them in your favorite text editor directly from the vvvv evironment, edit the code, save and the changed result will instantly be loaded in vvvv[7].
[1]https://www.thefuselab.io
[2]https://github.com/TheFuseLab/VL.Fuse
[3]https://visualprogramming.net
[4]https://thegraybook.vvvv.org/reference/extending/overview.ht...
[5]https://www.stride3d.net
[6]https://doc.stride3d.net/latest/en/manual/graphics/effects-a...
[7]https://thegraybook.vvvv.org/reference/libraries/3d/shaders....
-
-
> If people don't intrinsically understand you, maybe you need to go in to more detail so your explanation isn't so abstract.
People did; you didn't.
> Ergo, vis-a-vi have you ever actually tried making a graph that is rearranging itself while you're using it?
No one said anything about "while you're using it". Linters don't fuck up your text as you type it. It's a utility like anything else. And, YES, I have built a working version of one. It doesn't use machine learning/tensors at all, and it's a fucking nightmare to develop. I can see exactly where those things would help me. It's too abstract, to you, to understand? That's a shame! But other people seem to get it, so if you are having trouble, maybe try approaching your ignorance with openness and curiosity instead of cynicism and trivialization ('uncross some lines').
If you want to know how much time I've spent working on node edge graphs, you wouldn't believe me. But I can at least point you to the start of the web-component version I'm porting: https://github.com/catapart/Magnit.NodeGraph
