MartinusMagneson's picture

Magneson (@MartinusMagneson)


MartinusMagneson's picture
@MartinusMagneson commented on @Citizen-Caine's Discussion, “Shadertoy probs

I was literally looking at this very same shader last week (wondering if we were on the same project for a moment :-o )The radialness is linked to the rg or the textureLod function I believe. I got some radial patterns playing around with some values at shadertoy at least.

MartinusMagneson's picture
@MartinusMagneson commented on @MartinusMagneson's Discussion, “Memory leak

Thank you! I'll check this :)

MartinusMagneson's picture

The reason for this is that while the build list outputs an index number (which you use to name the object), the process list outputs a layer. So where build item will give you a number 1 - > ∞, process item will give you the layer info as a value. That means that after converting to a summary, instead of getting a text "1" ... "∞", you'll get a text "object named "1", ...". Since you don't have any layers named "object named..." it won't register any true conditions for any present layer.

There are multiple ways to solve this. The simplest perhaps is to put all of the functionality into the build list.

A different approach would be to generate lists for position and size, generate one oval layer, and do the size/movement with a copy layer node (perhaps a bit more efficient?).

Note that the movement change feedbacks its position making it glitch if the mouse is in an in-between old/new position as the moved layer has new bounds which would again move it outside the mouse area, moving it back to its false position, resizing it because of mouse position, move it outside the area and so on. This won't happen if the new position covers the old area as well (only moving it by the offset the new size generates).

MartinusMagneson's picture

The short answer is that it fits in anywhere! Which is the beauty of it. If you think linearly, this very simplified diagram might help, but maybe not really.

Since you basically can adjust things before or after the fact, it depends a bit on workflow, and what you want to achieve. If you follow the diagram, an image is an end point of the comp. But it can also be the beginning if you want to shade with an image. Or both if you want a feedback-y kind of shader for your comp.

I played around with a simple composition the other day that perhaps can demonstrate the flexibility and intertwinedness(?) a bit when it comes to where you should be putting values and things (boxFlip.vuo). It is how I view it though, there might be better ways to do it. The comp creates a cube (object), copies it and applies a transform to the position (points). The same points are used to sample a color (well, color) from an image input (or in this case live video from the cam), and use the lightness value (real(point)) to create a list of rotational values for the transforms (point). It is then rendering the scene to an image which goes to the output.

The cube is created at the beginning, and then copied since it is an array of similar objects, and it wouldn't be as efficient to create 625 meshes when there already is an object to copy.

There is no "Hold" node before the "Get Item from List" node going from the point grid because it gets generated at the start and it isn't animated (no events after the first). If the grid was animated, a "Hold" node would be required, or at least an "Allow Changes" node for intermittent adjustments to prevent stuttering and glitches (due to the two data streams being out of sync).

To run the composition, you'll need to put the Magneson.Points.2dGrid.vuonode in your user modules folder (WIP warning, should work, can't guarantee it).

If you haven't already, check out my nodes (and all the others!) in the Node Gallery! They are a bit all over the place at the moment, but should provide some useful tools for a lot of different (perhaps niche) stuff. Especially when it comes to lists.

MartinusMagneson's picture

The source code in combination with the API is an invaluable tool to figure out Vuo for more advanced usage. I frequently look up the node filename (under the node title), look up the source, and then move on to the API to understand the code/usage. For the specifics of Vuo, documenting all of this to a greater degree than it already is would be a huge undertaking for someone I assume is a small portion of the user base.

I can greatly recommend "The Nature of Code" by Daniel Schiffman and his excellent YouTube channel at The Coding Train to understand the basics better in a general perspective. He does his things in Processing or Processing.js, but the concepts, examples and code are relatively easily transferrable to Vuo. Especially in combination with the source/API.

I've thought of doing a few simple tutorials on writing very simple nodes in C that could or could not be what you are after, but not sure if I can find time to do so in the foreseeable future. It is on my to-do list, right after making sense of, structuring and publishing all my node sets though (and the source to those that are published are already available in the node sets!).