How do I make a radial UV texture coordinate map?

staffpicks

#1

Hey ladies and gents!

I’m working on a shader that pans inward towards the center of the texture, so I need to find or create a radial texture coordinate map. Does anyone have such a map on hand? If not I’ll likely try to make it in Processing. I’ll include a breakdown if it comes to that.

Here’s an example:


How does Shader Graph connect the polar filter effect of PS?
#2

Is it something like that that you want?

https://youtu.be/JYbgjCR8PMI?t=334


#3

Hey @Kevalier, does it need to be just a texture? I’ve run into this as well, and I found I always got a weird crease where the texture wraps around. A few people on here just recommended I make a ring plane and “bend” the uvs around into a circle, then just have a texture that tiles on at least the X.


#4

Thanks for the quick responses guys! As usual there’s a few ways to go about it, so a texture isn’t necessary. I’ve UVed a “vortex plane” mesh before as Travis mentioned, and I think that’s gonna be the way to go, again. Just wanted to try something new.

If anyone is looking to use what I asked about in the original post in the Unreal Engine 4 Material Editor, this node accomplishes what I was looking for:

With this you can simply pan a texture in a vertical direction to get a shockwave or vacuum shader. As Travis mentioned, there is a weird crease.

Node:


#5

Pardon the double post, but I can only put one image at a time.
Node when previewed:


#6

In processing:

// https://en.wikipedia.org/wiki/Polar_coordinate_system#Converting_between_polar_and_Cartesian_coordinates

size(512, 512); //Going larger that 512 is not worth it. You only get 255 steps of value in any direction anyway.
loadPixels();

float maxLength = dist( 0.5, 0.5, 0, 0 ); //Get the maximum distance to a corner, for normalization.

for(int x = 0; x < width; x++ ){
  for( int y = 0; y < height; y++ ){
    int index = x + y * width;
    float X = x;
    float Y = y;
    float U = (X / width) - 0.5; //Translate the origin to 0.5,0.5;
    float V = (Y / width) - 0.5;
    float r = 1 - (dist(U, V, 0, 0) / maxLength); //Get the radius sqrt(x^2 + y^2) and normalize.
                                                  //This normalization may not be what you want. Feel free to replace maxLength with 0.5
    float angle = atan2(V, U) / (PI); //Get the angle in radians, then normalize.
    color c = color( r * 255, angle * 255, 0 ); //Multiply by 255 to get 0,255 range color.
    pixels[index] = c;
  }
}
updatePixels();
save("RadialUVTexture.tga"); //Check your Sketch>Show Sketch Folder. (Ctrl+K)

Outputs:

Normalizing to 0.5 instead:

I recommend ignoring the V value in this case actually, you just want a radius. With that you can add distortion or whatever you want to it and just sample X values only. That way you don’t worry about creases. Instead you just make your pattern a single row instead of needing Y information. If you do choose to use both make sure your texture is tileable in all directions.

In addition: There is this old blog post which does what you want probably with both textures, and nodes.


#7

I don’t have my finished shaders in front of me, but from my scratch notepad I found this note from when I made one a few months ago - it looks correct, but I can’t verify. I’ll try to update when I get home:

u= sqrt(dot(uv.xy, uv.xy))*2; 
v =  (atan2(UV.x,UV.y)/-3.14) * .5 + .5; 

Or if you want V mirrored so it’s seamless:
v= abs(atan2(UV.x,UV.y)/6.283185);

atan2 is a pretty standard included function - you might not be able to do this in unreal entirely with nodes, but you can definitely use a custom node and use it in your shader code.


#8

Pretty sure this is accurate: but i’m pretty sure that if your UVs are 0-1 you’ll need to subtract (0.5, 0.5) from your uv.xy first. Although again in hlsl might as well use length(uv.xy) instead. Let the builtin do the work.


#9

I always forget about that function! Do you know if there’s a cost difference? I assume length is doing trigonometry to solve (length = sqrt(x^2 + y^2 + z^2)? I can’t recall the full long form for dot product, but I’m guessing it’s less efficient than this?


#10

It would be up to the compiler really. Most likely it is doing sqrt(dot(xyz,xyz)) because that expands to sqrt(xx + yy + z*z) which is the same thing. It definitely won’t be using pow(x,2) because that is unnecesary, but I can’t imagine it is any different. The reason to use length is that if the compiler has some fastmath approximation for it, it might use that instead without you having to think about it.

With that in mind, sqrt(dot(xyz,xyz)) totally works because it is mathematically equivalent to the longform version for the pathagoream theroem. Just easier to write.


#11

Because you guys are already talking about Processing. Is there any use with Processing in the vfx role? I have learned processing and even programmed my own full space invader version game with it. (must say tho, Processing is fun)
*I always thought that processing is useless for Industry level stuff, Would be great if you put light on the subject shortly.


#12

I’m a little intrigued by this too - this thread is honestly the first time I’ve seen processing mentioned in a useful capacity for our industry, so I’d love to learn more about how people are taking advantage of it.

Python on the other hand…


#13

Theres definitely room for processing. I used it quite a few times in production to create small form tools - its good when you want something done fast (maybe not necessarily nice)

At the end of my 2014 reel I’ve put in a point cloud generator for characters, it’d build up point cloud geometry based on depth slices. This geometry would also be baked with engine information such as per-point position & index.
I’ve made baking tools for animations before, mesh generators, flow map painter & a few texture based things. All are a lot faster to hit the ground running via processing, and then simply share through a production studio relatively simply as executables. For anything that needs speed though, it’s a little more of a touchy subject! If I’m realistic, performance can become an issue and some of the UI features aren’t 100%. Using shaders is also not as simple as it could be.

PS, there’s a couple of libraries I love for processing; controlP5 for beautiful UI out of the box, and toxiclibs with (amongst a ton of other things like physics etc) a marching cubes mesher for data sets - which can then be exported to .obj.


#14

That’s awesome. I can definitely see it being useful for internal dev tools, etc. I’ll add it back onto the list of things to keep learning!


#15

I’ve used Processing for animated textures/patterns because I enjoyed the code based approach and had a clearer understanding of what I am doing and what I want to achieve. The end justifies the means ;D
Also a big advantage of Processing is how readable and easy to follow the code is. Everyone in the office was able to tweak our tools to their liking. I highly recommend Processing as an additional tool.


#16

Thanks! Now I feel comfortable to meantion it in my CV. Is there any reason to keep learning Python then (i know python is used for many reasons) but it sounds that for visuals processing can handle stuff (my game dev prof. Showed us how to make the AMIGA ball replica with it ):blush: and build “physics” environment with all the OPP rules. Now we work a lot with c# for unity :slight_smile: .
Thanks alot @Leo @alex.underhill !


#17

Python is easily the most used and useful “glue” of modern production pipelines and tools. I’d highly encourage you to keep up with Python, as it’s going to add tremendous value to any dev studio.


#18

Out of curiousity, what’s on your list right now? Are there any industry tools we should be soaking up in the coming months/years?


#19

Yeah, processing has the benefit that it is really easy to create textures or resources with it in a very scripting centric way. No need to get into a bunch of python libraries.

But, you should absolutely learn python. Every film vfx tool uses python or has a python api, and many game tools do too. Each tool has its place, but if I had to tell you to learn one or the other I would go with python every time.


#20

Just as an aside, I’ve found that by removing mipmapping from the texture, the seam will go away. Not sure if that’s true for all engines though.