Thanks. I'm starting to get an idea. I'm new to 3d rendering in general, and all Metal examples one can find take 1 of 2 approaches: Naive approach, every game object has its own buffer(s) and we loop through them on the CPU and do a draw call for each. Add/change/remove objects at will. More modern rendering techniques that fix geometry up front and offload work to GPU. It's expected to never change. My case is to load/unload terrain as camera moves. Will look at triple buffering.

To then rephrase my question with that context in mind, it would be "Are there best practices/examples for managing change to geometry with modern rendering approaches using Metal?" I think I understand the point with triple buffering (three vertex buffers, update one while the previous one is being rendered) but I wonder about the performance of having to remake the buffer so often. I will just have to try to implement it. Thank you for the suggestions!

This works! Thank you! Have a great day.

Actually, I should say... this works until I try using this approach with a MTLTexture object. Example: struct FragmentShaderArguments { DEVICE_PTR(Light) lights; metal::depth2d<float> shadowTexture; }; As is, it cannot be found by Swift. If I try to use the DEVICE_PTR (or DEVICE_REF, for what it's worth) macro, Swift sees it and has no problem, but my fragment shader says Type 'const device FragmentShaderArguments &' is not valid for attribute 'buffer'.

On further thought, I don't think I can populate one large buffer for all models as that would, I think, not be possible to write to in parallel, and I would have no way to know the offsets ahead of time. Unless there is another possibility I'm missing, it would seem I would need an empty too-large intermediate buffer for each model.

That's a great point. I'll experiment and see how it goes. It would definitely save some existing work on the CPU side too.