make triangles object

[jersmi]

Looks like event order – try plugging Fire on Start into the random nodes.

How hard would it be for you to add things like UV coord support to an existing node in C, like the bss triangle strip/fan objects? I ask because you have a ton more experience on the code side than I do. I’d do it myself if it was approachable…

Definitely holes in Team Vuo’s support for basic 3D primitive stuff. All the 3D object manipulation stuff but no triangle strip, for example, seems like a no brainer.

Edit: kinda interesting to hook up an image texture to the triangle – looks like lighting/texture are mapped to screen size (UV mapping?) and the triangles/colors dance around as they are formed, masking the image. And the image jitters a little bit, not sure why, something outside the bounds of the viewer. Looks nice, though, a little movement there…  

[George_Toledo]

There are two current texture mapping possibilities with the Make Triangle Object patch. One is to map the texture sort of like a mask, flat to screen, across all of the mass of triangle strips. The second is to do a similar thing, but with mapped to the imagined uv coords of a sphere.

So…those are both very easy to implement and best approach once something gets to a patch like this without any UV coords existing already. Yet also not what is typical to do with a triangle strip for drawing type purpose. In that case, there are a couple/few useful UV map approaches, but the basic thing is to make distinct UV coords for each couple of triangles. Kind of mapping an image across each two triangles, as if it were a quad or sprite.

How easy to add? I have no idea. When I had the Qt and the VUO api setup correctly, I felt the wind beneath my wings on thinking in terms of the VUO node api and cranking them out. I know plenty of people do not use it, but let me say, the node api is really well done…and that aspect is lost on many users, but it is part of the quality of this system.

I moved to a different system and could not get Qt working on that one. So, if that remains the case…I’d say impossible! Now I’m on yet a different system, and figure I’ll inevitably give it a shot again in the near future. I have also discovered some Qt versions had some bugs that were near showstopper level for some things. Maybe I got lucky and had a bad version for awhile or something.

I remember quad strip being easier for me to think out UV for many years back, like - a few minutes - and it then being a little hairier to figure out UV for triangle strips but ultimately it worked fine. I can’t say I immediately remember the intricacies of how I implemented that UV part. There is a choice to try to center up texture per triangle, or treat two as though they more like a quad. But it is always 0-1 range and doesn’t vary with position in this context. I think it is getting the order generated correctly that is a little fiddly, iirc.

Nowdays, I don’t think quad strips are really “a thing”, you just make everything out of triangles…so it is the more annoying of the two cases (at least to my memory of it).

I will be looking at this myself (or, I plan to at the moment) as I bite off each bit that I can chew.

The fact something like this triangle structure patch already exists makes it somewhat easier, because it appears that it is just the UV coord handling bits that would have to be added…  

[jersmi]

I totally get all that. Thanks a ton for spelling it out.

[George_Toledo]

Umm - to the vuo team…

I hook up the Fire On Start to this as well, and now the rogue triangle doesn’t show at start.

But I now have two different types of fire objects hooked to these nodes.

If Fire Periodically fired when a composition was initialized, and the second fire was the selected interval, it would never be necessary to hook up these two different types of fire nodes. This would immediately reduce graph complexity.

I also tend to think that if it doesn’t fire initially, then there’s a solid chance that first interval probably doesn’t end up the true interval size, but we’re talking about a frame or two discrepancy potentially, so who really cares…yet…I’ll throw that out there anyway.

I mainly just think that one expects an initial fire out of it at the first frame it evaluates, then every period after.  

random triangles 2.vuo (5.4 KB)

[George_Toledo]

Fire On Display Refresh has some similar behavior. But there what I am finding is… I am editing a shader, and then kicking off the graph. But the values from the last time I ran the shader are what is rendering, not the current edit.

I can tell, because I edit the feedback to go a different direction, run the comp, but it hasn’t updated. Run again, it updates to what I had just written.

So the composition must kick off and run the old shader, because the Fire On Display Refresh doesn’t hit it on first cycle?

edit - looking again, there is a Share Value hooked to the shader, which in turn gets a Fire On Start. So, not sure why that shader doesn’t seem to update on first viewer start. I wonder if this will persist after restart.  

