I’m trying to write a function that will offset a row of vertices on the mesh via the vertex shader / tessellation in the material.
I’m having issues getting the row of vertices to be calculated locally rather then in absolute world space.
basically upon a twisted mesh, instead of having the vertices behave like applying a texture, they ignore the UV mapping entierly.
To solve this, I was considering using the Pixel shader instead, but before I go through that (sampling adjecent pixels and making calculations is far more expensive then using vertices) I figure I’d ask if anyone has any suggestions or tricks to sample specific adjacent vertices.
unfortunately vertex normal ws (dot) 0,0,1 isn’t returning the expected cosine.
let me back off.
Precisely, I need the cosine or angular value of each X/Y direction of each individual face on the mesh.
That should be the value of the Z axis of each vertexnormalWS - or so I thought.
My issue could also be related to something else, but before getting further into it, I think if anyone has any advice on this it would be greatly helpful.
Hi, I’m not quite sure I understand the problem, but basically if you would have a twisted mesh I would expect you to put in some seams into the UV map in the UV unwrapping process. So everywhere where you would have a seam you will have a break/discontinuity. So if you would have a seam between two adjacent vertices, then in the UV map they will not be adjacent, so you will have a break there.
If you would have many such seams you might get the impression that the vertices are distributed randomly on the UV map.
If that is the problem, then you could try looking into the “World Aligned Texture” node to get world aligned UVs.
can a part of the material graph be shown? There’s a VectorTransform for going from world to local space. There’s also a number of other transforms in the following list, specifically the Break Transform and Inverse transforms for location, rotation, and scale. So, possibly use Break Transform to break apart the mesh’s transform into location, rotation, and scale, then get world location of that, and use Inverse Transform Location to bring it to local space?
I’m not sure local space is the issue here. The formula is designed to be in world space - the issue is the direction passed into it needs to match the local space of the mesh.
This very simple formula produces a wave across the mesh.
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-tempid”:“temp_187510_1585702536532_119”}[/ATTACH]
If we replace Direction from a static parameter to a localized parameter, we start to get the kind of results that are needed.
The problem is that I can’t seem to find a way to solve for the local direction of each vertex as defined by the mesh - not the UV, forget I mentioned them.
IF you replace Direction with Another WPS node (normalized) you get a radial variation - because each pixel is interpreting the direction between world’s 0,0,0.
You can obviously offset this by Add/Subtract.
So then, transforming WPS to tangent space you should get a “localized” version - but you do not.
I think that because WPS node is essentially every pixel, substituting it with ObjectPosition is also not working correctly. And math with Object Position is also failing on me. (world position - object position).
Regardless of that, that’s still not exactly what I need, since it doesn’t target the specific pattern set within the mesh.
I’ve got no idea how you would offset a single line of vertices and nothing else around it…
But from your image
(1) the two 2pi are redundant, since you’re first multiplying by 2pi and then dividing by 2*pi
(2) what you’ve named “amplitude”, is in reality frequency (regardless what you input in the cosine it will always result in a value between -1 and 1), so what you’ve named “scale” is the amplitude
(3) Any reason why you’re not normalizing the “Absolute World Position”? Cause it seems to me you wanted to get the direction from origin to the current pixel but if you’re not normalizing the “Absolute World Position”, then you will not only take direction into account but also the length (so distance from origin), since (0, 0, 1000) dot (0,0,-1) = -1000 and not -1
The dot product automatically clamps the output value (the post-dot product value, and before everything else) to between 0 and 1, right? so multiplying 2pi by that value is not going to work unless the value is somehow modified to fit within the -1 to 1 range of a cosine wave. With only half a cosine wave getting reference in the graph, the math has to change to account for it. It all sounds too complicated for moving several vertices from one transform to another.
Nope, dot product is multiplying two vectors component wise and adds all those products up and returns the sum. If you want it normalized you would do that manually using “Normalize”.
And the values will only be positive if both vectors pointing in the same direction (angle between both vectors is < 90 degree). If they’re pointing in opposite directions the dot product will return negative values.
Hmmm, not quite sure what you mean by that. The output of cos is between -1 and 1 but the input can be any number (by default the period length of sine/cosine in ue is 1,0).
Cosine is between 0 and 2pi when it returns from Y=1 to Y=1. So, between Y= -1 and Y= 1, cosine is ‘traveling’, or described, by one half of 2pi. Amplitude is defined as the total height of the cosine wave (from y = -1 to y = 1), so in multiplying it by 2pi, I think the output would be incorrect for multiplying the two vectors since the formula for dot product utilizes the cosine of those two vectors multiplied and added. In other words, it sounds like the math is off. What is multiplying by 2pi and the amplitude doing, then?
*Amplitude is the total height of the cosine wave above or below its mean, or the x-axis in its graph.
However you wanna call it Amplitude - Wikipedia due to the wave equation I always use “peak amplitude” as a synonym for amplitude, not peak to peak.
Nope, you’re mixing the algebraic and the geometric definitions.
You might wanna look up the wikipedia pages about sine/cosine and especially dot product. [HR][/HR]
Again, I have no idea how to offset a specific line of vertices and nothing else around it, just pointing out what’s obvious to me in the image.
I was only using the geometric definition. Isn’t that the one that is utilized in the Unreal dot product node? I wasn’t arguing against the usage of 2pi, I was asking the question of whether it is applicable, and whether amplitude is applicable in the context of the material graph posted.
In the geometric definition you don’t add anything. I don’t know what definition unreal is using but I would strongly expect it to use the algebraic one, since your inputting two vectors, and not two scalars and an angle. You might wanna look at the wiki pages.
You might wanna read my first post after the image again (so my second post in this topic).
I don’t wanna sound wrong, but this discussion right now is pointless since I can’t tell you anything else than to read the wiki pages and as I said several times I can only point out what is obvious to me in the image and already did so.
Well, both 2pi are necessary.
you can make a material and test it out. To visualize it you need a grid of about 1 vertex every meter. Maybe add a tessellation multiplier to it of 4 to see finer detail.
The landscape may work fine for it.
The amplitude is the amplitude - or distance between the 2 crests. And what I named scale is actually something your probably shouldn’t do since you offset the value sideways/horizontally as well as vertically, but if you keep the value small it gives you a quick visual of where and how the pixels are moving.
Regardless, the problem isn’t/was never the formula as much as the inability to apply it only between vertices.
I will start to test creating a custom shader model, see if I can’t isolate a way to bind whatever formulas to vertices… maybe get a new input node sort of thing for it.
I referenced the geometric definition of cosine, not the geometric formula of dot product. The geometric and algebraic dot product formulas are similar and one can be derived from the other. You’re right, though, the algebraic one adds the vectors. However, the geometric one implies the value of those vectors (so basically, after they’re determined from the magnitudes of their components which are the xyz coordinates) and multiplies by cos of the angle formed between the two vectors. I was thinking that if 2pi is in use, then the algebraic formula of dot product is the wrong formula for projecting two vectors for moving them as an isolated group from the mesh. The geometric formula accounts for 2pi, even in the graph of cosine wave. Yet the Unreal formula for dot product is algebraic.
I agree that dot is not the best start for 2 vectors on the mesh. I think the reason dot works is that the calculation happens on every pixel of the mesh.
realistically, the formula itself doesn’t matter.
even with vertex color I have no way to say “for this inital vertex set calculate the direction based on -math-” and use it in the formula…
