WebGLRenderer: option to enable multi_draw / gl_DrawID in vertex shader

[vegarringdal]

Related issue: #XXXX

Description

Was trying to make a modified Batchedmesh, but I could not not use gl_DrawID in shader.

now it should be possible to enable it like this:

const material = new MeshStandardMaterial({
  color: 0x00ff00
});
material.extensions = { multiDraw: true };
material.onBeforeCompile = (shader) => {
  // magic 🪄 
});
 

See here for more information:

https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_multi_draw

Note: Although the extension name is named WEBGL_multi_draw, the extension must be enabled with the #extension GL_ANGLE_multi_draw directive to use the extension in a shader.

When this extension is enabled, the gl_DrawID built-in can be used in shader code. For any multi* draw call variant, the index of the draw i may be read by the vertex shader as gl_DrawID. For non-multi* calls, the value of gl_DrawID is 0.

<script type="x-shader/x-vertex">
  #extension GL_ANGLE_multi_draw : require
  void main() {
    gl_Position = vec4(gl_DrawID, 0, 0, 1);
  }
</script>

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
673.5 kB (167.2 kB)	673.6 kB (167.3 kB)	+163 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
454.2 kB (110.1 kB)	454.4 kB (110.2 kB)	+163 B

[gkjohnson]

Because objects are rearranged for object sorting and filtered for frustum culling the gl_DrawId isn't a useful field and not consistent between render. Users should use the batchId attribute if you want the object index in the shader.

[vegarringdal]

Because objects are rearranged for object sorting and filtered for frustum culling the gl_DrawId isn't a useful field and not consistent between render. Users should use the batchId attribute if you want the object index in the shader.

How I understand it the gl_DrawId is upped+1 for each offsets/starts in the multiDrawElementsInstancedWEBGL
If you use a attribute to hold the id, it will need to be a lot bigger and match index, so basically position length/3.

Unless Ive missed something the size of the texture will be a lot smaller in most cases wont it ?
If you have batched 100 drawcalls on large meshes the texture still just need to be size 100 * element size of number you have.

In this presentation I found on khronos.org they also say on page 14

gl_DrawID is considered ‘uniformly varying’, so
texture lookups will be cached across a given draw.

Dunno if this is helpful compared to buffer attribute, I really do not know enough about this stuff.

[gkjohnson]

How I understand it the gl_DrawId is upped+1 for each offsets/starts in the multiDrawElementsInstancedWEBGL
If you use a attribute to hold the id, it will need to be a lot bigger and match index, so basically position length/3.

Unless Ive missed something the size of the texture will be a lot smaller in most cases wont it ?

This is the case but you wind up using another one of your limited texture slots. I don't think it's worth changing BatchedMesh until it can be shown this is causing issues.

It does occur to me that a separate texture like this, though, can be used to render multiple of the same geometry in a single BatchedMesh without having to duplicate the data in the vertex buffers. So effectively we could cover instanced meshes and batched rendering all with a single object and draw call. An API with this in mind would need to be designed, though, which doesn't sound straight forward.

I suppose we can add this extension for experimentation, then. @Mugen87 is there anything else we need to change for adding support for the extension? I'm less familiar with what needs to be done.