VISH  0.2
Classes | Public Types | Public Member Functions | Protected Member Functions
Wizt::BufferArray Class Reference

Base class for OpenGL buffer objects, which are the building blocks of Vertex Buffer Objects. More...

#include </home/werner/origo/vish/ocean/GLvish/BufferArray.hpp>

List of all members.

Classes

Public Types

Public Member Functions

Protected Member Functions


Detailed Description

Base class for OpenGL buffer objects, which are the building blocks of Vertex Buffer Objects.

A possible exception-save usage scenario is via the activateVB() macro:

BufferArray&B;

        activateVB(B)
        {
                ... render code ..
        }
See also:
http://www.songho.ca/opengl/gl_vbo.html

Member Enumeration Documentation

Specifies the expected usage pattern of the data store.

  1. STREAM The data store contents will be modified once and used at most a few times.
  2. STATIC The data store contents will be modified once and used many times.
  3. DYNAMIC The data store contents will be modified repeatedly and used many times.

The nature of access may be one of these:

  1. DRAW The data store contents are modified by the application, and used as the source for GL drawing and image specification commands.
  2. READ The data store contents are modified by reading data from the GL, and used to return that data when queried by the application.
  3. COPY The data store contents are modified by reading data from the GL, and used as the source for GL drawing and image specification commands.
See also:
http://www.opengl.org/sdk/docs/man/xhtml/glBufferData.xml

Constructor & Destructor Documentation

Wizt::BufferArray::~BufferArray ( )

Destructor - MUST be called within an OpenGL Context.

If called in an non-OpenGL context, segmentation faults in the OpenGL driver/library will most likely occur. The preferred way is to store BufferArray objects in a GLCache, but NOT in an user-defined structure. The GLCache is supposed to be destroyed by the application when the OpenGL Context is destroyed, which is NOT when the containing objects are destroyed. Rather it is when a windows is closed, but not yet the application.

This mechanism does require special care and is non-trivial.


Member Function Documentation

bool Wizt::BufferArray::activate ( const Anemone )
Note:
This function issues the glGenBuffer() creation call on request.
bool Wizt::BufferArray::load_subset ( int  offset,
const void *  ptr,
memsize_t  sz 
) const [protected]

Load a subset of the data on the graphics card, updating an existing buffer.

Calls glBufferSubData() . http://www.opengl.org/sdk/docs/man/xhtml/glBufferSubData.xml

When replacing the entire data store, consider using glBufferSubData rather than completely recreating the data store with glBufferData. This avoids the cost of reallocating the data store.

Consider using multiple buffer objects to avoid stalling the rendering pipeline during data store updates. If any rendering in the pipeline makes reference to data in the buffer object being updated by glBufferSubData, especially from the specific region being updated, that rendering must drain from the pipeline before the data store can be updated.

Clients must align data elements consistent with the requirements of the client platform, with an additional base-level requirement that an offset within a buffer to a datum comprising N bytes be a multiple of N.

bool Wizt::BufferArray::load_untyped ( const void *  ptr,
memsize_t  MemorySize,
size_t  nElements,
usage  usage_hint = STATIC_DRAW 
) [protected]

Loads the given data on the graphix card.

Binds the current target and calls glBufferData().

Parameters:
MemorySizeHow much memory will this call occupy on the GPU? This value will be used in conjunction with the GLCache.
nElementsHow much elements will be used in this array? This value will be used to check the consistency of Vertex Buffer Arrays, if an array with different number of elements is added, then an Inconsistency exception will be thrown.
Note:
Clients must align data elements consistent with the requirements of the client platform, with an additional base-level requirement that an offset within a buffer to a datum comprising N bytes be a multiple of N.
See also:
http://www.opengl.org/sdk/docs/man/xhtml/glBufferData.xml
Todo:
Call does unbind() internally. Think if that is a problem and/or should be optimized.
size_t Wizt::BufferArray::NumberOfElements ( ) const [inline]

Returns the number of elements referenced via this BufferArray.

It will be zero at construction and only be set using a typed load() call.


The documentation for this class was generated from the following files: