Triangle nodes, structures, how to?

Discussions
1

I opened the example file DisplayRowOfSpheres.vuo for a row of spheres and made a row of triangles but the methodology is not one I think that I can adapt for what I want to do.

Greens-Triangles.png

I want to do colour transformations like from the left image to the right image above. I want to change them one at a time and eventually to write a folding transformation animation so the triangles can be rotated about an axis on one of their edges.

So i figured not knowing anything about Vuo, and this is how i’d attempt to do it in QC, that I’d generate a list of triangle co-ordinates and vertex colors much like you’d feed into the Kineme OpenGL Triangle Structure patch. That way I could use maths to determine triangle size, set the co-ordinates accordingly so they are all aligned to the 60º grid and touching but not overlapping. Then i’d either feed it to the Triangle Structure patch in QC or an iterator with a GLTriangle patch and breakout all the data inside the iterator and feed to the patch, including any vertex colour transitions or 3D transformations for animating a move.

The math is a little bit more involved using Points on Curve node to do the translations — and I can’t do an loop inside a loop to make all the translations I need for a grid. Or can i? I thought I’d need to write a node to generate the points or do it elsewhere and import as string literals and feed into something to split it into datatypes that work in Vuo to do the translations and scales on my prototype Triangle object. Not sure what nodes do that splitting for a txt or XML into co-ordinates.

The grid the setup in DisplayRowOfSpheres.vuo it’s quite hard to even set up the triangle width if the viewer window is going to change dimensions and even if it isn’t it’s all either trail and extra maths, and then if I want to change the triangle size and therefore number of triangles it complicates the maths further, there’s too much contingency math. It becomes even harder when I want to flip individual triangles I think. Maybe i just need to adapt my thinking to Vuo way.

Any ideas appreciated or guidance.

2

thinking some more, for some kinds of animation, i really need to have an id for each triangle and describe the moves, i.e. △23 ⟶ △27 which would correspond to data in a matrix Triangles[23] and Triangles[23].

so in pseudocode where:

 origin(x,y,z) = Triangles[42].pos;

fold direction vector would be:

  fold_vector =  Triangles[23].pos - Triangles[27].pos;

My central problem is being able to work with the triangle description data in one form for greatest ease of coding the matrix generating nodes and the animation nodes and translating the data easily into a form that I can use in Vuo to efficiently draw the triangles.

I don’t want to unfold the loops into single instances of Triangle nodes for example — I’m looking beyond this exercise and want generalised node tools out of it.

3

I’ve since discovered @George_Toledo’s question a couple of weeks ago about grid transformations etc. Please answer my queries here or on either of those threads to avoid repetition:

[How to make copies of an object in a grid formation along the X,Y,Z axes, possibly with noise/variation?][2] 2016.01.23

[rotating “arrange 3D objects in grid” and related questions][1] 2014.08.13
[1]:https://community.vuo.org/t/-/4696
[2]:https://community.vuo.org/t/-/5301#node-1135

4

Yeah, applying QC techniques isn’t really working when it comes to Vuo. It’s just that much of a difference that doing so will cause more confusion than forgetting about most of it.

If you have a slightly more extensive knowledge of geometry than me (which basically amounts to what a 13 year old should have), see if you can make use of the attached composition. It’s the basic concept of a grid that I also posted in @George_Toledo’s question, but with my attempt at being smart with (tri)angles and such (as you’ll probably see isn’t quite working out). So if you can calculate the height/width of the triangle(s) and the offset positions, you should be able to get rid of all the hardcoded values that are present now, and make it work regardless of size.

For coloring here I just used a rainbow patch because I’m lazy and it’s easy to troubleshoot, but for custom colors you just use a color list and the “get item from list” node with the “Build item” attached to the “which” port.

TriangleRubble.vuo (15 KB)

5

thanks Magneson, I’m still figuring out how you change colours… it’s all kind of round about how we need to do these things to my way of thinking, but maybe I’ll start thinking in Vuo soon enough.

6

(Just realized this would become a very, very long post although it’s barely scratching the surface)

Vuo is very flexible in color handling, so you can more or less figure out which workflow suits you the best. Here are some compositions showing a few, but there are even more ways to do it. I use the HSL node to do a lot of it, because when you get over to palette creation and the sorts, it’s a lot easier to deal with degrees when thinking color theory. The conversion is fairly simple to calculate based on the HSL model and a few math nodes.

The base composition is the grid model, since it’s conceptually easy, and it involves the Build List node which give you an identifier for the item. Item 1 is in the bottom left corner, max item is in the top right. As all color data is in the 0-1 range initially, you divide 1 by the max number of items in the list, and then multiplies the result by the item number to get its “address”.

