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! :-)