Mouse Trail Feedback VuoComposition.vuo (6.33 KB)

[George_Toledo]

…and after comp restart it isn’t happening. So, not able to reproduce that one.

Earlier when editing, at the moment the connections kind of grey out when you’re about to make a new connection, one of the line segments of a noodle connection did disappear for a moment even though it had popped back to “normal” noodle rendering mode. So maybe something subtle had gone awry in the editor. It wasn’t a heavy error like I had experience with noodle drawing on that older version recently, it just happened for a second, and started rendering correctly after.

[Bodysoulspirit]

@George_Toledo

Regarding Fire Periodically to also fire on launch I’m not sure, what if you’ll want to only fire it later, you’d have to ignore the first event then ? That would add nodes to the graph too ?

Regarding cables parts that sometimes disappear this has been reported already Loose node wires? and happens from time to time, it seems nobody was able to find the steps that will always produce it for a proper bug report.
But it’s just a glitch, the cables are still attached, usually drag-moving the node the cables are attached to solves it.

The Shadertoy node I also have encountered the fact that even if a Time cable is connected to it, changes in the code sometimes need a relaunch.

And regarding default node values or appearance it’s usually an event thing yes, sometimes I also don’t know why they happen and need some extra Hold Value nodes to fix them.
But from the Vuo Manual I remember it’s written somehow that the it is not 100% sure that the Fire on Start will fire before other events, so what I learned from Jaymie it’s that it’s best to use 1 stream for example like this (see screenshot)

 

Random Triangles 3.vuo (5.91 KB)

[useful_design (Alastair)]

I slowed this down and fired three events for every one event to keep the triangles on screen longer.

Two questions, 1) why aren’t 10 triangles on the screen at all times (I tried looking from behind in case they’re single faced triangles and that’s not it)?
2) what causes the “Max Headroom” type colour interactions when triangles interest. I FR the triangle structure object to do some stuff I want really clean colour with, now I’m scared it wont be up to it if there’s any intersections.

EDIT third question, what’s actually causing the jitters were occasionally a triangle makes a fleeting appearance for a couple of frames?

random triangles gt - with edits.vuo (6.55 KB)  

[Bodysoulspirit]

@useful_design not sure I understand all your questions but when slowing this down even more you’ll see that

• Since only 2D random coordinates are given, of course objects rendered on the same Z plane that intersect can lead to those artefacts, a little z-random values would probably remove most of them.

• When looking at the output port of enqueue, at the beginning you’ll see it’s first building up the list, and since triangles need 3 positions, a new triangles gets only added once the amount of positions are multiples of 3.
Then when the list is full, it adds only 1 more value, but since there are enough now, this remixes the triangles. I guess you only see 5 or 6 depending of where the points are in the list, some math going on with those multiples of 3.

• since the change colour nodes receive the same periodic event rate, but the triangles need 3 positions, when building up, the colours are changed for the triangles already existing too. It would need the color to change only when a new triangle is completely build.  

random triangles gt - with edits 1.1.vuo (5.05 KB)

[useful_design (Alastair)]

ah 2d vs 3D of course, doh. Thanks @Bodysoulspirit

And the jitters is that just the math of multiples of three? surely once the enqueue is full it stays at 30, looks that way yet sometimes only two triangles.

[George_Toledo]

That one artifact is just z-fighting, as Christian suggests: https://en.wikipedia.org/wiki/Z-fighting

"
Regarding Fire Periodically to also fire on launch I’m not sure, what if you’ll want to only fire it later, you’d have to ignore the first event then ? That would add nodes to the graph too ?"

In interval is the space between two events. If there is not an event at the start, the first interval is invalid.

[George_Toledo]

I managed to get textured ribbon drawing going with this patch, though there are a number of aspects that make me feel as though they need some revision. It may or may not be possible to smooth certain rough parts out, at least with this particular approach, I’m unsure.

I think an issue is that texture stretches between the points. Texture should possibly tile when points are very distant from one another, or I need a way to create an even sampling of points regardless of how fast the mouse travels between a given amount of frames.

There is fundamentally a certain kind of irregularity to the spacing of events with an event driven situation like mouse.

 

[jersmi]