What might be a bit confusing when building separate color lists (or rather real lists that edit color) is that the lists are separated. This doesn’t matter as long as the lists have the same number of items. The important bit though, is to use the hold node triggered by the Build Item port everywhere you have a “crossing”, where you edit one list with the other list and events get shuffled around. There might be some unwanted or hard to figure out stuff happening in these comps, as there are some event flow issues that I don’t know what’s causing. (@JStrecker, would you mind having a look, especially at the events from the Get Window Dimensions node? It seems like even with a hold node in place it struggles with separating)

So here we go. All you need to look at for the color bit is the lime-colored nodes.

1. Magneson_RainbowGrid

Color is calculated within the Build List that generates the grid. It uses a Scale node set from 0 to max item (x axis multiplied with y axis), and with a scaled range of 0-1. This is then fed to the Hue input port of the Make HSL Color node to generate the color. This is then filtered by a Hold node that is triggered by the Build Item port of the grid Build List node (Hold node is in place because the multiplication continuously fires events).

2.Magneson_EnqueuedColor

A Wave node generates values between 0-1. This is fed into an Enqueue node to hold the previous values. The Max Item Count input of the Enqueue node is the total amount of items. A Get Item From List node is then used to get the corresponding value for the item in the grid.

3.Magneson_BuildListColor

To get more finite control over each item in the list, an additional Build List node is used. This generates a new list containing color information (or real numbers to generate colors as is the case with these) that the grid Build List node can use. The fired item number from the list stores the value from the Share Value node to the corresponding item in the list. All are equal in this case, but it is the base concept.

4.Magneson_BuildListEnqueueColor

Changing things up a bit, here the output of the color Build List is connected to a strain of Change Item in List nodes. The data from the Wave node selects which item is to be changed, and the enqueue list delays the selection for the first and second Change Item in List nodes (the last item in the enqueue node is the most recent).

5. Magneson_BuildListCountColor

To get more control over the delay and positions, the Wave node is swapped out for the Count within Range node triggered by a Fire Periodically node. Where the wave method continuously change the position in such small increments that they might overlap if not given enough timed delay, this method changes a full step each time it’s triggered. Because of this, the list only needs to be as long as the max item count, and spacing is more intuitive (subtracting from max item gives the step).

6.Magneson_BuildListConditionalColor

For ultimate (and rather complex) control of the coloring, you can use boolean conditions to decide color. Using the Are equal node (the absolute, not sloppy version) you can filter the item number, and change it with the Select Input node (Boolean). Keep in mind that these can be chained for even more complexity, and the item number can of course be modulated to animate it.

7.Magneson_BuildListMultCondCol

The Select Input node also works with the Calculate node to do more comparisons at the same time. Here I used “(Item == A) || (Item == B) || (Item == C) || (Item == D)” to color four items of a definable position. The ABCD inputs sets which item to check for matching, and the Item input takes the current item from the build list. As the inputs are variable, you can animate the grid by changing which item to check for (like the Wave node on input A).

8.Magneson_BuildListCameraColor

Differing quite a bit again, this uses the Build List node to generate the colors (not numbers). It takes the 2d point generated from the grid calculation (but with its own hold nodes) along with the element width to sample the colors from an image (or video in this case) at the position of the item in the grid.

The Get Window Dimensions node isn’t playing nice, so there are hardcoded values for the grid. I still hope this can be of some help in understanding some (mine at least) ways of coloring grids and other multiples of stuff in Vuo. I only used the Make HSL Color here without lightness or saturation, and you also have the RGB and Hex coloring nodes which are their own containers of fun (and probably frustration).

1.Magneson_RainbowGrid.vuo (11.6 KB)

2.Magneson_EnqueuedColor.vuo (11.4 KB)

3.Magneson_BuildListColor.vuo (11.5 KB)

4.Magneson_BuildListEnqueueColor.vuo (15.1 KB)

5.Magneson_BuildListCountColor.vuo (16.9 KB)

6.Magneson_BuildListConditionalColor.vuo (12.7 KB)

7.Magneson_BuildListMultCondCol.vuo (15.8 KB)

8.Magneson_BuildListCameraColor.vuo (14.3 KB)

3 Likes
7

there are some event flow issues that I don’t know what’s causing. (@jstrecker, would you mind having a look, especially at the events from the Get Window Dimensions node? It seems like even with a hold node in place it struggles with separating)

Here’s a revised version of the first composition. It needed a Hold Value node for Make Color Layer : Center. (I figured this out by disconnecting the cable Make Color Layer -> Build List and then running the composition with Show Events turned on to see which nodes in the Build List feedback loop were getting lit up.)

1.Magneson_RainbowGrid_2016-02-11.vuo (10.7 KB)

2 Likes
8

Ah, I forgot that one, it’s corrected in the later comps. The problem was with the build list getting fed the amount of items from the Multiply node that sums the total number of points (should have mentioned that). Even when using a Hold node it went black when starting, and the only means to get the grid back was to use a hardcoded value and restart the comp. Now it seems to work though, so maybe it was just a hiccup of my mac that day.

