[fixed]Buffers used in SHWBufferLinks can't be encapsulated

[rogerborg]

I've noticed and reported what appears to be a problem with CVolumeLightSceneNode's direct encapsulation of an SMeshBuffer.

Because it's a direct encapsulation, the SMeshBuffer is deleted when the CVolumeLightSceneNode is deleted. However, the SMeshBuffer may have been grabbed by an SHWBufferLink, which assumes that it will therefore remain valid, and tries to drop() it in its destructor. If the CVolumeLightSceneNode has been deleted before this happens, EGREGIOUS HORRORS ensue.

I mention this because I'm a lazy hippy, and haven't checked if this is a general problem. You, dear reader, may want to check if your use - and particularly deletion - of an SMeshBuffer is prone to conflict with SHWBufferLink grabbing a reference to it.

[hybrid]

I think this problem will hit several other nodes as well. At least may hit them, once the buffers are changed from EHM_NEVER to something else. Since the hw_buffer interface might also be used for other things in the future we should fix all possible issues. This means that no IMeshBuffer which is used for drawing should use static memory allocation. I guess this is a restriction everyone can live with. Other ways, such as checking the existance of the meshbuffer somehow, or signaling it's destruction under all circumstances would imly too many other changes and a stronger binsing to the driver interface - something which we tried to avoid by the current hw_buffer implementation.
I'll also put a documentation into the IMeshBuffer interface and their implementations so everyone will know about this issue.

[hybrid]

Ok, just added the docs, so this should be fixed - at least for MeshBuffers.