Right now I’m generating Mesh data using a ComputeShader, sharing a buffer with a vertex shader and using Graphics.DrawProcedural to generate the mesh. But from what I can tell that mesh can only be seen by one camera, the camera that is the current render target as of the DrawProcedural call. But I have two cameras that must show the mesh right now, from different angles, with at least one more likely to come later.
The only solution I can think of is to pull data off the GPU and generate it on the CPU, but that comes at a tremendous performance cost, especially since this mesh is supposed to be constantly recreated every frame.
I have a fear of harming performance by generating the meshes multiple times (if nothing else, just the system copying the 100,000 vertices and color data every frame for each camera seems a waste). Also, I’ve been having problems with my mesh generation and multiple cameras being active at once and was hoping there’s another way to generate the mesh to try and narrow down what’s going wrong.
but if you have the data on a compute shader it is not copied if you render it again.
Even if the DrawMeshProcedural supported rendering to multiple cameras at the same time it would do separate render passes for each camera internally
To generate a mesh it has to create vertices for the new mesh in GPU memory, which at minimum involves copying the vertex data somewhere else on the GPU - it can’t just treat the data from the ComputeBuffer as mesh vertex data directly because that data could change.
you could do another approach for rendering it.
You render a dummymesh with the same amount of vertices with Graphics.DrawMesh or Graphics.DrawMeshInstanced if you need to render multiple copies.
Then swap out the vertex positions and normals from the structuredbuffer in the vertex shader.
Not being able to populate a mesh’s vertices and indices from another GPU buffer is tough. This is a (lack of a) feature I keep running into and represents a major shortcoming for advanced graphics programming in Unity.