Feature request: UVFlow processor

[fight4dream]

It would be great to have the flow follows the direction in uv space. for example, a river mesh may be curved and would usually be extended along one of the uv direction.

[omid3098]

I am trying to think of a way to map rays on something like river with repeating UVs. There would be some challenges:

• If I map rays along UV space, we cannot detect obstacles because there would be multiple points on mesh per repeated UVs. So the only logical flowmap based on UV space would be detecting UV edges along the river path without having any obstacles something like this

• The other way is to have rays on the whole mesh and use the rendered flowmap with lightmap UV in a custom shader. this way we can have obstacles along the river and use UV0 for tiling purpose like this:

[fight4dream]

regarding obstacles, i think it is the job of the “outer flow processor”. is it correct that, the outer flow simply add to the input and not override it? if so, then i think the “uv flow” doesnt need to handle obstacles.

in my mind, i am thinking about the directions is with respect to tangent space (it works according to uv right?). so i think it will work across the tiling boundary. i am not sure about the “lightmap uv”. if you are referring to uv1 that is produced by unity lightmapper, it is kind of projections and stitches. it might be a bit unpredictable. maybe you are thinking of unwarp another set of uv and store into uv2+ ?

[omid3098]

is it correct that, the outer flow simply add to the input and not override it?

Yes.

if so, then i think the “uv flow” doesnt need to handle obstacles.

So far the result of these processors will be converted to a single flowmap texture. it actually does not matter what processor is handling which part. The question is "in what space" we want to use the flowmap?

i am thinking about the directions is with respect to tangent space (it works according to uv right?).

Yes.

so i think it will work across the tiling boundary.

No. if we have obstacles in the first part of the river, and for example we bake the outer flow of that area, this flowmap only works in the first part of the river but will be repeated in other parts of the river even though they do not have obstacles. This effect is similar to UV overlapping when baking textures in 3D modeling tools.

i am not sure about the “lightmap uv”. if you are referring to uv1 that is produced by unity lightmapper, it is kind of projections and stitches. it might be a bit unpredictable. maybe you are thinking of unwarp another set of uv and store into uv2+ ?

We can have an option to get the current UV set of the mesh. so, it does not matter if Unity made that through Lightmapping pipeline or we create another separate UV channel for this purpose.

Also another option could be baking results into the vertex colors of the mesh. it will require more mesh details to have more accurate results and can be done using a dedicated processor like FlowmapRendererProcessor.

[fight4dream]

did i accidentally hijack the branch to do the typo fixes?

the original issue “feature request for uv processor” should still open