behave-graph VS threeify

How does this compare to the open source behave-graph library?

https://github.com/bhouston/behave-graph

Is Luna based on behave-graph?

I enjoyed reading this. I knew of quartz composer but I never did anything with it.

I love visual tools and I think they are underutilized today. I cut my teeth in ~2005 with Houdini[0] and Fusion[1] which are both heavily graph / node based (and procedural).

Most recently I have been rekindling my love for visual programming and flow based programming and plan to spend some time in January and February doing more research around flow based programming for infrastructure management.

I plan to get this sort of info published on my website which I have neglected for half a decade or more but if you are interested in visual programming you might enjoy checking these out:

Unit from Samuel Timbó:

https://github.com/samuelmtimbo/unit

https://ioun.it/

A video of me exploring what I figured out about it (while also learning to stream) https://www.youtube.com/watch?v=vwknTfGVDq8

Behave-Graph from Ben Houston:

https://github.com/bhouston/behave-graph

And the products I learned so long ago

[0] Houdini https://www.sidefx.com/products/houdini/

[1] Fusion https://www.blackmagicdesign.com/products/fusion

Fun fact, a lot of it is open source, just not where you would expect it. During the creation of Clara.io I created over 200 PRs to Three.js:

https://github.com/mrdoob/three.js/pulls?q=is%3Apr+author%3A...

The problem with open sourcing it wholesale at this point is a challenge because parts of the tech stack became parts of Threekit.com. Threekit.com is VC funded and an ongoing business operation.

I do what I can with open source still, see:

https://github.com/bhouston/behave-graph

https://github.com/threeify/threeify

Don't forget behave-graph/behave-flow, the Unreal Engine Blueprints / Unity Visual Script like interaction/behavior system:

https://github.com/bhouston/behave-graph

As someone who has written math libraries over and over again for the last 25 years (no joke - wrote this in 1997: https://github.com/bhouston/BezierCurveDemo1997/blob/master/... and just recently wrote the Threeify math library: https://github.com/bhouston/threeify/tree/master/packages/ma...), I find that operator overloading works only for the simple cases but that for performance and clarify, function names work best.

Function names let you clarify that it is an outside product or inside product (e.g. there are often different types of adds, multiplies, divides), and I can not stand when someone maps cross product onto ^ or dot product onto something else. Also operator overloading often doesn't make clear memory management, rather it replies on making new objects constantly, where as with function names, you can pass in a parameter that will take the result. Lastly, function names allow you to pass in how to handle various conditions, like non-invertible, NANs, etc.

I find word based function more verbose but significant less error prone and also they are more performant. Operator overloading is only good for very simple code and even then people always push it too far so that I can not understand it.

Fun fact, a lot of it is open source, just not where you would expect it. During the creation of Clara.io I created over 200 PRs to Three.js:

https://github.com/mrdoob/three.js/pulls?q=is%3Apr+author%3A...

The problem with open sourcing it wholesale at this point is a challenge because parts of the tech stack became parts of Threekit.com. Threekit.com is VC funded and an ongoing business operation.

I do what I can with open source still, see:

https://github.com/bhouston/behave-graph

https://github.com/threeify/threeify