@texone “reported a bug” concerning the Echo Effect in VL.Addons.
Looking into it I came to the conclusion that it is caused by the recent GPU change since the effect is working fine in the version just before it was merged (5.3 preview-0403). Looking through the patches reveals that the ColorIn node inside the FullScreenQuadRenderer is now working differently.
However, the idea is clear: in this rare case we decided to be more “progressive”, where most of the time we decide for conservative solutions including orange obsolete nodes in order to not break patches.
In this case we opted for the breaking change as we figured that no one wants those legacy nodes that behave the old way. “Everybody” wants to have the new version of the node and wants to adapt the patch in order to work with the version of the library.
So I fear VL.Addons needs to be adapted to work with current previews…
Mh I think you misunderstood. FullscreenQuadRenderer is now behaving differently than before which is potentially a breaking change for a lot of patches not just VL.Addons.
But the last screenshot shows “MyFullScreenQuadRenderer” that behaves as the old one?
If yes: I’d say there is a way to adapt VL.Addons in order to work with the previews.
Again the way FullscreenQuadRenderer handles colors / blending is different than before. I can work around that of course. Still it is a breaking change not just for VL.Addons.
Now, you can agree or diagree if that was a good decision, but that’s a completely different discussion.
Again, to me it sounds like you found a way to “fix” the FullScreenQuadRenderer node inside of VL.Addons. Is that right? The thing that you call MyFullScreenQuadRenderer: is it doing the exact same thing as FullScreenQuadRenderer did before?
What changed was that the sRGB to linear conversion had to go further inside to a more central place. That’s why you no longer see that device Color Space node in the patch. But now looking at it also became apparent is that by doing so the pre multiplication of the alpha channel now happens too early, it’s happening on the still sRGB encoded Color and not the linear one. You say you have blending issues so that would be my best bet.
We reverted a previous commit on the topic and moved color space conversion back out of a rather central spot. This should restore the old behavior of the ColorIn node (first bring the color to linear space, then premultiply the alpha).
The conversion to the device color space as well as the premultiplication will also happen on any pins of type GPU<RGBA>. Note that this part can’t be controlled manually and simply mimics the ColorIn node in its default settings. So should you have a case where your colors are already pre-multiplied you’ll not be able to use the RGBA -> GPU<RGBA> bridge and instead will need to use the ColorIn node.
Just downloaded the latest preview (6.0-59), installed latest stable VL.Addons (0.2.1) and the Echo help patch looks correct again. Thanks for bringing it up!
