Feature DynamicBufferMesh with DrawArgsOption (Indirect Drawing)

[kopffarben]

PR Details

This enables indirect drawing

sponsored by mbox

This PR extends the DynamicBufferMesh node with the option to use a DrawArgsBuffer. This enables a dynamic mesh with a variable DrawCount, which is fully controlled by a ComputeShader.

This is especially important to make the complete compute pipeline of VL.Fuse indirect. Without the need for ugly ReadBacks.

All changes should not break any existing patches, as I have only added features.

HelpPatch

VL.Stride\help\Rendering\HowTo Dynamic Buffer Mesh with Indirect Draw Option.vl

Description

Changes in the source code

I have created two new classes in VL.Stride.Runtime.

• MeshDrawIndirect
  • which inherits from MeshDraw and adds a DrawArgs buffer.
• MeshRenderFeature
  • which in turn inherits MeshRenderFeature from Stride
  • there I handle the method Draw(RenderDrawContext context, RenderView renderView, RenderViewStage renderViewStage, int startIndex, int endIndex) a little differently than in Stride, otherwise it is a copy of Stride
  • I make a difference in the DrawCall whether it is a MeshDraw or a MeshDrawIndirect
  • The MeshRenderFeature node is automatically replaced because the new one in VL.Stride.Rendering is automatically referenced in the CompositingNodes

Changes in VL

Customized nodes:

• DynamicBufferMesh in VL.Stride.Rendering.vl
  • here I have added the option for a DrawArgsBuffer
• MeshRenderer in VL.Stride.Rendering.vl
  • here, too, the DrawCall distinguishes whether it is a DrawMesh or a MeshDrawIndirect

Added Nodes:

• DynamicDrawArgsBuffer in VL.Stride.Graphics.vl

Motivation and Context

Make VL.Fuse and VL.Stride more awsome

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation

[tebjan]

Very much needed for some GPU techniques. Did you see my draft PR on Stride?

stride3d/stride#1482

This would be the proper way to do it and Stride is currently releasing packages more frequently. If you want, you can pick up my branch and finish it. It would be a cleaner solution than accumulating technology in the vvvv repo that doesn't flow back into the engine itself.

Another point against having such a central class as the MeshRenderFeature in the vvvv repo is that it will mask the original one and will not get the changes/updates from it anymore. Thus putting an extra maintenance workload on it in the future.

[kopffarben]

@tebjan Ahh no, I haven't seen the PR, but it does more or less the same thing. Ok, thinking about DrawAuto at the same time is of course a great idea.

Just to understand, couldn't DrawAuto also be derived from VertexBuffer.Flags == BufferFlags.StreamOutput. Only then does it make sense in my understanding.

But for now I would prefer the workaround via the VL.StandardLibs, since we (mBox) currently need the feature.

And at the same time I would try to make a PR for Stride. As soon as this is accepted and a new release is out, I would then revert it.

[azeno]

Looks good to me. Once changes are in Stride we can revert some parts.

And like we discussed in our call, C# code can be simplified a little bit by using https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.unsafeaccessorattribute?view=net-8.0, the drawing logic can be shared by adding one static helper method called by both the MeshRenderFeature and the MeshRenderer and therefor the newly introduced SplitMesh node removed again.

[tebjan]

Just to understand, couldn't DrawAuto also be derived from VertexBuffer.Flags == BufferFlags.StreamOutput. Only then does it make sense in my understanding.

I don't think you should derive it directly from the flag. You could have a StreamOut buffer that you want to draw differently.
It is true that DrawAuto always needs a StreamOut buffer, but not vice versa.

Also, it is better to do a bitwise check if the flag is contained instead of the == operator because flags could be combined:
if (someInstance.Flags & flagToCheck) != 0)

But for now I would prefer the workaround via the VL.StandardLibs, since we (mBox) currently need the feature.

And at the same time I would try to make a PR for Stride. As soon as this is accepted and a new release is out, I would then revert it.

Ok, but would you (or someone else) actually happen to have time in the next weeks to follow that through? And what kind of support would you need from my side?

[kopffarben]

@azeno I have changed everything as discussed yesterday and have also included Tebjan's comments. MeshDrawIndirect now has a DrawAuto property, in case you want to draw a StramOut buffer other than DrawAuto.

All changes have been implemented in the Feature MeshOutline and Wireframe as Components for Entities PR as it is based on this branch.

[kopffarben]

@tebjan I would try to PR the IndirectDraw feature in Stride next week. Would be nice if you could look over it again then

[azeno]

Was merged by 6cb30a5