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.

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.

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'.

This works! Thank you! Have a great day.

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!

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.