Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

Feedback DrawProceduralIndirectNow without ComputeBuffer supplied arguments (and more immediate mode control)

Discussion in 'Graphics Experimental Previews' started by Per-Morten, Jun 17, 2020.

  1. Per-Morten


    Aug 23, 2019
    Hi, hopefully this is the correct place to post this.

    Currently the `DrawProceduralIndirectNow` function allows us to supply a ComputeBuffer/GraphicsBuffer with arguments (index count, start index location, base vertex location, etc) for how a mesh should be drawn based on an index buffer. Would it be possible to get a version of this function where we could supply those arguments directly, rather than through a Compute/GraphicsBuffer? This function would map to Direct3D11 DrawIndexed, rather than DrawIndexedInstancedIndirect, and look something like the following:
    Code (csharp):
    2. public static void DrawProceduralIndirectNow(MeshTopology topology, GraphicsBuffer indexBuffer, int indexCount, int startIndexLocation, int baseVertexLocation);
    Alternatively something like:
    Code (csharp):
    2. public struct DrawArgs
    3. {
    4.     public int IndexCount;
    5.     public int StartIndexLocation;
    6.     public int BaseVertexLocation;
    7. }
    9. public static void DrawProceduralIndirectNow(MeshTopology topology, GraphicsBuffer indexBuffer, NativeArray<DrawArgs> arguments, int argumentsIdx);
    Is this something that it would be possible to add?

    To give some background for this request:
    Over the last 4 weeks, I've been working on implementing custom frustum culling, static batching, and rendering in our VR app (largely due to issue 1217274).

    I've found that the fastest way for us to do our rendering (outside of a native plugin probably) is to store all batch related vertex and index information in compute buffers (tied to materials), and then have a `bufferWithArgs` that we update based on culling information & dynamic batching and use together with `DrawProceduralIndirectNow`. Essentially trying to emulate Direct3D11 DrawIndexed through DrawIndexedInstancedIndirect.

    The main problem with this approach is that calling bufferWithArgs.SetData() can take up a lot of time, time that would not exist if we were able to call a `DrawProceduralIndirectNow` that mapped straight to DrawIndexed, and didn't require the use of ComputeBuffers.

    In general, it would be great to have even more control of the graphics pipeline, especially in the immediate mode (Graphics.Draw*Now). For instance, being able to directly bind vertex and index buffers (so we didn't need to tie compute buffers to materials) would be hugely beneficial for us.

    Obviously, you can get this control by writing a native plugin. However, from my experimentation Unity seem's to clear the GPU state before issuing native plugin events, meaning that doing something as simple as writing a native plugin that simply draws a mesh using Unity's shaders is non trivial.
    LooperVFX likes this.