GraphicsBuffer, Mesh vertices and Compute shaders

I am working on a project that performs manual skinning for meshes. For performance reasons this is currently running on the GPU through Compute Shaders. The resulting vertices are fed to a vertex shader through Compute Buffers. This is clearly not ideal. I would much prefer a way to update the mesh data directly, on the GPU, so that no changes to shaders are needed.

I noticed that a new GraphicsBuffer type has been introduced recently, which is used to supply an index buffer in a call to DrawProcedural.
Are there are any plans to allow users to get the GraphicsBuffer containing the vertex data of a mesh? And will GraphicsBuffer be compatible with Compute Shaders?

I realize this has been asked before, for instance in this topic:
https://forum.unity.com/threads/graphicsbuffer-and-mesh.636631/
However, seeing as how that topic is in an archived beta section, I wanted to request this feature here as well.

 

Thank you, that is great to hear!

 

Really look forward to this, Hopefully we could finally use graphics buffer to do some serious graphics stuff in unity

 

Thanks for reply! actually I want to know how to use GraphicsBuffers with "Vertex" and "Index", or are they just useless flags for now?

 

Hi @richardkettlewell GraphicsBuffer is great news. Does it / will it support append/consume buffers with varying dynamic count?

 

@richardkettlewell Excellent! For me, that's the best news from Unity in a long while. That, and multicompile for ComputeShaders.

It would be great to have examples of use in the Unity docs.

 

So what I am getting from this is the GraphicsBuffer can be used to render an index array generated from the compute buffer with Graphics.DrawProcedural?

But in the material shader, I should be able to use the "uint vertexId : SV_VertexI" vertex program input to read from a Compute Buffer containing the vertex positions, and set the vert position from inside the vertex program.

I will test this out at some point soon...

 

I just tired out GraphicBuffer indices in 2020.1.0b5 and it seems to work as expected.
https://github.com/cecarlsen/HowToDrawATriangle

Now a couple of questions come to mind @richardkettlewell

1) When can we expect to see GraphicsBuffer.Target.Vertex to be working in a public beta?

2) Am I correct that a GraphicsBuffer.Target.Vertex will finally make it possible to use DrawProcedural and ShaderGraph together? If the vertices are provided like a mesh with vertex shader semantics I don't see why not.

3) What is the fate of ComputeBuffer? Will it be phased out? GraphicsBuffer.Target seems to cover what ComputeBufferType did and more. So why keep it? And if that is the case, why didn't you expand the features of ComputeBuffer instead of adding a new type?

 

Push, push, we need this =)

If GraphicBuffer vertices support vertex shader semantics, wouldn't that eliminate the need for binding custom vertex ComputeBuffers to shaders for use with DrawProcedural? And wound't that mean that default shaders as well as ShaderGraph compiled shaders would accept GraphicBuffer verticies through DrawProcedural just like they accept Meshes through MeshFilter and MeshRenderer?

Good to know.

 

Thank you.

Exactly! This is exactly what we need. It would be an amazing feature for anyone working with procedural/generative content. There are many benefits from doing this ... perhaps the greatest being that that code for GPU bound procedural content creation can be decoupled from specific SRPs, or perhaps that every existing shader would work with GPU bound procedural content. Currently, it is a pain to write DrawProcedural compatible shaders for HDRP. And for URP, although there is an API for it, things like shadows are not even supported at the moment.

 

In this example, you set the vertex from inside the compute shader and it can be read from inside the graphics shader with the DrawProcedural call. However, you set the GraphicsBuffer from inside C# rather than inside the compute shader. Was this due the same issue I came across? The issue I'm having with the version I made for my project, however, is that when I create a graphics Buffer for indices (using sizeof(int)), Assign it to a RWStructuredBuffer<int>, I am unable to pull data out of the compute shader. If, in the C# end, I turn

GraphicsBuffer g_buff = new GraphicsBuffer(GraphicsBuffer.Target.Index, indexBuff_size, sizeof(int));

to

ComputeBuffer g_buff = new ComputeBuffer(indexBuff_size, sizeof(int));

It works; With ComputeBuffer g_buff.GetData(), I get an array with valid data. With the GraphicsBuffer, I get an array of all zeros.

richardkettlewell, is GraphicsBuffer actually able to be written to from a compute shader yet?

 

Aww nuts. I could currently really use the vertex target support for my project. Definitely need the ability to generate vertices from compute.

 

Hi Richard,
thanks for the help! However when I try to use

Code (CSharp):

1. var indexBuffer = new GraphicsBuffer(GraphicsBuffer.Target.Index | GraphicsBuffer.Target.Structured, count, sizeof(int));

I get following errors:
Failed to create Compute Buffer UAV, HRESULT: 0x80070057
Failed to create Compute Buffer SRV, HRESULT: 0x80070057

When I use GraphicsBuffer.Target.Raw instead of GraphicsBuffer.Target.Structured it works, but I like to use a RWStructuredBuffer ... any idea how to fix that?

Btw.: I'm using Unity 2020.1.0.b13.

Also Graphics.DrawProceduralIndirect(_goMat, _mesh.bounds, MeshTopology.Triangles, _indexBuffer, _bufferWithArgs); is not working!

Best regards,
Chris

 

Also looking forward to be able to write vertex data in compute. You have an ETA when or Unity version where this will be available?

 

I think you missed CommandBuffer.SetComputeBufferCounterValue

 

