A Feelings of Computing one. This is the 2nd time...
# share-your-work
t
A Feelings of Computing one. This is the 2nd time I have returned to the idea of using inverse kinematics to manipulate graphics. But I have moved to plain SVG now, thinking that that is somewhat of a universal representation. And the new thing is reflecting on a reactive dataflow graph to discover parameterization automatically, and also extracting the params -> svg from the computational graph automatically, so the author only has to write parameterized SVG, and choose location of drag anchors, and the system can figure out how the anchors related to the SVG parameterization via numerical differentiation magically, so the drag handling is all free. https://tomlarkworthy.github.io/lopebooks/notebooks/@tomlarkworthy_parameteric-svg.html You can get a lot of expressivity out of this for not much investment. You can choose how your parameters affect your SVG, it can be quite weird. Not sure how to handle something like a normal drawing program though with multiple objects. I think I there is still something missing though. I generally want to make drawing diagrams easier, this is very finite dimensioned though.
❤️ 6
💥 1
d
epic dude
k
Wow, this is something I have been dreaming of for too many years to count! I have been playing a bit with the examples, and trying to figure out how this works. Is there any way in Lopecode to search for references to specific cells? For example, I have been wondering how the "robotEditor" cell actually contributes to the animation, as I haven't seen it referenced so far.
t
probably easier to use the search on Observable https://observablehq.com/@tomlarkworthy/parameteric-svg
yeah the logic is hard to follow because of the meta-programming. robotEditor instanciates svgEditor, which clones a prototype dataflow subgragh (svgEditor_template), which is these cells pointing at an arbitrary ordinary svg node (i.e. each example has its own unique set of these cells so their state is kept separate) 'viewof svgTargetName', 'svgTargetName', 'viewof svgTargetModule', 'svgTargetModule', 'svgTemplateVariable', 'svgRenderDefinition', 'svgInputNames', 'svgParameterViews', 'svgParameterNames', 'svgParameterViewByName', 'svgParameterVarByName', 'svgParameterViewElByName', 'resolveSvgRenderArgs', 'renderProbe', 'viewof inverseConfig', 'inverseConfig', 'pseudoInverseStepMxN', 'viewof svgEditorStatus', 'svgEditorStatus', 'svgEditor_setStatus', 'getCurrentParams', 'svgEditor_commitParams', 'svgEditorController', 'anchor' The numerical methods are mainly "pseudoInverseStepMxN". The core clever part is 'svgEditor_estimateJacobianForAnchor' 'renderProbe' and 'svgEditor_commitParams'. renderProbe transforms the rendering to a pure
(params) => svg
so that we can linearize the system (svgEditor_estimateJacobianForAnchor) and then invert the dynamics, svgEditor_commitParams actually writes back to the true dataflow graph via twiddling the real UI (which is the chosen paramaterization of the SVG). I should add some more technical documentation really.
k
Thanks @Tom Larkworthy! This raises the interesting question for Lopecode if metaprogramming can be made more transparent. And/or if some visual representation of the cell graph could make complex graphs easier to understand.
👍 1
j
you may be interested in: https://omrelli.ug/g9/, https://aprt.us/
👀 2
t
Great recs @Joshua Horowitz those are amazing close to what I would like to do.
d
Also Ivan mentioned to me that Apparatus actualized productized into https://cuttle.xyz and its quite good but some of the cooler fancy bits are not there
t
Oh I have used cuttle because I like Lazer cuttering.
❤️ 1
j
Indeed, Cuttle does not have the numerical-optimization-driven drag-and-drop stuff which motivates me to list Apparatus as related. I think it’s probably best to see Cuttle as “a canvasy thing Toby did, inspired by his experience with Apparatus”, not as “a productization of Apparatus”.
🙄 1