What options do I have for making per vertex calculations on a given mesh?

High guys,

I have a mesh that is occupying big portion of my screen and I need to make realtime vertex re-positioning on it.
Now the logic that I will use to determine the positions of the vertices can be made to depend on typical vector math functions using square roots and trigonometric tasks, or it otherwise can be done completely by look up large arrays with simple arithmetic averaging logic ( no square roots and no trigonometrics used). Both approached are totally viable.

Now what are the options that I have to make this large runtime task with lowest performance cost possible?

Reading data is almost always faster than doing heavy math in a shader, although the precise details matter and profiling on all your different target systems is the only true answer.

If you can push the “second position” for each vertex into a blend target, then morphing between them is very low cost. This assumes that all vertices move based on a single blend.

If you need per-vertex blend control, then you can build the second position as a second vertex data channel, and use a runtime calculated texture to apply the weight between position A and position B.

Lowest performance possible:
calculate data inside a 3d program, make an alembic file. Import in engine.

A runtime alternative is a mesh with morphs.
1 morph per vector. Takes its toll though, so its not very performant.

Material shader.
You are limited in a few things. But you could make a texture in which each pixel has color values out of range to describe local XYZ shifted points.

you could potentially bring those value into range with a bit of math on the texture before you produce it.

Either way. The shader would then loop the pixels of the texture, read the values, and morph the object by shifting the vertex in local space.

the hard part here, is figuring out how to lay the texture out - you have to break apart Pivot Painter to do that. Vertex order counts…

jwatte
How about full math calculation (trig/sqrt) per vertex per frame. In a manner that all I need from the cpu side is a couple of vectors while the mesh and all its calculation is done using programmable gpu units. Disclaimer, I am new to this field, but I have done a lot of cpu based procedural geometry, and I am reading about Vulkan. What are my options in UE4 to do those sorts of tasks.

To put you in the full picture let me add these two notes:
a. The mesh I am editing in real time is such a big mesh and is a very essential game element in itself that I need to manually change as part of the game rules.
b. More importantly, I have done the job fully by CPU serial mesh calculation logic and the performance was roughly decent, so I decided to move the math and the mesh calculation to gpu seeking SIMD benefits but I am really new to gpu programming.

Thanks indeed for your contribution.

Say that I want to fully calculate vertices in the gpu mathematically, without any imported mesh, only programming code to the gpu. No imported mesh, no texture or morphs for interpolation. What are my options to go to. May be this looks not the ideal way of doing it but I would like to try it because I am very familiar with vertix calculation, and because it might be performant enough in my case.
I really wish I do this now, even if I ended up utilizing what you preferred in the final project.

Thanks.

So, I wrote a wall of my thoughts. And now deleted it.

There is no practical way to do this in engine entierly.

Make a mesh outside of the engine.
Pick a power of 2 texture size that fits the max number of verts across.

Uv unwrap so that each vertex sits in the middle of a pixel of said texture.

Now in engine, you can do any maths on anything that has the same number of vertex as pixels in the texture.

You can bake the normalized math in a render target.

And you can have the mesh use the render target × normalws × max value pre normalization.

Simply make a BP that does the calcs, produces the texture, and pushes the material instance changes.

This method works on anything. 3d geometry or not.

You can use the same method to bake a normalized normal. Or a tangent for the shader to use instead of vertexnormalws.

as always. The more passes you add, the more calcs need to happen, the worse performance gets.

**MostHost LA

Thanks for your time and effort, I really appreciate it.**

The best way I think to describe my request is this. Suppose that I wrote a graphics code in Vulkan, or CUDA (which is what I am really trying to do) what are my options to make that code part of my UE4 exe. I am sure there must be a direct way for exactly that. A pure graphics API code must be not that alien to UE4’s expectation from devs.

Unreal Engine expects to know and control absolutely everything about the geometry. Trying to write your own shaders not as part of the engine is likely to go off the rails. You have to make sure you understand everything that happens inside the rendering pipeline, for all the shading modes and models that could be used.
That being said, consider this:

Look especially at the concept of Vertex Factories.

That’s cool really, I think I will eventually have no option but to dive into that.
In the mean time tho, I wonder whether Niagara script modules written in HLSL that run on GPU simulation would be of any relevance here, what do you think?

If you can make it work, and it runs fast enough for you, go for it!

I posted the question in C++ forum and I got the exact answer I was looking for, I will post the reply here for any one in the future found this thread for similar inquiry.

You just write a Compute Shader (you don’t target a specific API like CUDA or Vulkan - UE4 handles that translation for you based on the platform you are compiling for). Tons of resources online for this stuff:

https://medium.com/realities-io/usin…4-f64bac65a907
http://www.valentinkraft.de/compute-…real-tutorial/

by: ExtraLifeMatt