#Difference between mesh vertex modification via C# script vs vertex shader

1 messages · Page 1 of 1 (latest)

mild moon
#

Can anyone clarify this for me ? To my understanding, scripts are run through the cpu while shaders run on the gpu, and the gpu tends to be able to handle a lot of repetitive data on the screen more efficiently than the cpu. Would this mean modifying vertices should be better suited to be done via a shader than manually modifying vertices through some script? Im fairly new to shaders so any resources to better clarify when I should be doing things in a shader for optimization purposes.

Also side note, image shows a tutorial I was following to learn up a little on shaders, and I noticed the plane they used is still highlighted as a plane, whereas the vertices are clearly being modified... what does the red plane outline represent ? If it had a collider for example, would the waves not matter and the collision still be triggered by the initial plane or the new wave contours ?

tropic oriole
#

shader cant change mesh collider. so yeah, the collision will still follow the original contour/shape

rough imp
# mild moon Can anyone clarify this for me ? To my understanding, scripts are run through th...

Shaders are extremely fast, you should almost always use them if you want to animate the visual mesh frequently (e.g. every frame). Vertex shader has to be processes regardless, simple deformation code in addition often doesn't make much difference in vertex shader. Your CPU on the other hand will very quickly get overwhelmed if you need to process high resolution meshes frequently. The two main downsides of vertex shaders are that:

  1. they run every frame, you cannot run the shader once at the start and expect the deformation to stay in subsequent frames (while the CPU mesh modification will remain until changed again for no cost on subsequent frames)
  2. The vertex data from the vertex shader cannot be retrieved to the CPU side meaning you won't be able to use it to update the collision shape (if you use mesh collider) or otherwise use the data.

Water shaders for example use almost exclusively a GPU side solution for the waves but then need to resort to some extra measures to get the height data for floating things like boats. One solution is to calculate the required data points (wave heights for every floating device) separately on CPU side using the exact same math from the vertex shader

As a second example, the game terrain is generally done using actual mesh and if it needs to support terraforming, that is done in CPU script so that the collision shape matches the visual shape. That is often not an issue because the terraforming is often done very locally, on quite low resolution meshes, the terraforming doesn't happen all the time and the effect can be optimized by splitting the mesh into reasonably sized chunks. I'm not aware whether unitys terrain system supports such realtime modification, but that is just one example where you would generally use CPU side modification rather than GPU shaders.