I give each object its own buffer. Remember that buffers are different sizes, so to share it among different objects, you'd have to make it big enough for hte biggest object.

That being said, don't be too worried about locking/unlocking, it's very common to lock/unlock many object's buffers per frame, such as model animation.

Often more than one object is kept in the same buffer. In some cases that's the natural thing to do (such as for particles, though perhaps not everyone will call them "objects"). At other times it's just a way to save buffer switches, which have a little bit of overhead.

Quote:Would each object have its own buffer? This way you wouldn't need to lock/unlock the buffer as often.

What do you mean? There's usually not much of a relation between locking/unlocking and the number of objects in a buffer. If you have a bunch of static objects in a buffer, then they buffer is filled once, and then you just access subsets of it, which doesn't require locking/unlocking. If everything is dynamic (such as with particles), then you change the entire buffer anyway. If some stuff is dynamic and some is static, then you'll need at least one static buffer and one dynamic buffer, but ...

It tends to be simpler to have one buffer per object, and I'd recommend it as a first implementation (to get something working as quickly as possible) but since you're talking OOP, I think that abstracting this is the way to go. That'd probably mean putting the management of buffers in a different class, and having an opaque definition of an object's buffers, which in the naive buffer manager (one buffer per object) will just include the buffer, but in a more complex one will include the position as well.