It would just allow for some slight optimization in my case that might not even make any difference (I can reset the counter outside the command buffer).

What I would really like is a way to use ShaderGraph with data created in a compute shader. This could be done with:
A. DrawProceduralIndirect that lets you set a vertex buffer/vertex description.
B. A way to set Mesh data directly from ComputeBuffers or GraphicsBuffers.
C. Nodes in ShaderGraph for SV_VertexID and a custom struct array.
I think A would be simplest/most user friendly, followed by B then C.

Correct me if I'm wrong, but I believe currently to do this you need to:
- Copy the data back to the CPU and set it on a Mesh.
OR
- Export the HLSL for the ShaderGraph and modify it to use the custom vertex array/SV_VertexID.
OR
- I haven't tried this, but I guess if a compute shader packed the data into texture(s), a constant vertex buffer with fixed UVs could be used to index them.

 

I made a post
https://forum.unity.com/threads/support-drawprocedural-computebuffer-and-sv_vertexid.957215/

 

I, too, would like the ability to generate vertices in a compute shader without having to send them to the CPU and back.

My use case is extending the HDRP Lit shader with a vertex shader. One solution without modifying the HDRP Lit shader code could be to simulate a vertex shader via a compute shader, but something like GraphicsBuffer.Target.Vertex is needed. (Using Shader Graph won't work for me here since I need the actual HDRP Lit shader, not Shader Graph's Lit base.)

The post about my use case is here:
https://forum.unity.com/threads/adding-a-vertex-shader-to-lit.1037011/

 

Could you please give a ComputeShader example of how to write triangle indices to a ByteAddressBuffer? I think many of us are a bit confused about how to use ByteAddressBuffer's compared to StructuredBuffers where you have the data type defined

One more question, where can I find the documentation for the values that should be sent to the arguments buffer when using DrawProceduralIndirect? I've seen some examples of usage, but I'm unable to find the documentation of what the values actually mean.

 

Hi @richardkettlewell, are there any news on GraphicsBuffer as vertex buffer to be used with DrawProcedural? I don't see much in the 2021.1 beta release notes. It the work still in progress, or stalled? It is a long wait.

 

Thanks for the replies. That answers my questions

 

Thanks for getting back.

This is becoming increasingly frustrating. When you do any real time GPGPU/Compute geometry work and want to render it, there is no other option other than to write specific renderers and shaders every time. And with the crippling inter-incompatibility of legacy, URP and HDRP the workload just blows up. If only it was possible to set the GPU content of a mesh directly from ComputeBuffers I think we would see a lot more interesting procedural tools being made and shared by the community. I am not sure what good a new concept like GraphicsBuffer does without providing this feature. With the two new render pipelines, Unity has in effect become three separate engines. Really it should be called Trinity at this point. This feature would help glue them together again.

It is beyond my understanding why this has such a low priority at Unity.

 

@cecarlsen I agree, no idea why Unity makes this so difficult...

 

Hi @richardkettlewell, just wanted to ask when we can expect a straitghtforward way of setting up the GPU content of the mesh directly from Compute/GraphicsBuffers. I am worried whether this is even planned for 2021?

Besides regular rendering of procedural or simulation content straight from the GPU memory I would like to use it to efficiently construct raytracing acceleration structures for GPU physics simulation.

Thanks

 

HI @Aras thats great news! Please let me know if you'd need a helping hand with testing stuff. I am really looking forward to it.

 

This is truly great news @Aras.

Does this imply that targets are always CPU bound? What is (or will be) GraphicsBuffer.Target exactly?

 

Doh, should have checked.

Well, if Mesh will accept Target.Index and Target.Vertex GraphicsBuffers, then that is enough for me to pop the champagne.

Graphics.DrawProcedural (and it's siblings) takes a Target.Index GraphicsBuffer, but not Target.Vertex. This is equally important to me.

In terms of API, I am convinced you will come up with something sane, as usual.

 

Hi Aras,
Thanks for picking this up
Looking forward to try this out.

 

This look pretty awesome, excited about this! But in order for it to be fully complete we would need the same as GetVertexBuffer() for the normals -> GetNormalsBuffer(). I imagine this would be specifically relevant when using SkinneMeshRenderers.

 

Aha, all good then!

 

Hello!
Please tell me, for a Built-in project I use a ComputeBuffer to get information about vertices from a vertex shader. But it doesn't work on HDRP.
Then I tried to use a GraphicsBuffer (with Vertex, Raw and Structured Target), but it also does not help me, after calling GetData() I get an unchanged vertex array, the code is presented below.
What could be the problem?
Thanks!

Code (CSharp):

1. GraphicsBuffer OutputVertexBuffer;
2. OutputVertexBuffer = new GraphicsBuffer(GraphicsBuffer.Target.Vertex,gameObject.GetComponent<MeshFilter>().sharedMesh.vertexCount,Marshal.SizeOf( typeof( Vector3 ) ));
3. Vector3[] vertices = new Vector3[gameObject.GetComponent<MeshFilter>().sharedMesh.vertices.Length];
4. OutputVertexBuffer.SetData(vertices);
5. Graphics.SetRandomWriteTarget( 1, OutputVertexBuffer, true );
6. gameObject.GetComponent<Renderer>().sharedMaterial.SetBuffer( "OutputVertexBuffer", OutputVertexBuffer );
7. yield return new WaitForEndOfFrame();
8. OutputVertexBuffer.GetData( vertices );