What problem does this solve or what need does it fill?
Currently, it's possible to bind a Vec or a raw Buffer to a custom material, but this has two problems:
- The
Vec version eagerly creates a new buffer every frame, regardless of whether the buffer actually needs to be resized. It also isn't usable as a RenderAsset as the Buffer is created in the AsBindGroup impl.
- The
Buffer version isn't usable from the main world without additional hacks, since a Buffer can only be created in the render world. This makes it difficult to work with, particularly if you also want to bind that Buffer to another custom pass, like a compute shader.
What solution would you like?
We should implement a Handle<Storage> abstraction that can replace both these use cases. This will be the Buffer equivalent to Handle<Image> and will produce a RenderAsset (likely one of our higher level wrapper types, or possibly a new type erased version that avoids needing a generic plugin).
What alternative(s) have you considered?
It's possible to work around this right now as noted above, but it's very painful and the docs are confusing.
Additional context
This infrastructure may be able to be re-used for portions of #13373
What problem does this solve or what need does it fill?
Currently, it's possible to bind a
Vecor a rawBufferto a custom material, but this has two problems:Vecversion eagerly creates a new buffer every frame, regardless of whether the buffer actually needs to be resized. It also isn't usable as aRenderAssetas theBufferis created in theAsBindGroupimpl.Bufferversion isn't usable from the main world without additional hacks, since aBuffercan only be created in the render world. This makes it difficult to work with, particularly if you also want to bind thatBufferto another custom pass, like a compute shader.What solution would you like?
We should implement a
Handle<Storage>abstraction that can replace both these use cases. This will be theBufferequivalent toHandle<Image>and will produce aRenderAsset(likely one of our higher level wrapper types, or possibly a new type erased version that avoids needing a generic plugin).What alternative(s) have you considered?
It's possible to work around this right now as noted above, but it's very painful and the docs are confusing.
Additional context
This infrastructure may be able to be re-used for portions of #13373