You've Been Inform'd Ep5: Go f-UV Yourself

Inspired by Ryland

12 Likes

Really neat @Ryland Thanks @ALan for the demo.

Extremely cool! Thanks @Ryland and @ALan!

Every time I see the word ā€˜informā€™

informer understand GIF

Well this certainly beats me having to make a video to explain it!

When you stack the UVs you have to be careful that youā€™re maintaining the 32-bits of the UV through the whole chain. Otherwise youā€™ll start to see some shifting in the image. From the looks of it, the comp node works in 32-bit in 2023, but for anyone using an earlier version this is something to watch out for.

The aliasing thing is definitely a bit of an issue as well. The further you push something in one go the more it will happen. This can be mitigated by adjusting the filtering settings, but its one of the inherent drawbacks which is why I donā€™t typically stack my UVs on top of each other too much. I think its most useful for taking two warps and then animating between them.

Say you had someone breathing in and out and you wanted to make it seem like their chest was inflating more when they inhaled and deflating more when they exhaled. You could do two warps. First one would just be warping out for the inhaling, second one would be warping in for the exhaling. Then you would animate which warp is being applied by mixing between the two UVs. That way you only need to set one or two keyframes for each warp instead of animating the warp with each breath. Client wants more or less, turn down the effect on the UV.

1 Like

@ALan, I believe you are getting the aliasing on the final output because it looks like maybe some of your actions are in 8bit. The UVs can be done at 16bit, but I would recommend using 32bit for all of the actions that are warping the UV maps for the least amount of sampling hit.

1 Like

I would add that this can be rather annoying because there are two settings for 32-bit in action. One in the node settings and one in the render tab. When I start to see my image shifting in a way that seems wrong then I always check to make sure both settings are at 32-bit.

Never took the time to figure out why there are two settings or which of them is the important one but thats always where I go first when Iā€™m having issues.

2 Likes

I feel obligated to add that it seems like being aware of concatenation is really important here, especially if weā€™re in 32-bit in flame.

1 Like

I am aware of it but I thought it only happened inside of Action :thinking:

The ā€œuse 32-bit precisionā€ or whatever it says setting is kind of annoying, agreed. Because like- yeah- Iā€™m feeding you 32-bit, if I didnā€™t feel like I needed that precision I wouldnā€™t be setting this node to that.

I mean adding anything in between these actions that would end up breaking the chain of 32-bit, which is really easy to do in flame.

1 Like

It seems better in 2023, but in previous versions, Iā€™d often have to put a color management node in front of the actionā€™s back (if using the Same As Background option) and set it to 32bit to help force action into 32bit mode. It could get finicky at times for me even when enabling 32bit output.

Yeah. Sorry. It has a literal meaning and then a Nuke-ish meaning.
https://learn.foundry.com/nuke/content/comp_environment/transforming_elements/node_concatenation.html

I thought we were talking about filtering (Nuke-ish)

1 Like

Yeah thats my exact experience. Reassuring to know Iā€™m not the only one. Definitely one of those things where you feel like Flame is gaslighting you.