Continuing from the VL.FUSE chat:
I was fighting with broken renders from a spritesheet that I applied to sprites via the FlipBookUV node.
The issues I had were:
a.) if I had the same values for X and Y for both the spritesheet generation (in my case 6 x 40 cells) and in the FlipBookUV, I got four words per cell instead of 1.
b.) if I doubled the subdivision for the sprites, I got most words correctly, but some were half a sprite offset.
c.) only the first couple of rows were used, not the whole spritesheet.
So currently I am examining his scene and trying to find out, what the difference is.
So far I found, that he is using a “Sample Texture” instead of a “Sample” node, but that doesn’t seem to make a difference.
He is plugging a TexCoord into the FlipBookUV which I don’t, but when I looked into the code, the node has that internally as a default, so that shouldn’t be it either.
Instead of “Sprite”, he is using a “Sprite2” node that I do not have, so I’ll investigate in that direction.
Maybe this provides useful for others and will unclutter the chat.
It doesn’t work here when I build it myself (which I did initially) in build 5.3 0377 as I wrote above and I get broken results. I have to work on something else right now but will return to this when I have time.
Not sure if it’s a bug in this build or what I could have done wrong.
Will upload a sample when I return to it and can’t solve it.
The example works fine on version 5.3-0403.
If your example doesn’t work on the latest preview versions, let me know.
FUSE offers very few off-the-shelf solutions, unlike other node systems. FUSE is very atomic, providing low-level access to the shader assembly. The innovation of FUSE is that it allows you to build shaders and reuse those builds in a very clever way. Don’t expect FUSE to solve complex problems for you, you’ll probably need to learn more about shader programming, and it can help a lot.
If you look at the logic of what’s going on, you can probably make changes without any problems. Your question above will probably be resolved as you deepen your understanding of VVVV programming.
Ok, I’m currently working on an example scene that shows that the FlipBookUV node is actually broken. It fails if your spritesheet is non-square. Then it only uses the upper part of the spritesheet, not all of it.
This also happens in above example from gegenlicht, but since the words in the spritesheet are so generic, we don’t realise it. I’ll try to upload it as soon as I get it working.
Ok, if you want to see the issue, load below patch and load the gradient texture below into the image reader path I built in (don’t know yet how to create a gradient in VL). Then you can see, that only the upper part is used, from white to blue, but never the colors further down.
And this issue is getting more pronounced the more slices you have in Y as compared to X. Change the values in the “FlipBookResolution” to see it.
In my original case, I had 6x40 and only got the uppermost two or three rows of words.
Only when it’s basically the same number of slices in each direction it works correctly.
(updated the file for clarity).
Ok, I had to actually rebuild the logic in Houdini to better visualise what happens and the bug is rather simple: Instead of dividing the modulo of the multiplied X and Y resolution through Y, it needs to be divided by X to get the rows…
This is the original file:
Yeah, that one I have understood, but there is also an offset happening inside the tiles that is wrong.
If you try with the words in the wordlist but make the words larger, so they fit their cell almost completely, you can see that the UVs are off. Investigating that now.
And finally I found a way to demonstrate the other issue I was having:
With the "Sprite (Material Extension) I was using originally, the UVs are different from the UVs in the "Sprite (Effect).
When used together with the (fixed) FlipBookUVs, one is getting 4 words per particle instead of one.
See this file for a demonstration: TextSpritesExampleGegenlicht_Tom_SpriteIssue.vl (206.4 KB)
So I was running into a combination of different bugs, hidden parameters and inconsistencies…
I learned a lot about VVVV and FUSE, but when I think that in Tooll3 this whole setup needs 8 nodes and took me minutes to set up, while here it was several days of banging my head against all kinds of walls, it’s rather “interesting”:
@Thomas_Helzle again, there are very few off-the-shelf solutions. Once you’ve patched this, it’s always your solution, with all the low-level possibilities. You can always contribute to this development by making similar tools or improving existing ones. See how to develop with git and join on github. You can also create your own tool and post it publicly
The size just changes the size of the sprite, not the UV map.
One has to open the Sprite node and change “Use Normalized Texcoords” to get usable results (“usable” as in what one would expect from a billboard type primitive).
So yeah, as fascinating and powerful as VVVV and FUSE are, they come with quite a load of unclear and mostly undocumented things that make it hard to learn.
