and give us just a python for esoteric stuff and APEX script (which is syntactically is the same anyway)I started using compilable graphs more and more but developer experience around them could be better. I'm not using hdas sometimes but create my own library of compiled graphs that I can then invoke with some parameters as a part of high level tool.
The main pain point is creating parametrized programs, to provide a sensible pack of "arguments" and also create a parameters dependencies. Compilation strips anything related to expression so you either process the program as geo or rely on parameters overriding which is also not ideal (and afaik currently is not possible for cop nodes)
Both problems are easily solvable via expressions. Its just a very natural way to build parameters dependencies as a part of creating graphs
So ideally I'd love to see something like this:
- New expression language based on apex script and its vm
- Probably this expression should be available only for compilable nodes and subnetworks
- I guess it should be interpreted and evaluated on the fly as a part of cooking process
- However if I compile the network into apex graph this expression become part of resulting apex graph
==
I think one of the interesting example to illustrate where it can be useful is the new h21 cop updates. Finally compilation and invoking is exposed even with mixins of sop operators. So currently we're able to compile program consisting sop and cop verbs and invoke it. However parameter passing is still a hard part.
So consider this simple example attached of invoking program with different parameters on every point. This is something that I use in sop context and personally found it very powerful. It's basically like Invoke On Points in contrast with Copy To Points. We don't provide instances, we provide parameters for compilable network to have an infinite amount of variations.
Basically I've created a simple program that rasterize sdf shape.
Now I want to copy this shape but with different parameters on some points in image. For that I've scattered some points and randomize its attributes that will go into program as parameters. For simplicity I parametrized this shape on star sides count, outline width, iso offset and angle.
Then (with some arcane hacks) I've created a COP Block that could be considered as For Each Point where I invoke this program on every point and pass point attributes to it.
The result is this picture
I dont provide variations - I procedurally create a different shape on every point. I have as much variations as much points I have. Even though it's a very simple example you can already see how powerful it can be.
However this setup has couple of issues, performance related mainly, though it's still viable and for procedural texures there are many cases that instances are around thousand at least
- I suspect cop opencl verb still transpiles the snippet on every invoke. Even though it's "compiled" it consists only non expanded code so I just don't see how it'd work without transpiling. May be current implementation has some caching strategies over non expanded snippet but I doubt it
- I don't like the idea of modifying the program as geo, not sure but it probably also hurts how invoke works. Ideally I'd have just non modified apex graph with inputs. In theory I can create my own graph or modify the compilation result but it's even more complicated
- The whole setup of adjusting parameters (currently in vex) is very cumbersome. Be prepared to modify deeply nested dictionaries. It also forces you to inspect internal graph structure and find corresponding parameters which can be very time consuming in large graphs. Also currently cop compiler is flattening graph without keeping subnetworks
However if I had a way to express my parameters via apex script and compile them this could be way way easier. If we could compile not only block but also subnetworks (hdas) into graph with parameters dependencies the whole setup can be very simple and natural to express.