The OpenGL Interface of Vish

Objects Implementing Rendering Functionality

Some, but not all, Vish objects have the capability of rendering into an OpenGL context. Those who can, are derived from the common base class VEnvironmentRenderObject . They provide a special member function render() that must be called with an OpenGL context enabled. Only when this function is called an OpenGL context is available, all other virtual member functions - in particular

• the constructor
• the update function
• the destructor will not have an OpenGL context available. It is therefore important that neither the constructor, nor the destructor, call any OpenGL functions. Functions that use OpenGL must only be called from within the render() function.

In most cases, derive an object from VRenderObject . These objects are "save" and will not influence others. MonochromeBackground::cpp is a short example. For more basic functionality, derive from VEnvironmentRenderObject . These objects may influence other objects that are rendered "later". See the object's respective documentation for details.

Rendering Vish Objects from an Application providing an OpenGL Context

Rendering a Single Vish Object

Objects that can be rendered are derived from base class RenderAble (see about automatic type casting). Rendering a specific Vish object in an existing OpenGL context as provided by an application is as simple as calling this object's safe_render() function:

VRenderContext&Context;
        if (RefPtr<RenderAble> RenderAbleObject = MyObject)
        {
                RenderAbleObject->safe_render(Context);
        }

Note that a VRenderContext must be provided and constructed appropriatly. See the documentation of class VRenderContext for details.

Renderable objects provide some more functionality, such as means to get the 3D bounding box of an objects, or a flag whether it is supposed to be visible or not. It is left to to the calling code to determine if this functionality is used or not.

Rendering Multiple Vish Object

If multiple objects are intended to be rendered, they may be all collected in an object of type VSceneObjects and inserted manually by calling the VSceneObjects::insert() function. The member function VSceneObjects::render() will then take the same parameters as a single RenderAble object, but allow to render a set of objects. There exists a class VScene which provides exactly this type VSceneObjects as output; this class can be used to store such a list of RenderAble objects.

The class VEnvironmentRenderObject comes with a special property, that during construction it will look for for all objects of type VScene that exist in Vish, and add themselves to each of these lists that (already existing) VScene objects provide. Thus, there is no need to manually insert objects to a list of renderable objects - just create a VScene object, and once a new VEnvironmentRenderObject is created by any means (such as executing a Vish script), it will automatically show up in the list of objects that are renderable by the VScene. The list of available objects in a specific VScene object can be inspected by investigating the output VScene::mySceneLayers .

Rendering Multiple Vish Object in Different Contexts

While an instance of class VScene provides a list of renderable object, the class Viewer requires such a list of renderable objects as input. It may therefore be connected to a VScene. A Viewer is an abstract base class that provides additional functionality, such as

• rendering a list of objects into some Frame buffer
• providing a ValuePool that enables variables to have values local to just this Viewer's context
• an OpenGL Cache

An application will want to derive from class Viewer, and call the Viewer::render() function whenever some rendering would occur. A newly created Viewer object will create a VScene object automatically, if it does not yet exist, or connect with an existing one. Therefore once a Viewer object has been created by an application, all subsequently created VEnvironmentRenderObjects will be rendered by calling this Viewer's render() function automatically.

Multiple Viewers may co-exist, each of them having its own Context and ValuePool . They may be managed through an instance of class MetaViewer . More documentation on this class is pending.