Would you consider posting the comp? Totally appreciate this pursuit. By the way, could you use the Make Points Along Spline to compensate for points between mouse events, simply for convenience?  

[George_Toledo]

Here you go.

The approach is like…way way down the list of the ways I initially thought to approach this, but I kept running up against roadblocks for the other ways that would result in me having to add functionality to some of the structure sorting nodes or some of the rendering nodes, possibly more.

It may actually be possible to do what some of the approaches I thought out with the built in nodes, maybe with Calculate List, or some way to re-order indices just-so… but I just couldn’t figure out the way to.

So this feels a bit hacky, with a number of aspects I dislike. Though I thought it was kind of fun to create the triangle point by modulating with a triangle wave. A sine wave would work fine too in this case. There are a number of issues…one that I can’t really think of how to debug at the moment, is that every once in awhile I get a gap where I believe there should be a triangle, using this method. In fact, there is also something where I had to use the show back faces, but I’m not really sure why. I used it in two places, though maybe it is only needed in one. Maybe with some tweaks/de-bugging in some other places it might not be needed.

What I would like to do for something like this is generate all of the structure completely on the front end, including the uv, color/alpha values, and whatever else, and then feed it to a patch that just renders all of it out. Or I would like to just feed 2D or 3D point data and have the rendering patch create the create the strips with some various style selection.

edit: I did a slight update to the file a half hour after I made this post.  

mouse snake wave 2.vuo (11.5 KB)

[jersmi]

Love seeing this, thanks for sharing. I sure get the desire to generate all the 3D attributes up front, get that sorted to focus on the end result.  

[George_Toledo]

I just got rid of one of the triangle objects I was using by creating the structure a little differently in the front.

A couple edits may have resulted in a gap I was seeing every so often being eliminated.  

mouse snake wave 3.vuo (10.4 KB)

[George_Toledo]

With something like this, you often want the trailing path from the cursor to go from thin -a single point at the cursor position - to full line weight. If you are just putting past coordinates in a queue you can’t really get that. Each step on for X indices at the front needs to readjust when a new index comes in, so that there can be the desired taper. That is one of the reasons why I had written that there are many parts of this where different approaches might be better. Maybe there is some way to get that result that is not obvious to me at the moment…but there are so many other aspects of this that I’m not crazy about, that I think it might more sense to modify the way this triangle rendering patch processes input points with a different mode on the rendering side, just to make it a bit easier to format. Not sure.

That gradual line weight trick at the front end may be possible with built in nodes though, not saying it’s not :-)  

[Scratchpole (Joe)]

Hacky to say the least ;)
The order of vertices is wrong, especially for use with UV’s. I appreciate the imaginative effort though George.
See the diagram that BSS shared in the triangle strip/fan node thread for the required vertex order.

In my previously shared comps using the Parabox nodes you can see how we need to select and re-order the verts from a single vertex queue, I was always hoping some clever bod would work that out programatically.

[George_Toledo]

The point order required by the vuo patch and bss are different.

But are you saying I should draw the top triangle point first and not the bottom left?

To me, the issue with the UV is that you would create UV coords at the same time in order to take into account the distance between points being different. If you have access to generate them at that point, you just rotate and tile however you want.

parabox nodes cause an exception for me now, very unfortunately.  

[Scratchpole (Joe)]

Ahh yes my mistake apologies, I forgot this was using the Vuo triangle patch. (It confused me earlier that you had posted this other ribbon comp here, now it becomes clear). I now wonder if the staggering of the vertices is causing the issue here?
I think the basis of my statement is true, when stringing individual triangles together into a strip they need to use the correct point order to ever have the posibility of utilising UV’s which display an image accross all the faces correctly.
In the sub comp ‘Triangle Strip 2Q’ which is included here I create the triangle strip vertices in the correct order. It’s about starting and ending the following triangles with the same vertex IIRC.

I realise the Parabox nodes are defunct (They last worked in version 1.2.8), they were the only way that I managed to get the UV’s into the correct order for a triangle strip construction, it was in no way elegant and the nodes were causing the gui to slow down terribly while noodling. I just opened up this old comp so I could remind myself how painful it was: I manually created the UV coordinates for 10 sides of a cylinder! eugh!