I totally get all that. Thanks a ton for spelling it out.
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)
1 Like
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)
…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.
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)
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)
1 Like
@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)
1 Like
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.
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.
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.
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?
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)
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.
1 Like
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)
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 :-)
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.
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.
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!
1 Like
I think maybe if I had it as two right/ortho triangles nestled together it might look better - so that the second point is basically lined up with the bottom left corner, but then again, the nature of how the initial path is created will always create some skew to the triangles. So, again, I think the UVs need to get generated according to the point layout.
There is an element here where it’s like…what is right, what is wrong really. Stretching UV wider by default if two points are far away; I’m suggesting it is “wrong” but it isn’t objectively. It just is. It just gives a different aesthetic.
You can clamp the x or y UV in situations like this, and it does a fun little thing that can look really nice on a ribbon. Is it right, wrong, or just a subjective choice?
I didn’t look enough at the UV parameters on the triangle object itself before digging in to setup anything really worthwhile there. Thinking now, maybe more is possible than I have suggested in the last couple posts,
I think as far as the stock patches go, something similar to this might be able to be accomplished with the quad object and be a little more straightforward to deal with texture wise.
I thought that the queueing and restructuring I had to do felt like an asinine choice to make when I probably should have taken the time to get the SDK up and running and changed the point sorting method at the patch level.
Or, I had two other approaches, where I would have had to modify list interleave one way, or…I forgot the other thing I was thinking at the moment! :-)