Handling the output of the neighborPOP without GLSL?

[flowb]

I’ve been thinking about one of the stated objectives on the POPs notion site (that POPs should eliminate a lot of the need for coding). I wanted to explore the process of adapting a workflow that leans heavily on GLSL to non-GLSL POPs.

The attached file is a simple 2D physics solver where attraction vectors are computed from a mono input texture. I was able to get most of it to work without GLSL, though I’m not sure if there might have been other ways to do some of this. The file has the non-GLSL versions with the original GLSL implementations beside them.

Some thoughts:

Lookup Texture POP:
In order to extrapolate direction vectors from my input texture I’m using a multi-sampling approach and deriving the variance based on distribution. Adapting this to use Lookup Texture POPs requires putting one down for each sample point (unless there’s a smarter way). I really like how the TOP to CHOP can be supplied with an input channel that the OP uses for sampling multiple positions. I wonder if there may be a way of adding a similar feature to the Lookup Texture POP.

Math Combine POP:
This OP is really the rockstar of my whole process here. A lot of things done in code were able to be done here, though it required taking some operations and splitting them into smaller chunks with intermediary stages. This kind of warped my own sense of approachability a bit. I know that some people feel overwhelmed when confronted with code and the prevailing implicit bias is that by keeping people out of the code and in the network editor, things are made friendlier and more approachable. However, math stuff done in GLSL can be laid out in fairly intuitive ways and annotated with comments. These operations pulled out of the GLSL POPs DAT and expanded into a dozen or so operation in the Math Combine POP suddenly become far more inscrutable (to me at least).

Collision and Neighbor POP:
I really like the neighbor POP, but I have a hard time understanding how someone could operate on information like the neighbor’s point Index without GLSL. The collision calculation I’m doing in my project is a variant of the one used in the neighboring spheres example in the Alpha package. The basic structure of the collideSpheres() function included in the example seems like something that maybe could be rolled into a ‘Simple Collision POP’ which has inputs for neighbor attributes and radius.

texAttractFlock.toe (12.3 KB)

[vincentDev]

Hi Florian,

Thanks for sharing, cool example!

@flowb

I have a hard time understanding how someone could operate on information like the neighbor’s point Index without GLSL.

Indeed, right now some of its functionnality could be considered as a helper POP for other GLSL POPs. When outputting averages it can be quite useful as is.
We did have a few requests for MathMix/MathCombine to operate on arrays, so we’ll eventually get to it - we might do a specific POP to make it easier to deal with empty array elements.

MathMix topics (RFE, bug & idea)

Hi there, RFE: Would it be possible to add a ‘reflect(A,B)’ and ‘refract(A,B,C)’ function to the mathmix operations? Those are predefined GLSL functions and can help alot for particle collisions (mainly reflect). I can imagine some interesting effects with refract() as well. Other thing which I’m not sure is technical possible but thought about mentioning. When working with arrays (like position outputs of the neighborPOP), you often want to do some math operations with each element in this ar…

Math Combine Against Neighbor Array

is there any way to do math against the neighbor array in math combine? Essentially iterate/loop

otherwise as you say for flocking, collision, etc, we’ll probably create higher level POPs in the future.

@flowb

These operations pulled out of the GLSL POPs DAT and expanded into a dozen or so operation in the Math Combine POP suddenly become far more inscrutable (to me at least).

We had this feedback from other people as well, I personnally think mathMix / mathCombine is great for things not too complicated, but becomes another form of coding for more complex operations, and in that case it might be worthwhile to invest in a bit of GLSL knowledge. POPs specific documentation is a bit sparse but we’re planing on making it easier to approach.

Otherwise as stated above we’ll try to cover more high level functionnality with dedicated POPs.

[flowb]

Hi @vincentDev!

On the last point about the inscrutability of long chains of operations in the Math Combine POP, I thought about it some more and realize that it would have been more intuitive to break the stages of the shader computation out into multiple math POPs interacting with one another.

As you said, this would make it simpler, and more perceptually intuitive.