9

I have a feeling that if I was going to do this, it might be quickest to write a new node that gives the exact info to provide to the parabox Make Mesh With Values node. Or create a node that draws triangle strips. I bet you might be able to take a look at the grid node and just do the needed adjustments yourself Alastair as long as you get Qt up and running.

I would probably attempt to construct the UV’s in a way that made it reasonable to create the colors in a shader.

That whole gl_Color per vertex possibility with fixed function pipeline OpenGL was a pretty handy thing…

1 Like
10

thx @George_Toledo I was wondering about making a 3D mesh using vertex points but I don’t know how to do it and feed it vetted colour values in Vuo. In fact the only 3D Mesh node I’ve looked into is the 3D Mesh with Heightfield Image node that’s in one of the example compositions, and that’s not suitable at all for this.

I guess I keep coming to this issue with Vuo where I tend to think of a a set of steps whereby you create a datatype (say an array of point locations to declare triangle vertexes with, plus empty element(s) for say colour value) and then run a node to generate all the points, then feed that to another node that adds all the colours (perhaps randomised) and then feed that to a node that can take one set of points for one triangle and transform it with reflection math so as to animate it’s 3D position (this might rule out using a mesh or would require creation of two meshes at least) then finally feed that data list into the Node that makes the triangles one by one and sends them of to a Render node.

But in Vuo it seems like it’s less procedural and more declarative in that it looks like you kind of have set up all the list generation logic up to execute together in one big hit, less of passing things from one stage to another building up the picture — I could be totally wrong about that but that’s what I’m seeing in the example comps so far.

Obviously I tend to think the former is a methodology more suited to my conceptualisation than the later, but I may have to adapt/improve my intellectualisation of these abstractions.

11

I’ve got as far as working out i need to generate lists of triangles (with different colours) then arrange them using two Arrange 3D Objects in Grid nodes (using just two dimensions). I managed to alter Jaymie’s composition on another thread to make random coloured cubes and spheres in a 5x5x5 grid. But I can’t seem to build the list here. I removed all extraneous nodes from a minimum evaluation chain but no list is generated. Not sure what I am doing wrong.

randomGreenTriangle-recursive-checking-v0.2.vuo (9.37 KB)

12

It’s because you fire at the wrong port. With the “Build List” node, and similar, you fire the trigger events directly into the “Fire” port of the node to generate the lists.

13

I’m using exactly the same methodology as Jaymie’s example comp called GridOfCubes-list.vuo on this thread. I’ve even tried firing into every single node event port in the iteration chain. Spent hours trying to work out why it was failing.

I’m finding a bug in either** Build List** or Make a 3D Triangle patch that is causing the most simple two node version of this iteration to fail.

Watch this screen capture and see what i mean:

14

Oh, that’s weird indeed. I can’t reproduce it here, maybe that’s the reason I got the last one working? Did you file a bug report?

15

Looks like the problem is Build List and Process List may stop firing during live coding.

1 Like
16

The new Make Triangles Object seemed to help with this, then i realised it’s only 2D, so I can’t flip about an arbitrary axis. I guess I could rotate an equatorial triangle triangle aligned to the X-ais about the X-Axis by 180º. And then after that calculate a translation and 2D rotation to put it where I need it. If I can order the translations and not have the order overridden in the scene render node.

But still no vertex colours. I gather a Material Shader node is the only way to apply (other than colour lighting) to colour to the triangles directly, and presumably it applies the same material to every triangle is that right, @jstrecker?  

17

On a side note, there’s a “64” input to the list builder, which limits the comp to 8x8 (or 9x7 etc). Took me a while to figure out to wire the Build List node’s “Start Building” input to the Multiply node.

1.Magneson_RainbowGrid_2020-03-04.vuo (11.3 KB)

18

Here is one way one doing it if I understand correctly what you want. No flip & rotation though, but a grid changing colours.

You can change the triangle size, choose an amount of columns (5,7,9 etc), the rows are calculated accordingly

PS the new triangle nodes have 2D list points by default, but with a transform node you can still rotate them, or even change the input list to 3D on the node itself. Don’t forget to show the back of the object.

Capture d’écran 2020-03-05 à 00.25.24.png
Capture d’écran 2020-03-05 à 00.25.24.png1014×763 20.8 KB
 

Change Triangle Color In Grid.vuo (23.2 KB)

2 Likes
19

A lazy method, instead of changing the whole position & rotations maths to get the final shape closer to yours compared to my latest upload, is to cut the first and last triangles from the list.

I’m still thinking that applying a rotation on one triangle at the time is quite tricky, but I’d be happy to be corrected.

Capture d’écran 2020-04-02 à 02.01.26.png
Capture d’écran 2020-04-02 à 02.01.26.png1920×1080 90.1 KB
 

Lazy Remove.vuo (24.1 KB)